BIP 119: Unpacking CTV and How It Would Change Bitcoin

When you send a Bitcoin transaction currently, it goes a little something like this: You acquire an address from your recipient, you pick out which unspent transaction outputs (or UTXOs, what the cool folks call “coins”) you want to send, and you sign a transaction with your private key that proves you authorized the spend.

On-chain transactions more or less all work this way, except for special transactions that use Bitcoin’s scripting mechanism. With these transactions, users can utilize a special field to encode instructions for what happens to the coins in that transaction (timelocks are the classic example).

Right now, we can only use Bitcoin scripts to designate when or why a bitcoin is spent. But what if we could use them to designate how a bitcoin is spent? What if, for instance, we could tell a transaction to only spend a certain amount of bitcoin (BTC), or specify that a transaction can only send to a specific address?

Enter OP_CHECKTEMPLATEVERIFY (or CTV for short), a proposed Bitcoin upgrade which would introduce new scripting logic for how a transaction can spend specific coin(s).

This modularity could, among other things, improve wallet security because in the event of a hack, the attacker can only send the bitcoin to an address that you control.

Beyond security implications, CTV could also enable financial applications to be more easily deployed on Bitcoin, such as on-chain bitcoin options, using smart contracts, like discreet log contracts (DLCs).

Read more: Discreet Log Contracts Are Bringing Private, ‘Scriptless’ Smart Contracts to Bitcoin

Additionally, CTV could pave the way for “payment pools” and “channel factories,” Lightning Network applications that could be beneficial to custodians, exchanges and Lightning service providers. These payment pools are off-chain, so they could also furnish users with better privacy, as well.

All of these use cases, though, don’t guarantee that it’ll be Bitcoin’s next big upgrade.

Currently, bitcoin transactions go from point A to point B – or more accurately, they are locked up by user A until this user gives user B the ability to unlock them. Right now, we can only set a timelock for these coins.

“What could be useful under certain circumstances is that you might want to leave an instruction [for how your bitcoin is spent],” 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 Bitcoin’s code for review by the wider community. (Anyone can view these proposals, make their own and comment on BIPs via the Bitcoin Core GitHub.)

Read more: What Are BIPs and Why Do They Matter?

In BIP 119, Rubin introduces OP_Check_Template_Verify (CTV), a proposed upgrade to Bitcoin which creates new spending conditions that allow the receiver – not the sender – to set conditions for how a coin is spent.

If that doesn’t make sense right now, it will later. The important thing to note is that these new conditions could strengthen cold storage and create more private and scalable multiparty transactions and enable a slew of other applications that are generally marketed as bringing “smart contract” compatibility to Bitcoin (via discreet log contracts (DLCs), for one example).

“In the current Bitcoin locks, everything is limited to things like combination locks … with CTV, you get to do things with a little bit of statefulness, which allows you to say a little bit of what happens next,” said Rubin.

This “statefulness” means that coins with CTV-enabled rules have to have some record for how the coins are supposed to be spent. This record takes the form of a template (hence CheckTemplateVerify).

With CTV, users can create a template that creates specific spending conditions for a coin (UTXO).

Unless a broadcasted transaction meets the specifications for the CTV transaction template, 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 instruction in the Bitcoin transaction (in Bitcoin, an OP_CODE gives special instructions for script transactions). Again, when someone creates a transaction to spend the CTV coins, the transaction must match the OP_CTV template to succeed.

“You can think of OP_CTV like a friend who has a key for you, but will only sign the specific transactions you told them to sign for in advance. However, Bitcoin scripts can specify multiple alternatives. So it is possible to generate an address that says either (signature with key) or (transaction matching template 1) or (transaction matching template 2), which makes what you can do with CTV more flexible than just one particular transaction,” said Rubin.

Developers often refer to this transaction design – where an OP_CODE restricts how a transaction is spent – as a covenant. Perhaps the clearest use case for a covenant: improving cold storage and custody.

Users could create covenants that specify, for example, the coins in their vault could only be sent to a specific address, or that they can only spend 0.0025 BTC at a time (these are just a couple of examples that could help in the event of an attack).

CTV would give the Lightning Network new functionality as well, giving users the ability to create “payment pools” and “channel factories,” where thousands of users can lock up funds that are 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 win that reduces the block space all of these transactions would otherwise use.

And users can exit the channels whenever they want, “without requiring signatures from both parties,” Rubin writes in a post on one of his websites.

