A Taproot-native (re-)bindable transaction bundle proposal

In a recent discussion regarding the evolution and implementation of Bitcoin Improvement Proposals (BIPs), several key points were raised concerning the effectiveness and potential limitations of proposed changes. The conversation, primarily between two knowledgeable figures in the field, shed light on various aspects of these proposals, specifically focusing on TEMPLATEHASH and its comparison to BIP-119 and other relevant BIPs.

A significant concern brought up involves the way TEMPLATEHASH commits to an annex, unlike CTV (CHECKTEMPLATEVERIFY). This distinction raises questions about the flexibility and future utility of TEMPLATEHASH, as the content of the annex—defined in BIP-341—is determined at the spend time, necessitating prior knowledge of this content for the hash. This requirement could restrict how the annex is utilized, especially considering possible uses such as cross-input signature aggregation, aggregate vault operations checks, and implementing SIGHASH_GROUP-like functions. An alternative suggestion was made to consider an orthogonal opcode, potentially named "OP_CHECKANNEX", which would allow script authors to explicitly set expectations for the annex, thus offering a more adaptable approach.

Another point of debate is the lack of support for TEMPLATEHASH in witness version 0 (segwit) scripts, which is seen as a significant limitation for its adoption and deployability. Despite Taproot's activation, estimates indicate minimal utilization, suggesting a slow transition away from pre-Taproot script contexts. This slow adoption can be partly attributed to practical barriers, such as the lack of native Hardware Security Module (HSM) support for the Schnorr signature scheme integral to Taproot, implying that some systems may never update to Taproot compatibility. This scenario underscores the importance of considering the needs of users entrenched in witness v0 environments, especially those interested in utilizing simple vaulting mechanisms—a use case where CTV has garnered interest.

Furthermore, there was an expression of disappointment regarding the oversight of certain use cases by the TEMPLATEHASH authors, particularly those related to deferred payout and congestion control, which could benefit from either CTV or a proposed P2TH ("witness v2") patch. Despite these concerns, the overall tone acknowledged the ongoing efforts to enhance Bitcoin's scripting capabilities, highlighting the importance of continued dialogue and development within the community.

For further details, the discussion references specific commits and proposals accessible via GitHub, providing a direct link to the technical documentation and changes under consideration.