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

The discourse centers around the implications and considerations of annex commitment within Bitcoin transactions, specifically in relation to OP_TEMPLATEHASH. The concern raised involves the potential limitation imposed by annex commitment on the ability of users to change the annex at the time of spending, should they have previously committed to a specific annex. Annex commitments are highlighted as crucial for enabling rebindable signatures and for ensuring forward compatibility with future uses of the annex, which could range from proof of publication without needing an additional signature to pre-committing to any consensus meaning the annex might have in future soft forks.

Despite the concerns, it's argued that pre-committing to an annex does not significantly increase the risk of invalidating someone's coins in the future compared to pre-signing it. This is underpinned by a warning against including an annex in transactions due to the potential for permanent fund loss, suggesting that the risks are already well communicated to users. The discussion extends to the broader context of upgrade hooks, including higher nVersion numbers and future Segwit versions in transaction outputs, implying that users may willingly commit to these elements knowing the associated risks.

A significant portion of the debate focuses on the support or lack thereof for Segwit v0 in the context of introducing new features like OP_TEMPLATEHASH. The argument against prioritizing support for outdated scripting contexts like Segwit v0 is bolstered by data showing an increasing adoption of Taproot (P2TR outputs), which suggests a shift towards more modern script contexts. It's emphasized that new features should primarily target the latest iterations of the scripting system to leverage improvements in security, efficiency, and privacy—qualities attributed to Taproot/Tapscript over Segwit v0. This stance is justified by the enhancements Taproot/Tapscript brings, such as eliminating quadratic hashing, enforcing malleability-related standardness rules, supporting batched validation, and improving privacy by making outputs appear identical before being spent.

The conversation also touches on industrial adoption, challenging the claim that many companies wish to use OP_TEMPLATEHASH but are unable to migrate from P2WSH to Taproot without presenting evidence to support this assertion. The possibility of implementing optimizations for congestion control through a new Segwit version is mentioned, though skepticism about its necessity and worth is expressed, reflecting a broader apprehension within the community regarding the proposed changes.

In conclusion, the discussion encapsulates a nuanced examination of the practical and theoretical implications of integrating new features like OP_TEMPLATEHASH within the Bitcoin protocol, weighing the benefits of innovation against the need for caution and compatibility with existing systems. Key points include the importance of annex commitment for future compatibility and the argument for focusing feature development on modern script contexts to harness the full potential of recent advancements in the protocol.