Bitcoin Covenants Part 2: OP_CHECKTEMPLATEVERIFY

This is Part 2 in the technical article series about Bitcoin covenants by Cointelegraph Research. To read the previous article click here. 

OP_CHECKTEMPLATEVERIFY (OP_CTV) was proposed by Jeremy Rubin in BIP 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_CTV expects this 32-byte commitment hash on top of the stack. The opcode then computes a fresh StandardTemplateHash from the current spending transaction to compare with this commitment hash. The serialized fields that go into the StandardTemplateHash include 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_CTV pushes a 1 on the stack to signal success; otherwise, it pushes a 0 to signal failure.

A basic locking script with OP_CTV would take the form <Commitment Hash> OP_CTV <PubKey> 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 as OP_IF and OP_ELSE. A script structured OP_IF <Hash_X> OP_CTV OP_ELSE <Hash_Y> OP_CTV OP_ENDIF gives the spender the option of two possible transaction templates, each enforced by a distinct commitment hash. The spender selects a branch, and OP_CTV verifies 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 of OP_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 two OP_CTV ScriptPubKeys be created. 

To deposit funds into this vault, she creates a vault output encumbered by OP_CTV that commits only to a single transaction template, Tx_Unvault. This template spends the vault UTXO to a second OP_CTV address, 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 by OP_CHECKSEQUENCEVERIFY (OP_CSV) via the previous transaction’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 a CTV commitment 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 Transaction

OP_0 <sha256(

    OP_IF

        <100> OP_CHECKSEQUENCEVERIFY

        OP_DROP

        <Hash_Hot> OP_CHECKTEMPLATEVERIFY

        <Hot_PubKey> OP_CHECKSIG

    OP_ELSE

        <Hash_Cold> OP_CHECKTEMPLATEVERIFY

        <Cold_PubKey> OP_CHECKSIG

    OP_ENDIF

)>

If Alice takes the normal withdrawal path, she waits 100 blocks, builds Tx_Hot exactly as precommitted, and provides her hot key signature with OP_1 to 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 through OP_CTV are similar to those that can already be achieved through pre-signed transactions. However, OP_CTV avoids having to generate and later dispose of ephemeral keys. Because OP_CTV does not commit to txids, an OP_CTV address can also be reused, as long as it is funded with the exact amount required by the output template. If the UTXO sent to an OP_CTV is too small, it can become unspendable. If it is too large, the excess can become a compulsory miner tip. OP_CTV results 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 of SIGHASH_ANYPREVOUT (APO), which is another well discussed proposal for opcodes that fully implement covenant functionality.