Published on: 2018-05-10T22:44:36+00:00
The Bitcoin Core Devs are engaged in discussions regarding the post-Schnorr signing process, which aims to enhance fungibility by making different features indistinguishable. This would render tracking and data mining useless, but it necessitates the development, review, testing, and deployment of all features together rather than individually. The ideas surrounding post-Schnorr signing can be categorized into Schnorr CHECKSIG, Merkelized Abstract Syntax Trees (MAST), Taproot, Graftroot, Interactive Signature Aggregation, Non-interactive Half-Signature Aggregation within Transaction, New SIGHASH modes, p2pk versus p2pkh, Other new Opcodes, Hard-fork Automatic Upgrade of p2pkh to be Spendable via Segwit, and the debate on whether addresses should be hashes or scripts.Most of these improvements require new segwit versions, with MAST being potentially evaluated independently in segwit v0. However, other enhancements such as Schnorr p2pk(h) addresses and taproot+mast addresses would need a soft-fork for segwit v1. Further upgrades including graftroot, interactive signature aggregation, and non-interactive sig aggregation would be introduced in later segwit versions.During discussions, there were concerns raised about graftroot and the possibility of delaying its implementation until non-interactive sig aggregation becomes feasible. It was suggested that (e) and (f) should be separated if non-interactive sig aggregation is not possible. The overall goal of the post-Schnorr signing process is to improve fungibility, but the approach of developing all features together could potentially delay certain improvements. Interested individuals can subscribe to the bitcoin-dev mailing list for more information on these discussions.In another discussion on the Bitcoin developer mailing list, Anthony Towns proposed a soft-fork to enable Schnorr signatures and CHECKSIGFROMSTACK. This proposal has various benefits, such as payment decorrelation for lightning and improved multi-signature schemes. While it could be implemented with a single new script type, significant work would still be required for its rollout. Other potential changes discussed include 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 suggests starting 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 explored. However, concerns were raised about the time it might take and the urgency for graftroot. It was suggested that delaying implementation until non-interactive sig aggregation becomes possible would be a better option. Some participants expressed concerns about the feasibility of non-interactive sig aggregation, leading to the suggestion of separating (e) and (f). There was also a preference for doing them as a single upgrade.Overall, the discussions revolved around proposed changes to Bitcoin's segwit protocol and the optimal approach to implementing them. Those interested can refer to the post documenting the discussion for further details. Anthony Towns compiled a list of ideas for signing post-Schnorr, which includes Schnorr CHECKSIG, MAST, Taproot, Graftroot, Interactive Signature Aggregation, Non-interactive half-signature aggregation within transaction, New SIGHASH modes, p2pk versus p2pkh, Other new opcodes, Hard-fork automatic upgrade of p2pkh to be spendable via segwit, and Should addresses be hashes or scripts? Each idea is accompanied by its benefits, requirements, approaches, drawbacks, and rationale. Some ideas require a new segwit version, while others can be implemented independently.The proposed soft-fork timeline suggests implementing MAST in segwit v0 if there is sufficient support, 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.Bitcoin developers are exploring several upgrades to the cryptocurrency system. One proposal involves introducing a soft fork for Merkelized Abstract Syntax Trees (MAST) in SegWit v0, which offers logarithmic scaling for scripts with multiple alternative paths. Another proposal includes introducing a new SIGHASH mode and deciding between pubkeyhash or just pubkey for addresses. Schnorr p2pk(h) addresses and taproot+mast addresses could be introduced in SegWit v1, combining pay-to-pubkey and pay-to-script in a single address.
Updated on: 2023-08-01T23:07:41.006702+00:00