May 6 - Jul 13, 2026
Instead of this older method, the new approach binds directly to the outpoint itself using the sha_prevouts field from the sighash preimage, which significantly increases security and specificity in transactions. This is achieved by hardcoding the outpoint of input B within the script, which then computes a SHA256 hash of the concatenated outpoints of both inputs. The hash must match the sha_prevouts segment from the preimage, and integrity is verified through a Schnorr signature that satisfies both OP_CHECKSIG and OP_CHECKSIGFROMSTACK. Successful testing on the Bitcoin Inquisition signet has demonstrated the robustness of this script, with detailed transaction records provided for further verification on platforms like mempool.space. The source code and additional details are accessible on GitHub.
In contrast, another email critiques the traditional cryptographic methodologies, particularly those used by Aaron’s team, which involve manually combining preimages with OP_CAT, likening them to outdated technologies. The sender proposes a streamlined approach utilized within the Simplicity framework, which integrates state directly into the Taproot address using SHA-256 streaming. This method ensures absolute Layer 1 bivalence, enhancing consensus and security efficiency. It encourages moving away from OP_CAT towards modern practices embedded within the Simplicity architecture's robust capabilities.
Further discussions explore the viability of taproot-native constructs for output binding in Bitcoin transactions as an alternative to OP_CHECKTEMPLATEVERIFY (CTV). This method involves hardcoding a 32-byte expected sha_outputs into the tapscript, crucial for verifying transaction outputs, and employs multiple opcodes like OP_EQUALVERIFY and OP_CHECKSIGFROMSTACK to confirm transaction integrity. Tested successfully on the Bitcoin Inquisition signet, the method showcases its effectiveness through confirmed transactions and demonstrates its potential in maintaining transactional integrity without necessarily replacing CTV due to its deployment economics. This technique underscores advanced control over transaction elements within existing Bitcoin script capabilities, fostering discussions on its broader applicability.
Lastly, there is a comprehensive discussion about why CAT+CSFS must replace CTV, rooted in the cryptographic definition of a signature as a proof of knowledge. This discussion elaborates how different covenant proposals interact differently with the transaction signature equation, emphasizing that CSFS+CAT allows for the re-execution of the signature message construction (f) within the script itself. This capability suggests that these opcodes could foster more efficient, smaller, and potentially cheaper scripts while providing a robust framework for various covenant implementations. This theoretical underpinning is further explored in detailed discussions and examples available on delvingbitcoin.org, promoting a deeper understanding of their practical and conceptual implications.
TLDR
We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project.
Give Feedback