BIP-119: The Bitcoin Soft Fork Proposal

The Bitcoin scene is currently heatedly debating BIP-119, which is intended to introduce a new function into the Bitcoin protocol. In the discussion, politics and technology are closely intertwined. We explain what it’s all about – and why it’s so important.

One of the most outstanding characteristics of Bitcoiners is that they can react extremely emotionally to technological details. Things that are bohemian hamlets to the rest of the world can cause storms of enthusiasm or outrage from Bitcoiners. Nowhere else does technology get so political? The newest battleground is BIP-119, which introduces OP_CHECKTEMPLATEVERIFY (CTV). The scene has been heating up for about two weeks. You probably don’t understand what these words mean. And you probably understand even less why there is such a fuss about it. So we work our way through the drama bit by bit.

BIP-119

First of all, BIP-119 is a “Bitcoin Improvement Proposal”. Anyone who wants to change Bitcoin must submit their proposal in a specific format so that it can be discussed by the core developers. Only what is a GDP has a chance to become a reality in Bitcoin. With BIP-119, developer Jeremy Rubin proposes to introduce a new Op_Code, namely OP_CHECKTEMPLATEVERIFY (CTV). BIP was published in Bitcoin Core’s official repository in mid-2020.

An Op_Code means a kind of command of the Bitcoin scripting language. There are various Op_Codes in every transaction. These define conditions on how the transferred coins can be spent further. In the simplest case, the OP_Codes determine that the subsequent transaction must be signed with a specific key. This is the standard transaction.  As described by the Boletim Bitcoin portal. So Jeremy Rubin wants to add a new OP_Code with BIP-119. He wants to allow Bitcoin’s scripting language to perform an operation that wasn’t possible before OP_CHECKTEMPLATEVERIFY (CTV). But what does CTV enable? The answer is covenants.

Covenants

Covenants is a technical term from British law. According to Wikipedia, it refers to ” a unilaterally binding promise that is made in the special private notarization form of the deed .” For Bitcoin, this means that you can use CTV, explains BIP, “to form transactions that will have limited use in the future.” You can not only define which key is to be used to sign the subsequent transaction, but also which properties it should have. So you not only determine WHO can spend the money – but also HOW.

On a purely technical level, the Op_Code does the following: It loads an object of 32 bytes and checks whether the hash of the transaction corresponds to this object. Only if he does this is the transaction valid. CTV makes it possible to formulate very precise conditions for follow-up transactions. This can affect almost every element of a transaction: inputs and outputs, lock time, scripts, value, and much more. Covenants are, explains Jeremy Rubin in BIP, “restrictions on how a coin can be spent other than by possession of the key”. But what are they good for?

Vaults, congestion controls, non-interactive channels

Jeremy Rubin explains with a few examples what you can do with covenants:

• You can create a vault(literally: a vault): a transaction is only valid if the recipient is a specific address or belongs to a set of addresses.
• You can construct ” non-interactive payment channels”. So far, both sides have had to act in the Lightning network for a transaction to flow through a payment channel. With covenants, it is possible to form payment channels where only one side has to be active so that the other side can even be offline. Exactly how this works is complex, but if it works it would be a smash hit.
• An exchange can form what Rubin calls a “congestion control”: It sends a transaction that bundles many transactions together, but waits until fees have gone down, then triggers it with another, smaller transaction.
• One could form mining pools where the payout of the proceeds does not depend on the operator: pools without a central third party that one has to trust.
• Somewhat more esoteric is the suggestion of placing bets on soft forks, or creating larger Hashed Time Locked Contracts (HTLCS) more securely (HTLCS are an essential part of Lightning).

Do you need that?

The offline transactions for Lightning seem like a massive win. You would be a game changer. I would say they alone are enough to make you want BIP-119. With all the other applications outlined by Rubin, however, it is questionable whether they are needed. The Vaults sound good at first glance. But are they anything other than a time-shifted multisig? Do they have advantages over what is already possible? And do stock exchanges need the congestion control outlined by Jeremy? Can’t they just wait until the fees are low to form a transaction?

With P2Pool and Slush‘s Braiins, we already have models of somewhat more decentralized mining pools. Does CTV bring a significant advantage here? And is block revenue misappropriation by pools even a problem? And so forth. So does CTV need it? Especially after Bitcoin has only just received Taproot, which is far from arriving in wallets and, as the brilliant Taro shows, is also far from being exhausted? And anyway, why is Jeremy Rubin ignoring the obvious and most obvious application – earmarked transactions? So white lists? Is it because CTV is a powerful tool for exercising control – and that’s what scares many more than it excites?

Recursive blacklists

The discourse on CTV that has erupted in recent weeks splits curiously: on one side, tech-savvy developers are discussing politics, and on the other, politically-savvy influencers are discussing technology.

