Author: Anthony Towns 2022-03-05 05:59:24
Published on: 2022-03-05T05:59:24+00:00
The Bitcoin development mailing list has been discussing the Annex in Bitcoin, which is a way to include additional information in a transaction that can be analyzed immediately and unconditionally without knowing anything about the UTXO being spent. The annex can also be used for optimizing SIGHASH_GROUP, allowing a group of inputs to claim a group of outputs for signing.The Annex can be encoded in a simple way using a tag/length/value scheme or the list encoding from Lisp scripting language. It can be used to change the consensus interpretation of a transaction and validate a zero-knowledge proof. To access individual entries from the annex, a different approach may be necessary, as introducing OP_ANNEX may require. It commits to the signature, making it important to know what the annex will contain before signing since some entries in the annex may not be able to be calculated by other parties. Having a way to specify locktimes in the annex can solve this CLTV problem. However, having signatures in both COLD_LOGIC and HOT_LOGIC with different costs could create issues. The "add cost" use of the annex is only talked about hypothetically and is not needed in reasonable scripts with today's opcodes.Cross-input signature aggregation requires everyone to agree on the message they're signing in the first place. Therefore, OP_ANNEX should be soft-forked out, reserved until we can find a way of using it.
Updated on: 2023-05-22T18:05:57.339361+00:00