Erik Weijers, a year ago
A heated debate rages in the Bitcoin community. It is about a new improvement proposal: BIP119. The disagreement mainly concerns the question of how quickly this proposal can be pushed through or whether a broad consensus must first be reached.
Bitcoin's latest upgrade, Taproot, was preceded by years of wide-ranging debate and testing. So there was already quite a lot of unanimity before the activation mechanism of the upgrade was set in motion. In this case, there is no such agreement. The discussion about BIP119 has been heating up especially in the last few weeks. Behind the question of the speed with which the proposal should be put to the vote is a more fundamental question. Namely, the question of what Bitcoin essentially is.
BIP119 (Bitcoin Improvement Proposal 119) would give Bitcoin more options to run smart contract-like functionality. Transactions would become more programmable as a result. For example:
To do all this, BIP119 uses covenants. These are restrictions in a script that set the conditions for how a transaction output can be spent.
The concern is that the strength of covenants will cause harmful side effects. The creator of BIP119, Jeremy Rubin, claims that his so-called Check Template Verify is a minimalist implementation of covenants. It is precisely about this point that there is concern, as the great Bitcoin explainer Andreas Antonopoulos points out in this Q&A.
Because where does the power of those covenants end? A challenge with covenants is that it allows for a whole series of recursive and thus difficult to foresee restrictions: 'this transaction output can only be issued by this covenant in a transaction that also has a covenant, which ...' Etcetera, as a nesting of Babushka dolls.
And you might already be slightly alarmed… restrictions on transactions. That has the downside that - unintentionally or not, far in the future or not - Bitcoin cannot be spent without the consent of a covenant. In fact, it could lead to a whitelist or blacklist that Bitcoin may or may not be sent to. That's a feature that could be exploited and that we might not want: it makes Bitcoin less exchangeable (fungible). It would in effect lead to two types of Bitcoin: Bitcoin that can be sent anywhere and Bitcoin that can only be sent to whitelisted addresses.
Beneath the disagreement over the potential implications of BIP119 lies the deeper question of what Bitcoin should be. Do we also want to turn Bitcoin into a smart contract platform or should we leave that to, for example, Ethereum? Isn't it enough for Bitcoin to do what it does best, which is simply to be hard money? Aren't we introducing all kinds of vulnerabilities if we add too much programmability?
The point of contention with which we started this article is procedural but no less essential to what makes Bitcoin anti-fragile. Jeremy Rubin wants to bring BIP119 to the miners in a speedy trial: that would give miners four months to cast their vote. If at least 95% is in favour, the new feature is 'locked in' and will be activated again a few months later. That would be incredibly fast for Bitcoin.
Should this speedy trial come to pass and should the majority of the miners vote in favour - which is not very likely - then this will undoubtedly receive pushback from node operators. These are mostly regular users who run a copy of the Bitcoin blockchain. They have at least as much power as the miners in allowing or blocking a new BIP. Anyone running a node could decide to reject blocks of miners who voted for it.
Thus, Bitcoin's consensus mechanism depends on the vote of multiple types of parties and is therefore highly conservative. It probably won't prove possible to push through BIP119 quickly.