Currently, when you send a bitcoin transaction, it goes something like this: You get an address from your recipient, you choose which unspent transaction outputs (or UTXOs, what the cool people call "coins") you want to send, and you sign a transaction with your private key, which proves that you authorized the output.
On-chain transactions more or less all work this way, except for special transactions that use Bitcoin's scripting mechanism. In these transactions, users can use a special field to encode instructions on what to do with the coins in that transaction (timelocks are the classic example).
Right now, we can only use bitcoin scripts to specify when or why a bitcoin is spent. But what if we could use them to specify how a bitcoin is spent? For example, what if we could tell a transaction to only spend a certain amount of bitcoin (BTC), or specify that a transaction can only be sent to a certain address?
This is where OP_CHECKTEMPLATEVERIFY (or CTV for short) comes in, a proposed bitcoin upgrade that would introduce new scripting logic for how a transaction can spend specific coins.
Among other things, this modularity could improve wallet security, since in the event of a hack, the attacker could only send bitcoin to an address you control.
Aside from the security implications, CTV could also enable easier deployment of financial applications on bitcoin, such as on-chain bitcoin options using smart contracts like discrete protocol contracts (DLCs).
In addition, CTV could pave the way for "payment pools" and "channel factories," Lightning Network applications that could benefit custodians, exchanges, and Lightning service providers. These payment pools are located outside the chain, so they could also offer users better data protection.
However, all of these use cases are no guarantee that this will be Bitcoin's next major upgrade.
BIP 119 and OP_CTV
Currently, Bitcoin transactions go from point A to point B - or more accurately, they are locked by user A until that user allows user B to unlock them. Right now, we can only set a time lock on these coins.
"What might be useful in certain circumstances is that you might want to leave instructions [on how to spend your bitcoin]," Jeremy Rubin told CoinDesk.
Rubin is the author of Bitcoin Improvement Proposal 119 (BIP 119); these BIPs are a way for Bitcoin contributors (professional and amateur coders alike) to propose changes to the Bitcoin code for review by the broader community. (Anyone can view these suggestions, make their own suggestions, and comment on BIPs via the Bitcoin Core GitHub.)
In BIP 119, Rubin introduces OP_Check_Template_Verify (CTV), a proposed upgrade for Bitcoin that creates new spending conditions that allow the receiver - rather than the sender - to set the terms for how a coin is spent.
If that doesn't make sense now, it will later. Importantly, these new terms could strengthen cold storage and create more private and scalable multi-party transactions, and enable a number of other applications that are commonly marketed as "smart contract" compatibility for Bitcoin (for example, via discrete protocol contracts (DLCs)).
In current bitcoin locks, everything is limited to things like combination locks ... "with CTV, you can do things with a certain amount of statefulness, which allows you to say a little bit about what's going to happen next," Rubin said.
This "statefulness" means that for coins with CTV-enabled rules, a record of how the coins are to be spent must be created. This record is in the form of a template (hence CheckTemplateVerify).
How CTV works
CTV allows users to create a template that specifies specific output conditions for a coin (UTXO).
If a transferred transaction does not meet the CTV transaction template specifications, no one can spend the coins associated with the template. Users embed this template in the script of a Bitcoin transaction and enforce it using instructions specified by the OP_CTV statement in the Bitcoin transaction (in Bitcoin, an OP_CODE gives specific instructions for script transactions). When someone creates a transaction to spend the FTV coins, the transaction must in turn match the OP_CTV template to be successful.
"You can think of OP_CTV as a friend who has a key for you, but only signs the specific transactions that you have told them in advance. Bitcoin scripts, however, can specify multiple alternatives. So it is possible to generate an address that is either (Signature with Key) or (Transaction Matching Template 1) or (Transaction Matching Template 2).
Developers often refer to this transaction design - where an OP_CODE constrains how a transaction is issued - as a covenant. Perhaps the clearest use case for a covenant is to improve cold storage and custody.
Users could create covenants that specify, for example, that the coins in their vault can only be sent to a specific address or that they can only spend 0.0025 BTC at a time (these are just a few examples that could be useful in the event of an attack).
CTV would also add new functionality to the Lightning Network by allowing users to create "payment pools" and "channel factories" where thousands of users can lock funds represented by a single UTXO in a single on-chain transaction.
Exchanges, custodians, and mining pools could use these channel factories to pay out thousands of users (on-chain) with a single UTXO (coin), a scaling gain that reduces the block space all these transactions would otherwise require.
And users can leave the channels at any time "without requiring signatures from either party," Rubin writes in a post on one of his websites.
Payment pools could also have positive implications for user privacy. In addition to payment pools taking place outside the bitcoin chain, dozens, hundreds or thousands of users can hold funds in a transaction represented by a single coin on the chain, and each of them can close their own channels as they see fit, making it harder overall to trace the funds.
Bitcoin mining pools could use these payment pools to manage payouts, or custodians and users could use them to create cold storage vaults.
Will CTV be bitcoin's next upgrade?
Many Bitcoin developers and enthusiasts see the benefits of CTV, but many others say the upgrade needs to be thought through more carefully and that there are alternatives that should be explored. Some opponents say CTV is unnecessary or that proponents have not clearly articulated the benefits, while an extreme and vocal minority has called the proposal an "attack on Bitcoin."
Perhaps the most sobering and practical rebuttal is the fact that Taproot - the upgrade that makes CTV possible - was only enabled last November and the ecosystem is still adopting it.
When a new feature like Segwit or Taproot is soft forked into Bitcoin, it's up to industry players like wallet providers and exchanges to adopt the code; moreover, the services that enable new upgrades don't evolve on their own, and it takes time for developers, entrepreneurs, and companies to design products that rely on features that have never been used before.
"In general, I don't think Bitcoin is ready for new soft forking features in the short term. Taproot has just emerged and there is already so much work to be done to adopt and use it," wrote Synonym CEO John Carvalho on the Bitcoin Developer mailing list in response to one of Rubin's posts.
Others believe that prioritizing CTV makes sense right now. For the more cynical among them, Big Brother is keeping a closer eye on Bitcoin and its users than ever before, and they worry that time is running out to implement upgrades that give users more control over their coins (and more privacy).
For Rubin, it's about giving people better tools, especially those living under strict financial monitoring and scrutiny.
"Imagine a future where people are targeted because of their bitcoin ownership because we didn't have adequate privacy," Rubin said. "That's a big concern for me. A big part of the benefit of payment pools is not just scalability, but privacy, because they keep data off-chain."
For CTV proponents, the code is more or less tried and true (there's been a 5.5 BTC bounty on CTV for almost six months), and the arguments against CTV seem to be: "We need more time to evaluate alternatives."
Alternatives to CTV
As for alternatives, some point to AnyPrevOutput (APO or BIP 118), another soft fork designed by Blockstream Core Lightning developer Christian Decker. Others, including Rubin and Decker, see each other's BIPs as complementary.
"That's always been my position - they are very complementary. They have some overlap, but they are not exact ways of achieving the same goal, and they have been proposed in different contexts. I never had the impression that they were competitors," Decker said.
All of this assumes, of course, that the Bitcoin community wants these features.
So why the wait?
But what is "the broader bitcoin community" anyway? That's part of the problem with these debates.
The Bitcoin user base spans every continent except Antarctica, and the forum for debate includes social media, email lists, and messaging groups. As the price of bitcoin has risen over the years and the number of active community swells, the consensus has become increasingly unwieldy - especially considering the average person is unable to understand the intricacies of these changes.
It's much easier to advocate for an upgrade when you're campaigning and educating. That's why Rubin has taken to social media to try to drum up support for CTV (his Twitter name was once "BIP 119 Marketing Department").
Rubin's Twitter name change was done tongue-in-cheek because many active Bitcoiners were put off by his involvement. Certainly, the debate over BIP 119 has turned sour. Its developer doesn't mind his work being questioned. What he doesn't want, however, is undue concern from those who don't have the knowledge to understand FTV on a micro level.
"It's fantastic that there are so many people who care about Bitcoin and are doing everything they can to defend it," Rubin said. That's very good. In this case, a lot of that concern is misplaced, though I understand where it's coming from.
Die-hard Bitcoin supporters can be very recalcitrant, extremely skeptical and stubborn in their defense of the orange money. Some opponents of BIP 119 don't like the fact that Rubin is advocating for an upgrade that he designed himself (for his part, Rubin has tweeted that he doesn't care what is enabled, but that something has to happen if privacy and custody solutions are to be improved).
While the core of the debate may be blossoming with the discussion of BIP 119, the fact that CTV's critics are particularly upset about Rubin's advocacy of BIP 119 brings into focus a larger debate about Bitcoin's rough consensus. Who decides on upgrades? When is code "ready" to ship? And what's the best way to activate a soft fork to make sure nothing bad happens?
With CTV and other promising soft forks like APO waiting their turn in the dugout (if ever), a new game for Bitcoin's rough consensus is protocol evolution in the first inning.
And even though it looks like those who disagree are playing on opposing teams, ultimately they're all working toward the same goal. They're just puzzling over what rules they want to play by, and that's fine, because "that's the work," Rubin said, that's needed to reach a rough consensus.
"The developers who disagree are all friends. ... Bitcoin is a family, a big dysfunctional family. At the end of the day, we're really trying to achieve the same thing, we just disagree on how to get there. If one of those paths showed that it was the best way to get there, then there would be more cohesion."