The most obvious and perhaps strongest criticism comes from the mother of all Bitcoin influencers, Andreas Antonopolous. With him, she gains that violence with which only Bitcoiners can react to technological details. Andreas fears that covenants will introduce whitelists. The vaults Rubin proposed already do, and it’s a short jump from there to governments requiring banks and exchanges to only send transfers to whitelisted addresses. Worse still, recursive whitelisting is also possible: a subsequent transaction is only valid if it goes to a whitelisted address AND if it is also whitelisted. Once transferred, bitcoins could never escape from this walled garden. CTV is therefore threatening to kill Bitcoin, says Andreas dramatizing.

The block trainer takes this criticism a little further: he too fears that BIP-119 could destroy Bitcoin. In doing so, he exchanges whitelists for blacklists. The difference between black and white is fundamental. A whitelist contains addresses you are allowed to send to, a blacklist contains addresses you are not allowed to send to. With a blacklist everything is allowed that is not forbidden; a whitelist bans everything that is not allowed. Most importantly, as far as I can see, CTV doesn’t allow for blacklists, as it only allows positive conditions, not negative ones.

“If someone can force you to use a different currency, you’re already lost.

The difference between whitelists and blacklists is crucial. A blacklist is much less bad – and therefore much worse. A blacklist is tolerable and would probably be accepted by the users. How many people are affected by not being able to send Bitcoin to an address that is on the US Treasury Department blacklists? A minority. And even if they do, those affected can simply form a new address that is not on a blacklist.

With blacklists, on-chain restrictions could eat into Bitcoin bit by bit and with the goodwill of the community. It would be like the frog in the cooking pot that slowly heats up. That’s why they would be worse than whitelists. Whitelists, on the other hand, are intolerable. They’re like a pot that heats up instantly so the frog hops out. A coin forever constrained by recursive covenants will necessarily be worth less than other coins. A stock exchange that sells it without informing its customers is, in the worst case, liable to prosecution and will in any case lose the customers’ trust.

Darosier sums this up perfectly in the mailing list: “How is that different from being paid with an altcoin? It seems to me that the ability to say ‘Sorry, your money isn’t good enough for me here’ is at the core of Bitcoin’s security. If someone can force you to use another currency, you’re already doomed. ” In general, one wonders how this is supposed to scale. If you only whitelist 10-20 possible addresses, the coin is completely useless; for example, writing 1000 in bloats the transaction by 32 kilobytes, which becomes a fairly expensive exercise and doesn’t scale at all.

In any case, CTV does not enable anything fundamentally new here. One could also set up “walled gardens” with simple multi-sig transactions, for example by having BaFin or the FATF sign every transaction. In practice, that would be just as effective as a whitelist with CTV, would scale much better, and would also be much more practical, since you can also update the blacklists or whitelists continuously. For these reasons, recursive whitelists play almost no part in developer discussions. Nonetheless, the discussion is intense.

I don’t understand why you think CTV is ‘ready for action’ in bitcoin.

The debate became slightly toxic as early as January 2022. At that time, Jeremy Rubin was trying to convince the core developers to initiate the activation of CTV. Several prominent developers then gave him a rebuff. For example, Blockstream CEO Adam Back wrote on January 3, 2022, that further analysis of the protocol and “well thought-out alternatives” were necessary.

ChainCodeLabs’ Matt Corallo put it more bluntly: “I don’t understand why you think CTV is ‘ready for action’ in Bitcoin. At no point in Bitcoin’s history has it been ok to bring things to consensus […] without considering alternatives. The push for CTV feels… wrong, in every way imaginable. Rather than collaborative development, it feels like ‘I built this, let’s do it’ while ignoring any feedback. Honestly, for that alone, it should die on the try. The developer Mark Erhardt (Murch) is also skeptical: “Protocol changes have to be safe, useful, desirable, and the best variant. Selling the absence of criticism as silent support is misleading. A proposal must generate interest to get reviews. This proposal would change the philosophy of how transactions work and I don’t see experts supporting it.”

The same goes for the mailing list. For example, Peter Todd calls BIP-119 an “immature idea” and Jeremy’s implementation “inadequate.” He insists it enables possible DoS attacks. One could go on for a long time. It rained criticism and rejection in January. It is also clear that at no point is it a question of whether covenants are desirable or not. There seems to be a consensus that their benefits outweigh the potential harm. The substantive-technical criticism is also sparse. It’s less about the content and more about the form – about HOW to change the Bitcoin protocol. Jeremy Rubin tried to convince the other developers in the following months. But he didn’t succeed. And with that, the debate reached the hot, toxic stage.

That’s how it has to be.

