What is OP_CTV and BIP-119?

BIP-119, better known as OP_CHECKTEMPLATEVERIFY or CTV for short, is a proposed Bitcoin upgrade which would enable new spending conditions for UTXOs (unspent bitcoin). Specifically, CTV would allow Bitcoin users to specify exactly how much bitcoin can be spent in a transaction and exactly where that bitcoin is allowed to go. For example, say that you have a wallet with 1 BTC in it. With CTV, you could create specific spending conditions that allow an authorized transaction to only send 0.5 BTC to address ABCD, while another transaction can only spend the remaining 0.5 BTC to address EFGH. 

CTV provides a more efficient, trustless alternative to pre-signed transactions.  Among other use cases, the upgrade would enable covenants, which are specific rules that dictate how a user can spend UTXOs. This has positive ramifications for wallet security by enabling covenants and vaults – if a hacker accesses a wallet but only a portion of the wallet’s BTC can be spent and/or those BTC can only be spent to an address that’s controlled by the wallet’s owner, CTV spending conditions can thwart would-be theft – but CTV could also positively impact the Lightning Network by enabling channel factories and Bitcoin mining pools by enabling payment pools. 

What is BIP-119 and OP_CTV?

Jeremy Rubin first introduced BIP-119 for OP_CTV in January 2020. Talk of the upgrade made rounds in 2021, but concrete action to implement it never materialized and Rubin took a hiatus from Bitcoin development. In recent months, discussion regarding the proposal has bubbled to the surface of online technical talks once again. 

In BIP-119, Rubin suggests changes to the semantics of an existing opcode, OP_NOP4, to create the technical parameters for OP_CTV. Also known as “Operation Codes,” opcodes are programmatic commands that provide instructions for the execution of specific functions within a computing system; for Bitcoin, opcodes are commands that provide specific, predefined instructions for transactions. For example, Pay-to-Public-Key-Hash (P2PKH) payments utilize 4 opcodes that collectively stipulate that a UTXO (unspent bitcoin) can only be unlocked and spent using the public key and private key signature associated with said UTXO. Another opcode, OP_FALSE, allows arbitrary data to be published on the blockchain, enabling inscriptions. 

OP_CTV would allow users to create predefined transactions that ensure that the related UTXO(s) can only be spent if these predefined conditions are met during subsequent transactions. To accomplish this, OP_CTV transactions include a hash of these conditions within the locking script of a UTXO when a sender creates it with a new transaction. The UTXO, then, can only be unlocked if the conditions of the sender’s next transaction completely match the predefined conditions within the hash included in the locking script.  As a result, CTV enforces rules on who can receive bitcoin, instead of solely enforcing rules on who can send bitcoin.

As explained by Jeremy Rubin on his website:

