BIP 119 Isn’t an Attack on Bitcoin, but Speedy Trial Is

An upgrade to the Bitcoin protocol is generating yet another controversy that threatens to split the chain. This time, the issue is BIP-119, a proposal to add the OP_CHECKTEMPLATEVERIFY opcode via a softfork. While the proposed change is generally uncontroversial, the consensus mechanism for accepting the change has catalyzed renewed debate on who is in charge of the protocol.

BIP-119 introduces the OP_CHECKTEMPLATEVERIFY (CTV) opcode, which allows users to create transactions that have restricted use in the future. For example, a trust-minimized vault that can only send funds to a designated wallet. OP_CTV verifies that the hash of the spending transaction matches the value provided in the initial vaulting transaction. This is called a covenant.

These covenants are constrained by hashed data from a future transaction rather than private keys and signatures, thus they can also be useful for payment channels where a counterparty may be offline. Another possible application is for congestion control, where an exchange may need to send a batched transaction with many outputs, but wants to wait until transaction fees are lower. OP_CTV can be used to create a small single-output transaction that commits to a later multi-output transaction when the mempool is less full.

The idea of covenants is uncontroversial; the main issue surrounding BIP-119 is the strategy that is being used to promote its adoption. The introduction of a new opcode requires a softfork, similar to how Segregated Witness (SegWit) was added to the core protocol. BIP-119 was first proposed by Jeremy Rubin in 2020, and received minimal attention as developers were focused on other priorities. Last week, Rubin announced that he would soon release a software build that implements OP_CTV and a mechanism for activating it across the network. This took many by surprise.

The release parameters follow the Speedy Trial process, which requires that 90% of blocks mined within a difficulty interval (approximately two weeks) include a signal bit that indicates softfork readiness. Once the threshold is reached, the softfork will activate and OP_CTV-ready nodes will start enforcing the new rules. This places the activation decision squarely in the hands of miners.

Speedy Trial was used to successfully activate Taproot, so it is a bit hypocritical to criticize the process now. At the time, Taproot developers wanted to avoid another SegWit/BIP-9 scenario where miners intentionally block an update even though network nodes were ready. The fact that so many users actively supported SegWit presented a credible threat of a User Activated Soft Fork (UASF), where non-signalling blocks would be orphaned by the rest of the network. This threat ultimately forced miners to go along with the activation.

The SegWit activation process was messy and contentious, but protocol changes are not supposed to be easy. In hindsight, maybe all the friction and conflict was a feature, not a bug.