Published on: 2022-06-24T18:05:50+00:00
In a recent discussion on the bitcoin-dev mailing list, the use of merkle trees for Commitment Transaction Verification (CTV) was debated. While there was recognition that merkle trees could offer advantages in terms of API perspective, the main concern raised was related to validation performance. It was argued that using a merkle tree would add unnecessary work for CTV, with its value only evident in scenarios involving multiple outputs and random-index insertions. For cases where editing the last output is common, SHA-STREAM was proposed as an alternative option, enabling efficient editing of the tail. The conversation also touched upon the OPTX_SEPARATELY and OPTX_UNHASHED fields, as well as the OPTX_SELECT_OUTPUT_AMOUNT32x2* and OPTX_SELECT_OUTPUT_SCRIPTPUBKEY* fields. The issue of upgradability was highlighted, particularly in relation to committing to specific outputs, which currently poses challenges for both OP_TX and CTV. One potential solution suggested was the use of a merkle path to prove the consumption of an entire output. Overall, the discussion centered around weighing the tradeoffs between employing a merkle tree versus other methods for CTV.On May 10, 2022, Rusty Russell shared some ideas on the bitcoin-dev mailing list regarding the OPTX_SEPARATELY and OPTX_UNHASHED fields. He proposed treating these fields separately instead of concatenating them and pushing them on the stack without hashing. The discussion revolved around updating the CTV hash by committing to specific outputs, but it was acknowledged that both approaches were less efficient compared to using a merkle path. The challenge of proving the consumption of an output in its entirety was linked to concerns about upgradability, especially if additional features like CAT or TLUV were to be added. Both OP_TX and CTV aimed to account for upgradability in advance. These concepts have the potential to enhance the efficiency and security of the Bitcoin network.A proposal has been introduced for a v1 tapscript opcode that enables generic covenants. The proposal suggests utilizing an OP_SUCCESS opcode, unless it is used similarly to OP_CHECKTEMPLATEVERIFY, which offers a clear use case and allows for future expansion. If experience demonstrates that repurposing OP_NOP4 as a shortcut is a useful optimization, it may be considered in the future. The proposal builds upon Russell O'Connor's TXHASH, incorporating Anthony Towns' modification through opcode extension. Certain bits are defined specifically for this soft fork, while others can have their semantics determined later. To ensure clarity, the proposal outlines potential future uses. Notably, BIP-342 resource limits impose restrictions, such as failing when more than 1000 elements are pushed on the stack or when an element exceeds 512 bytes. By precisely enumerating what can be committed to, it becomes unequivocally clear what is and isn't committed. The bits separating concatenation and hashing provide a straightforward mechanism for template-style commitments (like CTV) or programmatic treatment of individual elements, such as amounts. The absence of double-hashing for scriptsigs and other fields means that the hashing done for SIGHASH_ALL cannot be reused. It is important to note that the OP_SUCCESS semantic is only applicable in tapscript v1, making it incompatible with covenants for v0 segwit or pre-segwit inputs. If covenants prove beneficial, dedicated opcodes can be provided for those cases.Brandon responded to Rusty Russell's previous email regarding the proposal for a v1 tapscript opcode for generic covenants. Brandon emphasized one major limitation of CTV, which is the script's specificity to the amount of the input being spent. He suggested adding OPTX_SELECT_IN_OUT_AMOUNT32x2 to the initial set of flags, enabling the reuse of a single script and facilitating the construction of a small script for relocatable, batchable operations. The proposed soft fork involves OP_TX followed by 4 bytes of flags. Only the flags marked with an asterisk need to be defined for this soft fork, while others can have their semantics determined later. The proposed flag combinations aim to approximate OP_CHECKTEMPLATEVERIFY, with other combinations resulting in OP_SUCCESS. By enumerating what can be committed to, it becomes explicitly clear what is and isn't committed. The bits separating concatenation and hashing provide a simple mechanism for template-style commitments or programmatic treatment of individual elements. The absence of double-hashing for scriptsigs and other fields means that the hashing done for SIGHASH_ALL cannot be reused. The OP_SUCCESS semantic is only valid in tapscript v1, meaning it does not allow for covenants in v0 segwit or pre-segwit inputs.
Updated on: 2023-08-02T06:29:11.754640+00:00