Taproot-native prevout binding via sighash preimage decomposition

The discussion revolves around the technical implementation of output binding in Bitcoin transactions using taproot-native constructs, specifically focusing on whether this method serves as a viable alternative to OP_CHECKTEMPLATEVERIFY (CTV). In this method, the tapscript is designed to hardcode a 32-byte expected sha_outputs, which is crucial for verifying transaction outputs. This sha_outputs functions similarly to the digest committed by CTV. During transaction verification, the witness provides the preimage in segmented chunks that include this sha_outputs value. These chunks are kept under 80 bytes to comply with standard transaction formats.

The verification script utilizes OP_EQUALVERIFY to compare the sha_outputs chunk against its hardcoded counterpart, ensuring that only the correct transaction output is processed. Additionally, the script employs OP_SIZE to lock one chunk's size, while OP_CAT is used to reassemble the full 212-byte preimage. Once reassembled, it computes the TapSighash tagged hash and executes OP_CHECKSIGFROMSTACK along with OP_CHECKSIG against a 64-byte Schnorr signature. If the signature satisfies both conditions, it confirms that the witness preimage matches the real sighash, validating the integrity of the sha_outputs.

This mechanism has been actively tested on the Bitcoin Inquisition signet. One such test involved a transaction (identified by 05f9372d..) where a tapscript hardcoded the sha_outputs. This transaction was successfully confirmed (2f345180..), demonstrating the effectiveness of this output-binding method. Conversely, any attempt to alter the output (either the amount or scriptPubKey) resulted in rejection, highlighting the robustness of this approach in maintaining transaction integrity.

In summary, while this taproot-native output binding technique achieves similar security guarantees as CTV regarding where funds are directed, it does not necessarily replace CTV in terms of deployment economics. The method requires multiple preimage chunks and a larger script than a single OP_CTV invocation. However, its significance lies in leveraging already-activated opcodes and providing dual covenant semantics, alongside previously discussed input bindings (sha_prevouts). This showcases an advanced level of control over transaction elements within the existing Bitcoin script capabilities, opening discussions on its broader applicability and efficiency compared to traditional methods like CTV.