delvingbitcoin

Combined summary - Draft BIP for OP_TXHASH and OP_CHECKTXHASHVERIFY

Combined summary - Draft BIP for OP_TXHASH and OP_CHECKTXHASHVERIFY

The discussion centers on the exploration of utilizing non-verified transaction hashes (TXHASH) without Concurrent Signature Fields Selector (CSFS) or Concatenated Authentication Tag (CAT) for validating equality between specific fields within a transaction.

It highlights the harmonious function of CSFS and TXHASH, and the expansion of potential design space with the integration of CAT and TXHASH. A technical evaluation of the TXFS_SPECIAL_TEMPLATE is mentioned, revealing its flexibility in protocol design, especially concerning fee addition through Unspent Transaction Outputs (UTXOs). The utility of TXHASH in selecting a customized TxFieldSelector is emphasized, enhancing fee addition capabilities and mitigating risks associated with UTXO size-specific hashes.

The document contrasts adding CSFS with adopting APO-style keys, noting their respective advantages and disadvantages regarding size and compatibility. The possibility of incorporating "magic" keys through additional opcodes like OP_INTERNAL_KEY and/or OP_EXTERNAL_KEY is considered, alongside the use of OP_TXHASH combined with OP_CHECKSIGFROMSTACK to fulfill complex requirements. The potential simplification of default modes for input and output field selectors to streamline the selection process is also discussed. Moreover, it suggests that the BIP should address the commitment to the control block rather than the tapleaf_hash, highlighting the implicit inclusion of the leaf hash due to BIP341’s script validation rules. Lastly, the feasibility of using the TxFieldSelector mechanism for future introspection opcodes is contemplated, indicating a possible need for selecting the current input's script code.

The Bitcoin Improvement Proposal (BIP) has made significant progress, transitioning from its draft phase into a more concrete stage, as evidenced by its implementation within Bitcoin Core, accessible via Bitcoin Core Implementation. This marks a notable advancement in the Bitcoin network's evolution, reflecting a consensus on proposed changes and inviting further community engagement. The proposal introduces a TxFieldSelector, a serialized data structure for selecting transaction data, and specifies available global fields, input and output fields, and methods for selecting inputs and outputs. It proposes two new opcodes, OP_TXHASH and OP_CHECKTXHASHVERIFY, to enable hashing and verification based on selected transaction fields. Additionally, it addresses resource usage concerns and proposes a caching strategy to prevent excessive hashing.

Furthermore, the proposal aims to enhance protocol design flexibility, allowing users to add fees without breaking transaction chains and enforce conditions on specific transaction parts. It could replace complex sighash constructions and support equality enforcement among transaction fields, potentially replacing the need for certain opcodes. The proposal also entertains the idea of direct introspection through a hypothetical OP_TX opcode. Key open questions include addressing resource usage and quadratic hashing concerns, and the proposal's reception within the community. This initiative represents an attempt to formalize and implement innovative ideas within the Bitcoin protocol, signaling a willingness to explore community feedback and engage in further development.

Discussion History

0
stevenrooseOriginal Post
September 30, 2023 22:21 UTC
1
October 2, 2023 09:31 UTC
2
October 2, 2023 10:30 UTC
3
October 2, 2023 10:55 UTC
4
October 2, 2023 12:59 UTC
5
October 2, 2023 14:12 UTC
6
October 6, 2023 17:26 UTC
7
October 9, 2023 20:14 UTC
8
October 10, 2023 06:31 UTC
9
October 11, 2023 16:28 UTC
10
December 11, 2023 09:06 UTC
11
December 12, 2023 05:26 UTC