For those looking to wrap their head around BIP-119 this article seeks to shed some light on the discussion around the new bitcoin improvement proposal.
If you prefer to read up and take a look at the sources beforehand we can recommend the website put together by Bitcoin Gandalf www.bip119.com. You will find links to the original proposal as well as discussion and podcasts by experts.
Is it crucial for everyone bitcoin holder to understand BIP 119?
Bitcoin upgrades need a lot of consensus. From node operators and miners but also from users. Therefore having a rough understanding and following the discussion should not be dismissed. You might not be able to evaluate the pro’s and con’s on a technical level (really only a handful of people can) but you will be able to determine a sentiment and learn on the go.
Without a doubt, the more you understand, the better you can form your own opinion on BIP-119.
BIP-119 is supposed to introduce a new function into the Bitcoin protocol. Politics and technology are closely intertwined in the discussion. 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 be extremely emotional about technological details. Things that are bohemian hamlets to the rest of the world can cause storms of excitement or outrage among Bitcoiners. Nowhere else does technology become so political.
The latest battleground is BIP-119, which introduces OP_CHECKTEMPLATEVERIFY (CTV). It has been heating up the scene 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’re working 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 has to submit their proposal in a certain format so that it can be discussed by the core developers. Only what is a BIP has a chance of becoming reality in Bitcoin.
With BIP-119, developer Jeremy Rubin proposes to introduce a new Op_Code, namely OP_CHECKTEMPLATEVERIFY (CTV). BIP was published in the official Bitcoin Core repository in mid-2020.
An Op_Code means a kind of command of Bitcoin’s scripting language. There are various Op_Codes in every transaction. These define conditions for how the transferred coins can be spent. In the simplest case, the OP_Codes determine that the subsequent transaction must be signed with a certain key. This is the standard transaction.
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 was not possible before: OP_CHECKTEMPLATEVERIFY (CTV).
But what does CTV enable? The answer is “covenants”.
Covenants
Covenants is a technical term from the British legal system. According to Wikipedia, it refers to “a unilaterally binding promise made in the special private deed form of deed.”
For Bitcoin, this means: One can use CTV, GDP explains, to “form transactions that have a limited use in the future.” One can not only define with which key the subsequent transaction is to be signed, but also which properties it should have. So you don’t just define 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 it does, the transaction is valid.
CTV allows you to formulate very precise conditions for subsequent transactions. This can affect almost every element of a transaction: Inputs and outputs, locktime, the scripts, the value and much more.
Covenants are, explains Jeremy Rubin in BIP, “restrictions on how a coin can be spent other than through possession of the key”. But what are they good for?
Vaulting, congestion controls, non-interactive channels.
Jeremy Rubin explains what you can do with covenants with a few examples:
- You can form a vault (literally, a safe room): A transaction is only valid if the recipient is a specific address or belongs to a set of addresses.
- One can construct “non-interactive payment channels”. Until now, in the Lightning network, both sides have to act for a transaction to flow through a payment channel. With covenants, it is possible to create payment channels where only one side has to be active, so that the other can even be offline. Exactly how this works is complex, but if it does, it would be a scoop.
- An exchange can form what Rubin calls a “congestion control”: it sends a transaction that bundles many transactions, but waits until the fees have dropped to trigger it with another, smaller transaction.
- Mining pools could be formed where the payout of proceeds does not depend on the operator: pools with no central third party to trust.
- More esoteric is the suggestion of placing bets on softforks, or creating larger Hashed Time Locked Contracts (HTLCS) in a more secure way (HTLCS are an essential part of Lightning).
Is there really a need for this?
The offline transactions for Lightning seem like a huge win. They would be a gamechanger. We could argue they alone are enough reason to support BIP-119.
But with all the other applications Rubin outlines, it’s questionable whether you really need them.
The Vaults sound good at first glance. But are they really anything other than a time-shifted multisig? Do they really have advantages over what is already possible?
And do exchanges need the congestion control Jeremy outlined? Can’t they just wait until fees are low to form a transaction?
With P2Pool and Braiins from Slush, we already have models of slightly more decentralised mining pools. Does CTV really bring any significant advantage here? And is the misappropriation of block proceeds by pools even a problem?
And so on. So does CTV really need it? Especially after Bitcoin has only just received Taproot, which is still far from reaching wallets and, as the brilliant Taro shows, is also far from being exhausted?
And anyway, why is Jeremy Rubin silent on the obvious and most obvious application – earmarked transactions? In other words, whitelists? Is it because CTV is a powerful tool to exert control – and that this is precisely what frightens rather than excites many?
Recursive blacklists
The discourse on CTV that has erupted in recent weeks divides in a curious way: On one side, technically competent developers discuss the politics, and on the other, politically gifted influencers discuss the technology.
The most obvious and perhaps strongest criticism is voiced by the mother of all Bitcoin influencers, Andreas Antonopolous. With him, it gains the vehemence with which only Bitcoiners can react to technological details.
Andreas fears that covenants will introduce whitelists. The vaults proposed by Rubin already do this, and from there it is only a leap to governments obliging banks and stock exchanges to only transfer funds to addresses on a whitelist.
What’s worse is that recursive whitelists will also become possible: A subsequent transaction is only valid if it goes to an address on the whitelist AND if it also sets a whitelist. Once transferred, bitcoins could never escape from this “walled garden”. CTV therefore threatens, Andreas dramatises, to kill Bitcoin.
Update note: Apparently recursive whitelists are not possible. Whether that’s because they never were, or whether it was changed after criticism, I don’t know just yet.
The block trainer takes this criticism a bit 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 to which one is allowed to send, a blacklist addresses to which one is not allowed to send. With a blacklist, everything is allowed that is not forbidden; with a whitelist, everything is forbidden that is not allowed.
Most importantly: as far as I can see, CTV does not allow blacklists because it only allows positive conditions, not negative ones. The block trainer also admits this in a subsequent video.
“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 bearable and would probably be accepted by users. How many people are really affected by not being able to send bitcoins to an address blacklisted by the US Treasury? A minority. And even if they are – those affected can simply form a new address that is not blacklisted.
With blacklists, onchain 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 unbearable. They are like a pot that heats up immediately so that the frog hops out. A coin that is forever restricted by recursive covenants will necessarily be worth less than other coins. An exchange that sells it without informing its customer is, in the worst case, liable to prosecution and will in any case lose the trust of its customers.
In the mailing list, Darosier sums this up perfectly: “How is this different from paying you with an altcoin?”. It feels to me like 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 lost.”
In general, one wonders how this is supposed to scale. If you only write 10-20 possible addresses into the whitelist, the coin is completely useless; if you write in, say, 1000, that inflates the transaction by 32 kilobytes, which becomes a pretty expensive exercise and doesn’t scale at all.
Anyway, CTV doesn’t enable anything fundamentally new here. One could also set up “walled gardens” with simple multisig transactions, in which the BaFin or the FATF, for example, have to co-sign every transaction. This would be just as effective in practice as a whitelist with CTV, would scale much better and would also be much more practical, as one can also update the blacklists or whitelists continuously.
For these reasons, recursive whitelists play almost no role at all in the developers’ discussions. Nevertheless, the discussion is heated.
“I don’t understand why you think CTV is ‘ ready for use’ in Bitcoin.”
The debate became slightly toxic back in January 2022, when Jeremy Rubin tried to convince core developers to initiate the activation of CTV.
Several prominent developers rebuffed him in response. Blockstream CEO Adam Back, for example, wrote on 3 January 2022 that further analyses of the protocol and of “well thought-out alternatives” were necessary.
The mailing list continues in a similar vein. Peter Todd, for example, calls BIP-119 an “immature idea” and Jeremy’s implementation “inadequate.” He insists that it allows for possible DoS attacks.
One could go on for a long time. Criticism and rejection hailed in January. It is also noticeable that at no point is the issue whether covenants per se are desirable or not. There seems to be a consensus that their benefit outweighs the possible harm.
Criticism of the content is also sparse. It is not so much about the content, but about the form – about HOW to change the Bitcoin protocol.
Jeremy Rubin tried to convince the other developers in the following months. But he obviously did not succeed. And with that, the debate reached the hot, toxic phase.
“This is 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 and an activation mechanism.
One should know the following: A new Op_Code represents a change to the protocol. This is a not insignificant intervention, which in Core usually takes place through a softfork, as in SegWit or Taproot. A softfork means that ALL miners must use the code, as blocks created with the old code become invalid.
To activate the softfork, Rubin uses the Speedy Trial mechanism. This has already been used with Taproot. It works like this: If 90 percent of the miners signal approval over a period of about two weeks (2016 blocks or a Difficulty epoch), the upgrade is activated. If, on the other hand, three months pass without this threshold being reached, the attempt is considered a failure.
Speedy Trial, Rubin explains, allows a decision to be reached quickly. And he wants that decision. He’s been staying 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 apparently frustrated with the core developers: “I asked the maintainers for clear statements on what their requirements are for the CTV pull request, but I was rebuffed with no clear criteria, yet with the explanation that discussions about softforks are not the maintainers’ responsibility.”
He said he was surprised at first, but then realised, “It is not the fault of the maintainers that they cannot give me guidance. This is how it has to be.” Because when 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 releasing softforks independently and having them accepted by the wider community.”
Sounds fair and convincing, right? But the Core developers see it differently.
It’s not about the technology, it’s about the politics
Matt Corallo has very clear words on the mailing list, “Enabling CTV or trying to find a way to force it into Bitcoin is hurtful and short-sighted at this stage. Worse, it sets an incredibly unfavourable precedent about how we think about changes to Bitcoin and preserving Bitcoin’s culture of safe and careful design.”
And Adam Back follows up on Twitter, “Disappointing to see someone try to override or ignore reviews and other rational arguments.” And so on. The whole thing heated up to the above videos accusing Jeremy of using BIP-119 to destroy Bitcoins.
The developer has apparently crossed a red line. But this is not about the goal of BIP-119, at least among his colleagues, nor is it about technical flaws.
Rather – and this is of course frustrating for Jeremy – it is about process. Not about technology, but about politics.
The demystification of the softfork
In some ways, the Bitcoin community’s glorification of softforks is now taking revenge. This started in the wake of the Blocksize Wars, when the scene rejected a hardfork to increase the block size.
Softforks were presented as a soft, harmless alternative to hardforks. It has been clear for a long time that they are a very dangerous and also undemocratic instrument.
You have to know the difference between soft and hard forks. A hardfork is a “non-backward compatible” upgrade. Any node that does not go along loses consensus. It is out. To be successful, a hardfork needs the support not only of the miners, but also of the community and full nodes. This makes it democratic in a way.
A softfork, on the other hand, is “backwards compatible” for the full nodes. Only the miners have to follow suit. The full nodes don’t get anything out of it if they don’t go along with the upgrade. They continue to imagine they understand and validate all transactions, even though they no longer do so for the transactions enabled by the soft fork.
When Bitcoiners claim that their full node preserves the stability of the rules, this only applies to rules that are changed via hardfork. A soft fork undermines this mechanism. It makes the full node believe that it is verifying the validity of a transaction, while it does not understand the essential part of it. What is at stake sneaks through the radar of the ful node. A soft fork removes the Full Node’s say. If one wants to attack Bitcoin, for example by introducing onchain whitelists, a softfork would be a much more targeted method.
Jeremy Rubin has thus triggered the discussion that was long overdue in the Bitcoin community. His push has disenchanted the softfork, even if this has yet to reach the wider scene.
Why isn’t CTV allowed to do what Taproot was?
You could put the ideology Jeremy is running against this way: An upgrade with far-reaching consequences – any protocol change – SHOULD be toxic. Dissent SHOULD be the default, consensus for rule changes SHOULD be hard won.
Stability, not feature richness or flexibility, is what matters in Bitcoin. That is the ideology. The ideal is the ossified protocol that will never be changed again.
But why is this discussion ignited by BIP-119? Why did Taproot go through so well, even though it is also a softfork that was also enabled with Speedy Trial?
The answer again lies in the form: Taproot was planned for longer and discussed more intensively, including the process of activating the softfork. Taproot was also conceived and implemented by widely known Bitcoin veterans – Gregory Maxwell and Pieter Wuille.
CTV, on the other hand, is by Jeremy Rubins, a dedicated but much less well-known developer. He has not sat out the discussion, but cut it off by pushing for activation and now even trying to force it against the consensus of the developers. This brings back memories of Mike Hearn and BitcoinXT …
The way CTV is being activated seems like an attack. Maybe not like an attack per se. But it acts like a method that can also be misused for an attack. Therefore, rejection, dissent and drama is the only option, as unpleasant as this is for Jeremy and all in favor of covenants.