“CTV enables committing to a specific “next” transaction from script [Bitcoin's scripting language]. This is the ability to make an unbreakable promise on chain which Bitcoin can enforce (e.g. “This coin can only be spent to my multisig, or my backup after a timelock”). This is a departure from normal script which is traditionally only concerned with restrictions on the sender, CTV imposes restrictions on the recipient. More technically, CTV is essentially the ability to embed a signature of a specific transaction inside of a script without needing any elliptic curve operations.”

CTV offers a more trustless alternative to partially signed Bitcoin transactions (PSBT). Partially signed Bitcoin transactions are used to facilitate payments from cold storage wallets (e.g., hardware wallets), but they are also used in multi-signature wallets to facilitate certain Bitcoin applications like Lightning Network channels or Coinjoins; in multi-signature applications, partially signed Bitcoin transactions allow multiple users to sign on to the same transaction using a shared set of UTXOs. With PSBTs, each key that is associated with the partially signed transaction (or depending on the multi-signature setup, the majority or quorum) must sign the transaction to complete it, or the participants need to trust a central coordinator to sign the transactions. With OP_CTV, a Bitcoin user can codify the same transaction conditions that PSBTs enable within the hash that is committed to a UTXO's locking script, making those conditions enforceable by Bitcoin’s consensus rules under the changes orchestrated by OP_CTV.

Bitcoin Covenants, Vaults, Payment Pools, Channel Factories, and Other CTV Use Cases

OP_CTV creates predetermined spending conditions that are reinforced by Bitcoin’s consensus, which in turn creates a more trustless method for such things as UTXO sharing among multiple participants. If enabled, it unlocks the following capabilities for Taproot-enabled wallets:

• Vaults/Covenants: Covenants are spending conditions that allow a Bitcoin script (like tapscript) to restrict how and where an authorized user spends bitcoin; a vault is a type of covenant that creates spending conditions that requires the associated bitcoin to be transacted in two separate blocks in order for a user to take full control of them. Importantly, there are currently no methods to enforce covenants/vaults on-chain. Given that CTV imposes restrictions on how bitcoin can be spent using the hash that is included in the locking script, CTV can create covenants and vaults. Covenants and vaults would improve existing cold storage and custody solutions.
• Scaling via UTXO Sharing / Payment Pools: With CTV, you could construct a payment condition wherein multiple parties share the same UTXO(s). Through this method, a party or parties could consolidate a handful of transactions into a single UTXO and place CTV-enforced restrictions on how much BTC from the UTXO can be spent to certain wallets (for example, a shared UTXO for 1 BTC could be split into 5 payments of 0.2 BTC to five different wallets); when it comes time to distribute payments, the UTXO is broken up into multiple payments and each party receives their allotted share. This feature enables payment pools that have ramifications for exchanges, mining pools, and coinjoin services. 
• Channel Factories: Using similar method as described above, channel factories enable Lightning Network users to open multiple channels with a single UTXO in such a way that they can open new channels with old channels without needing to close-out the old channels on-chain. 
• Non-Interactive Lightning Network Channels: Currently, both parties that are involved in funding a 2-2 multi-signature wallet for a Lightning Network payment channel need to be present during the channel’s opening to sign the pre-signed transaction that is used to close the channel. With CTV, the channel can be funded by only one party on the outset, and either party can initiate a closing transaction that pays out the proper amount to both participants without a cooperative close (i.e., without both parties needing to be present and online at the time of a channel close).

The above list isn’t exhaustive, and you can find other use cases for CTV on this website.

When and How Will CTV Be Activated?

There is currently no concrete timeline for CTV’s activation, as the Bitcoin developer community (and community at large) has not reached consensus on whether or not to adopt the upgrade. 

Activation discussions started circulating in 2022, but a stalemate ultimately led to Jeremy Rubin taking a break from Bitcoin Core development. Now that Rubin is back on the scene – and CTV has entered people’s purview alongside OP_CAT – there’s a chance that active Bitcoiners could push for its activation in the near future – but there’s no guarantee.

Less clear still is the method by which the Bitcoin community would seek to activate CTV or any other upgrade. Achieving code change consensus is a loose exercise whereby Bitcoin’s most active users hash out arguments for or against certain upgrade proposals until they more-or-less agree on which one to implement next. Activating these upgrades is a whole other issue entirely, and there are multiple ways to go about it.

 Bitcoin is a decentralized system, so the safest method to upgrade it – by which we mean, the way to ensure that nothing disrupts the blockchain or splits the transaction history by introducing a newer version that is incompatible with an older version – is through what is called a “soft fork.” In Bitcoin, a soft fork is a code change that is backwards compatible, meaning that a new version of the Bitcoin software’s rules will not conflict with older versions, as opposed to a hard-fork, where the new rules are not backwards compatible and thus result in a chain split that creates a new transaction history entirely. Bitcoin’s most recent big upgrades, Taproot (2021) and Segwit (2016), were both soft forks. 

Now, a soft fork provides a method for making a code change, but delivering that code change is another consensus quandary in its own right. Taproot was activated via a new method known as Speedy Trial, whereby mining pools signaled support for the upgrade by adding a signal bit within the blocks they mine; the signaling period lasted 3 months, and once 90% of blocks under a given difficulty period contained positive signals for Taproot, then the upgrade would be locked in. Speedy Trial was successful, and Taproot activated in November. 

Speedy Trial was somewhat controversial, with detractors saying that it placed too much veto power in the hands of miners to accept or reject Bitcoin upgrades. Time will tell whether the Bitcoin community opts for this method or the equally controversial user-activated soft fork in the future.