Published on: 2018-03-28T03:19:48+00:00
Bitcoin developers are currently discussing the possibility of reclaiming unused opcodes in the software's scripting language and repurposing them as RETURN_VALID. This proposal, suggested by Bram Cohen, aims to simplify scripts and save bytes. While there is some agreement on this idea, there is a debate over whether to keep just one OP_NOP or not.One of the main challenges in implementing this change is dealing with unknown opcodes being parsed in unexecuted sections of code. Several options were discussed, including causing a RETURN_VALID at parse time, exterminating IF and MASTing, adding IFJUMP, IFNJUMP, and JUMP opcodes, or requiring new opcodes to have fixed length 1.The discussion also touched on the implementation of multisig opcodes. Cohen suggested using MAST as an elegant solution for a large number of possibilities, while others proposed more complex formulas for combining signatures.Another topic of discussion was signature aggregation in Bitcoin. Developers explored the concept of gathering public keys for aggregate signature checking instead of individual signatures. However, reconciling script with signature aggregation was noted as a difficulty, especially in terms of transaction-level aggregate differences between pre-fork and post-fork nodes.In a separate email thread, Anthony Towns proposed focusing on Schnorr signatures, Taproot, MAST, and re-enabling opcodes rather than interactive signature aggregation. The complexity of signature aggregation, particularly its impact on blind signature protocols, was highlighted by Andrew Poelstra. Poelstra suggests that zero-knowledge proofs could be used to address the issue.In another email conversation, Zeeman suggested a simplified solution for aggregated signatures using dedicated opcodes. AJ explained that checking gathered public keys only happens at the transaction level, making additional opcodes unnecessary in scripts. AJ also mentioned the importance of cross-input signature aggregation and the Bellare-Neven verification algorithm.To implement both signature aggregation and RETURN_VALID together, various solutions were discussed. These included carefully writing scripts, using dedicated opcodes, or employing a Merkleized Abstract Syntax Tree (MAST). The use of separate buckets for independent signature generation and verification was also explored.Soft-forking new opcodes presents challenges, particularly in validating new classes of addresses with existing nodes. The use of RETURN_VALID opcodes was suggested as an alternative solution, allowing for any behavior. However, caution is needed to ensure compatibility and avoid hard forks.Overall, the proposed solutions aim to make signature aggregation possible while maintaining compatibility with the existing Bitcoin infrastructure. Bitcoin Core developers are considering introducing a new segwit witness version (v2) that supports Schnorr signatures, MAST scripts, and has specific opcodes for aggregating signatures. A config setting will be maintained to allow users to prevent a hard fork until the next release after activation.
Updated on: 2023-08-01T22:49:43.596054+00:00