Published on: 2022-03-07T08:08:03+00:00
A discussion has been taking place on the Bitcoin development mailing list regarding the use of annexes in transactions and their potential benefits. Annexes are reserved spaces for future extensions that can be analyzed immediately without knowing anything about the utxo being spent. One potential benefit is optimizing SIGHASH_GROUP to allow a group of inputs to claim a group of outputs for signing. However, there are concerns about using annexes, such as the potential for script fragments to require incompatible interpretations of the annex. Some suggest banning the OP_ANNEX opcode altogether.The discussion also touches on other topics, such as CLTV, CSV, and nLockTime. It is suggested that a way to access individual entries from the annex would be useful, but creating scripts with difficult solutions can be impractical. The annex could contain a short byte string indicating additional weight units, which would only increase the witness size by a few bytes.There is also debate about the purpose of the annex and its implications for the Bitcoin network. Some propose using it for transaction field extension or specifying per-input absolute locktimes. Others suggest soft-forking the annex out of the current Checksig and redesigning its usage later. The reservation of the annex ensures that new consensus rules can be immediately applied to utxos predating those rules without needing to update them on-chain first.Concerns are raised about third-party malleability in Bitcoin transactions when using the annex opcode. Suggestions are made to banish the OP_ANNEX opcode or find a way to make it third-party malleable-resistant. The use of OP_ANNEX is debated, with some arguing for its utility in increasing limits on SCRIPT execution and others pointing out its potential issues.Overall, the discussion revolves around the potential benefits and drawbacks of using annexes in transactions and their implications for the Bitcoin network. There are various suggestions and concerns regarding the usage and implementation of annexes, including optimizing SIGHASH_GROUP, addressing script compatibility issues, and ensuring security against third-party malleability.The Annex is a linearizable resource that can be used to reserve something like memory efficiently. One suggestion is to introduce OP_ANNEX, an opcode that would push the annex on the stack along with a 0 or 1 to differentiate it from no annex. This would allow for the Annex to be used as a register/tape for a computational model, making witness construction Turing complete. However, this conflicts with using the Annex to guess computation costs and raises issues with Miniscript, where multiple annex values may need to be pre-signed.To address these issues, one solution proposed is to soft-fork the Annex out and always set it equal to 0 until a specific use case is found. Another option is to make the Annex unobservable from the script but still serve as a hint for validation rules. However, before deciding on the use of the Annex, further discussion is needed to determine its purpose and constraints.
Updated on: 2023-08-02T05:49:14.711009+00:00