delvingbitcoin
Contract-level Relative Timelocks (or, let's talk about ancestry proofs and singletons)
Posted on: January 6, 2025 14:40 UTC
The Schnorr trick, combined with the CAT operation in Bitcoin scripting, offers a compelling method for executing complex contract operations on the blockchain.
Through this technique, it's possible to push important transaction elements such as an input's scriptpubkey, prevout, and index, as well as the outputs, onto the stack. A key application of this is enforcing that funds are always spent back to the same Taproot address by matching an input's scriptpubkey with an output scriptpubkey. This mechanism can be utilized to construct state machines within contracts, where various states correspond to different tapleafs that validate state transitions. An insightful exploration of this technique, including the underlying Schnorr mathematics, was presented at Bitcoin++, details of which can be found here.
Another innovative approach involves the concept of passing state from one transaction to another, dubbed as the "state caboose." This involves embedding a state commitment within an output of a transaction and then verifying this commitment in a subsequent transaction. By reconstructing the transaction minus its witness data on the stack and using a hash function to generate its TXID, it ensures continuity and integrity of state across transactions. This strategy allows for creating contracts with a constant-sized inductive proof of validity, significantly optimizing contract execution and validation on the blockchain.
A practical implementation of this concept is demonstrated in the development of a vault prototype, where state commitment aids in specifying withdrawal destinations. The process entails making a commitment in one transaction that dictates the following transaction must adhere to certain rules of a specified contract. This facilitates a robust framework for contract validation, allowing for seamless upgrades or extensions and potentially simplifying the management of contract rules.
The feasibility of these advanced contract mechanisms hinges on specific Bitcoin script operations like OP_CAT, though exploring additional opcodes could further refine and expand their capabilities. For instance, opcodes like CCV and TAPTWEAK could streamline state management, while CSFS (CheckSigFromStack) enables more straightforward authenticated delegation. The introduction of more specialized introspection opcodes would also aid in simplifying scripts and enhancing the overall reasoning about contracts within this innovative scripting context.