Payment pools could also have positive ramifications for user privacy. In addition to payment pools taking place off-chain, dozens to hundreds to thousands of users can have funds locked up in a transaction that is represented by a single coin on-chain, and they can each close their own channels at their own whims, 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.

Plenty of Bitcoin developers and stakeholders see benefits to CTV, but plenty of others say that the upgrade needs more careful thought and that there are alternatives to explore. Some opponents say that CTV is unnecessary or that proponents have not clearly articulated the benefits, while a more extreme and vocal minority has called the proposal an “attack on Bitcoin.”

Perhaps the most sobering and practical refutation is the fact that Taproot – the upgrade that makes CTV possible – just activated 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 stakeholders, like wallet providers and exchanges, to adopt the code; going further, the services that new upgrades enable do not build themselves, and it takes time for developers, entrepreneurs and companies to design products that rely on functionality that has never been used before.

Read more: Hard Forks vs Soft Forks

“Generally, I do not think Bitcoin is ready for any new soft-forked features at all in the short term. Taproot just arrived and there is already so much work to be done to adopt and utilize it,” Synonym CEO John Carvalho wrote in the Bitcoin Developer mailing list as a response to one of Rubin’s posts.

Others feel as if prioritizing CTV makes sense right now. For the more cynical, Big Brother is keeping a closer eye on Bitcoin and its users than ever, and they worry time is running out to implement upgrades which give users greater control over their coins (and greater privacy).

For Rubin, it’s a matter of giving people improved tools, particularly privacy tools, especially those who live under stringent financial surveillance and control.

“Imagine a future where people are targeted for having bitcoin because we did not have sufficient privacy,” Rubin said. “That worries me a lot. A lot of the benefit of payment pools is not just in scalability, but in privacy too, because they keep data off-chain.”

For CTV proponents, the code is more or less vetted (there’s been a 5.5 BTC bounty on CTV for nearly six months) and the arguments against it seem to be “we need more time to evaluate alternatives.”

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 much complementary. They have some overlap, but they are not exact ways to achieve the same end, and they were proposed in different contexts. I never had the impression that they were competitors,” said Decker.

All of this, of course, assumes the wider Bitcoin community wants these features.

But what is “Bitcoin’s wider community,” anyway? That’s part of the problem with these debates.

Bitcoin’s user base spans every continent except Antarctica, and the forum for debate includes social media, email lists and messaging groups. As bitcoin’s price has grown over the years, and the numbers of its active community swells, consensus has become increasingly unwieldy – especially considering your average person’s capacity to fully grasp the minutiae of these changes.

It’s a lot easier to drum up support for an upgrade if you campaign and educate, so Rubin has been on social media attempting to rally support for CTV (his Twitter name at one point read “BIP 119 marketing department”).

Rubin’s Twitter name change was done very much tongue in cheek because many active bitcoiners were put off by his advocacy. For sure, debate around the BIP 119 has become acidic. Its designer doesn’t mind people scrutinizing his work. What he doesn’t want, though, is undue concern from those who lack the literacy to understand CTV on a micro level.

“It’s fantastic that there are so many people who care so deeply about Bitcoin and will go to the mat to defend it,” Rubin said. That is very good. In this case, a lot of that concern is misplaced, although I understand where a lot of it comes from.”

Avid bitcoiners can be ornery, highly skeptical, and dogged in their defense of orange coin. Some of BIP 119’s opponents don’t like the fact that Rubin is advocating for an upgrade he designed (for his part, Rubin has tweeted to the effect that he doesn’t care what gets activated, but something needs to happen if privacy and custody solutions are to improve).

While the kernel of the debate may be popping with discussion about BIP 119, the fact that CTV’s critics are particularly worked up over Rubin’s advocacy of BIP 119 puts a larger debate into focus about Bitcoin’s rough consensus. Who decides upgrades? When is code “ready” to ship? And what’s the best way to activate a soft fork to make sure nothing funky happens?

With CTV and other promising soft forks like APO waiting in the dugout for their turn (if ever) at bat, a new ballgame for Bitcoin’s rough consensus on protocol evolution is in the opening inning.

And even though it looks like those who disagree are on opposite teams, ultimately everyone is working toward the same goal. They are just puzzling out which rules they want to play by, and that’s OK because “this is the work,” Rubin said, that’s required to reach a rough consensus.

“The developers who disagree on this, we’re all friends. … Bitcoin is a family, a big dysfunctional family. Ultimately we really are trying to achieve the same thing, we just don’t agree on the way to get there. If one of these ways demonstrated that it was the best way to get there, then there would be more cohesion.”