On his blog, Jeremy announces that he will release a version of Bitcoin Core that includes the new OP_Code as well as an activation mechanism. One should know the following: A new Op_Code represents a change in the protocol. This is a not insignificant intrusion, which usually takes place in Core through a soft fork, like in SegWit or Taproot. A soft fork means ALL miners must use the code, as blocks generated with the old code become invalid. To activate the soft fork, Rubin uses the Speedy Trial mechanism. This was already used by Taproot. It works like this: If 90 percent of the miners signal approval over about two weeks (2016 blocks or one difficulty epoch), the upgrade is activated. If, on the other hand, three months go by without this threshold being reached, the attempt is deemed to have failed.

Speedy Trial allows, explains Rubin, to come to a decision quickly. And he wants that decision. He has been involved with CTV for a long time and he also has other goals and plans (with Bitcoin). The upgrade is programmed, and he wants to close this chapter instead of getting stuck in endless discussions. Rubin is frustrated with the core developers: “I asked the maintainers for clear statements about their requirements for the CTV pull request, but I was rejected without clear criteria, but with the explanation that discussions about soft forks are not the responsibility of the maintainers.” He was surprised at first but then realized: “It’s not the maintainers’ fault that they can’t guide me. That’s the way it has to be.” Because when the core developers decide how to change the protocol, they put themselves in a dangerous position. “The only way Bitcoin Core can remain apolitical is by having soft forks released independently and accepted by the wider community.” Sounds fair and convincing, right? But the core developers see it differently.

It’s not about technology, it’s about politics

Matt Corallo is very clear on the mailing list: “Activating CTV or finding a way to force it into Bitcoin is hurtful and short-sighted at this stage. Worse, it sets an incredibly unfavorable precedent for how we think about changing Bitcoin and preserving Bitcoin’s culture of safe and careful design.” And Adam Back tweeted: “It’s disappointing to see someone trying to override or ignore reviews and other rational arguments.” And so on. This all heated up to the aforementioned videos accusing Jeremy of using BIP-119 to destroy bitcoins. The developer has crossed a red line. However, at least in the case of his colleagues, this is not about the goal of BIP-119, and it is also not about technical shortcomings. It’s more about – and this is of course frustrating for Jeremy – about the process. Not about technology, but about politics.

The disenchantment of the soft fork

In a way, the Bitcoin community’s glorification of soft forks is now taking its revenge. This started in the wake of the blocksize wars when the scene rejected a hard fork to increase the block size.

Soft forks were presented as a gentle, harmless alternative to hard forks. It has long been clear that they are a very dangerous and also undemocratic instrument. You have to know the difference between soft and hard forks. A hard fork is a “non-backward compatible” upgrade. Any node that doesn’t follow suit loses the consensus. He is outside. To be successful, a hard fork not only needs the support of the miners but also of the community and the full nodes. That makes them democratic in a way. A soft fork, on the other hand, is “downward compatible” with the full nodes. Only the miners have to go along with it. The full nodes don’t even notice if they don’t go through with the upgrade. They continue to pretend to understand and validate all transactions, although they no longer do so for the transactions made possible by the soft fork.

When bitcoiners claim that their full node maintains the stability of the rules, this only applies to rules that are changed via a hard fork. A soft fork undermines this mechanism. It fools the full node into verifying the validity of a transaction, while it does not even understand the essential part of it. What is at stake is sneaking through the Ful Node’s radar. A soft fork deprives the full node of the right to have a say. If you want to attack Bitcoin, for example by introducing on-chain whitelists, a soft fork would be a much more effective method. Jeremy Rubin thus triggered the discussion that was long overdue in the Bitcoin community. His advance has disenchanted the soft fork, even if this has yet to arrive in the broader scene.

Why can’t CTV do what Taproot was allowed to do?

Another way of stating the ideology Jeremy is running against is that an upgrade with far-reaching consequences – any protocol change – SHOULD be toxic. Dissent SHOULD be the standard, consensus for rule changes SHOULD be hard to come by. Not feature richness or flexibility, but stability is what matters with Bitcoin. That’s the ideology. The idea is the ossified protocol that will never be changed again. But why is this discussion sparked by BIP-119? Why did Taproot pass so well even though it’s also a soft fork that was also enabled with Speedy Trial?

Again, the answer lies in the form: Taproot was planned longer and discussed more intensively, including the procedure for activating the soft fork. Taproot was also conceived and implemented by well-known Bitcoin veterans – Gregory Maxwell and Pieter Wuille. CTV, on the other hand, is by Jeremy Rubins, a dedicated but much lesser-known developer. He didn’t sit out the discussion, but cut it short by pushing for activation and now even trying to force it against the consensus of developers. This brings back memories of Mike Hearn and BitcoinXT… The way CTV activates acts like an attack. Maybe not like an attack per se. But it seems like a method that can also be abused for an attack. So denial, dissent, and drama are the only options, uncomfortable as it is for Jeremy and anyone who wants covenants.