What if you could lock Bitcoin so it could only move in one specific, pre-approved way? That's the idea behind OP_CTV, and it could make self-custody vaults dramatically safer and more trustless.
This is Part 2 in the technical article series about Bitcoin covenants by Cointelegraph Research. To read the previous articleclick here. OP_CHECKTEMPLATEVERIFY (OP_CTV)was proposed byJeremy RubininBIP 119. It. . .
This is Part 2 in the technical article series about Bitcoin covenants by Cointelegraph Research. To read the previous articleclick here. OP_CHECKTEMPLATEVERIFY (OP_CTV)was proposed byJeremy RubininBIP 119. It defines spending conditions in a simple template structure that can include the outputs, version, and locktime of the next transaction. The opcode takes a commitment hash as an argument and requires that any transaction executing the opcode include only outputs that match this commitment. Upon execution,OP_CTVexpects this 32-byte commitment hash on top of the stack. The opcode then computes a freshStandardTemplateHashfrom the current spending transaction to compare with this commitment hash. The serialized fields that go into theStandardTemplateHashinclude the transaction version and locktime, the counts of inputs and outputs, and a hash of all outputs, which commits to both their values and their locking scripts (scriptPubKeys). If the transaction matches the template,OP_CTVpushes a1on the stack to signal success; otherwise, it pushes a0to signal failure. A basic locking script withOP_CTVwould take the form OP_CTV OP_CHECKSIG. This enforces both the transaction details and the authorization of the key holder. To introduce branching logic, where two or more possible transaction types are allowed, CTV can be combined with conditionals such asOP_IFandOP_ELSE. A script structuredOP_IF OP_CTV OP_ELSE OP_CTV OP_ENDIFgives the spender the option of two possible transaction templates, each enforced by a distinct commitment hash. The spender selects a branch, andOP_CTVverifies that the spending transaction matches the corresponding template. The hash for each path is computed from the full set of outputs and other fixed parameters defined for that transaction. To illustrate a more advanced application ofOP_CTV, suppose Alice wants to create a vault, i. e. , a Bitcoin UTXO spending policy that constrains how funds can be spent, by requiring it to go through possible withdrawal paths. To spend her funds, they first need to be moved to an intermediary address from which they can either go to her hot wallet after a 100 block delay, or immediately be sent back to secure cold storage in case a compromise has taken place. This construction requires that three transaction templates and twoOP_CTVScriptPubKeys be created. To deposit funds into this vault, she creates a vault output encumbered byOP_CTVthat commits only to a single transaction template,Tx_Unvault. This template spends the vault UTXO to a secondOP_CTVaddress, which creates the intermediate unvaulting output. The intermediate output, in turn, has two possible spending templates. The first template,Tx_Hot, defines the normal withdrawal path and spends the unvaulting output to her hot wallet after a 100-block relative timelock enforced byOP_CHECKSEQUENCEVERIFY (OP_CSV)via the previoustransaction’s nSequence. The second template,Tx_Cold, defines the emergency recovery path that can be triggered in case her keys are compromised. It spends the attempted unvault directly back to cold storage without delay. Alice computes aCTVcommitment hash for each template. She then constructs the vault’s locking script as a P2WSH output, committing to the redeem script shown in Figure 1. Figure 1: Hot Branch Spend of Alice’s P2WSH TransactionOP_0 OP_CHECKSEQUENCEVERIFYOP_DROP OP_CHECKTEMPLATEVERIFY OP_CHECKSIGOP_ELSE OP_CHECKTEMPLATEVERIFY OP_CHECKSIGOP_ENDIF)>Source:Cointelegraph ResearchIf Alice takes the normal withdrawal path, she waits 100 blocks, buildsTx_Hotexactly as precommitted, and provides her hot key signature withOP_1to select the first branch. The relative time-lock countdown does not begin until an attempt is made to unvault the funds. In either case, the spending transaction must match one of the pre-committed templates exactly. The constraints expressible throughOP_CTVare similar to those that can already be achieved through pre-signed transactions. However,OP_CTVavoids having to generate and later dispose of ephemeral keys. BecauseOP_CTVdoes not commit to txids, anOP_CTVaddress can also be reused, as long as it is funded with the exact amount required by the output template. If the UTXO sent to anOP_CTVis too small, it can become unspendable. If it is too large, the excess can become a compulsory miner tip. OP_CTVresults in a more trust-minimized mechanism for constructing vaults, congestion-control schemes, and other smart contract primitives, but some of the rigidity of pre-signed transactions remains. In our next article we will commence our discussion ofSIGHASH_ANYPREVOUT (APO), which is another well discussed proposal for opcodes that fully implement covenant functionality.