Author: Bram Cohen 2018-05-10 20:11:04
Published on: 2018-05-10T20:11:04+00:00
In a Bitcoin developer mailing list, Anthony Towns proposed soft-forking to enable Schnorr signatures and CHECKSIGFROMSTACK. This would have many benefits including payment decorrelation for lightning and better multi-signature schemes. The proposal could be implemented in one fell swoop with a single new script type, but substantial work would still be required to roll it out. Other potential changes were also discussed, including Merkelized Abstract Syntax Trees (MAST), Taproot, Graftroot, Interactive Signature Aggregation, and New SIGHASH modes. These changes would require new segwit versions except for MAST, which could be evaluated independently.The proposed soft-fork timeline starts with implementing MAST in segwit v0, followed by Schnorr p2pk(h) addresses and taproot + mast addresses in segwit v1. Further upgrades including graftroot in segwit v2, interactive signature aggregation in segwit v2, and non-interactive sig aggregation in segwit v3 would be introduced later.During the discussion, the possibility of implementing signature aggregation as a variation of segwit v1 was also explored. However, there were concerns about the time it might take for this process, and whether there was an urgency for graftroot. It was suggested that delaying the implementation until non-interactive sig aggregation is possible would be a better option. Some participants expressed concerns that non-interactive sig aggregation might not be feasible, leading to the separation of (e) and (f). It was also suggested that doing them as a single upgrade would be preferable.Overall, the discussion centered on proposed changes to Bitcoin's segwit protocol and the best approach to implementing them. A post documenting the discussion can be found at [0].
Updated on: 2023-06-13T02:18:03.121682+00:00