After the activation of SegWit on Litecoin last week, many are left scratching their heads about Bitcoin’s own protocol development and trying to figure out where things went wrong. For the first time in the cryptocurrency’s history, a major feature developed by Bitcoin developers and heralded as one of the protocol’s most significant improvement is being activated in altcoins first.
Was this outcome inevitable? If this can be considered a failure of our ecosystem, how can we learn from it and adapt so as to avoid it turning into an irreparable precedent? This post attempts to shed light on the dynamics that lead to this stalemate and presents an alternative idea which protects Bitcoin users’ interests and safeguards the evolution of the protocol going forward.
The case against BIP 9
Behind the activation principles of BIP9 and previous IsSuperMajority transition processes lies a fundamental assumption: miners must validate the content of the blocks they mine. This is important because it allows the network to move forward with new backwards compatible behaviours without requiring a lengthy upgrade process from a majority of economic nodes. Rather, nodes rely on a super majority of miners to orphan soft fork invalid blocks after the activation threshold has been reached.
A major issue with these techniques is that the signalling mechanism used by miners to announce support of the soft fork has no incidence on the enforcement of its rules. As such, the security of these schemes ultimately relies on the diligence of miners and their associated pools, a sort of gentlemen’s agreement. Miners must actively validate the new rules after activation otherwise they risk creating incompatible blocks and accidentally fork themselves off the network. Unfortunately, previous incidents have demonstrated that the reliability of these methods is limited. The infamous BIP66 fork was a costly demonstration of this. The consensus fault lead to a loss of funds for miners who built on top of the invalid chain and put users of non-upgraded software at a risk of being defrauded.
The aforementioned failure mode brings valuable perspective about the objectives of version signalling. Politicization of Bitcoin development has had the inevitable result of exploiting the deployment mechanism of soft forks as a bargaining chip, pitting users’ interests against those of mining pool operators. This context has fuelled a twisted interpretation of the signalling process which has lead to a great deal of confusion about the miners’ responsibilities. A procedure that was intended to provide guarantees about the secure deployment of new rules has turned into a democratic contest; granting voting and veto powers to a handful of centralized actors. Regardless of whether the miners’ incentives are aligned with those of users, this situation exposes them to coercion and undue lobbying. I highlighted this dynamic in a previous piece:
This scenario has concentrated the attack surface of the network around a specific group of participants: pool operators. While most of them are unarguably heavily invested in Bitcoin, they find themselves open to outside influences that may try to leverage their position to advance their own political agendas.
Finally, as pointed out by developer ShaolinFry in the UASF introductory post, the preferred supermajority threshold of 95% comes with the risk of having to deal with of “upgrade inertia”. Unless 51% of miners make the controversial decision to orphan the blocks of the “inactive” hashing power, the activation of soft forks can be significantly stalled only because of laggards. While this seems avoidable in the current state of things, increasing mining decentralization could inflate these concerns.
Rules validation: who watches the watchmen?
Remember that in the BIP 66 incident users running compatible software were not put at risk of accepting invalid blocks as confirmation. This is a salient point that begs to be repeated. Blocks produced by SPV mining pools building on top of incompatible versions were ignored by upgraded nodes. While soft forks can more easily be activated through the coordination of a miner supermajority, the network’s nodes and the economic majority behind them are ultimately the ones enforcing them.
In the example above, miners responsible for the “inadvertent” fork quickly realized their mistake and were strongly incentivized to correct their behaviour as every block they mined could not be used for payments; a large portion of the economy would deem them invalid. It’s important to note that the network was put at risk because miners were relied upon for upholding a secure transition which they failed to do.
There was a point in Bitcoin’s history where such responsibilities had not yet been granted to them. The BIP16 (P2SH) soft fork was one such case wherein the terms of activation were set around a flag day upgrade. Users were strongly incentivized to upgrade and validate for themselves.
In hindsight this deployment is widely considered to have been unnecessarily risky. The short window of time between the release of the compatible software and the activation date suggests a non-negligible portion of the network might have been vulnerable had some miners started extending a chain with invalid rules. Over time though, a vast enough majority of nodes upgraded to software supporting BIP16 rules so that any blocks including invalid transactions would be rejected by the network.
User Activated Soft forks (UASF) address the shortcomings of the BIP 9 activation method & improve the security of the kind of flag day upgrades seen early on in Bitcoin development. They empower users to activate features they desire by incentivizing miners to work for the economic majority and avoid the pitfalls of politics. Assuming an adequate transition period, they provide a safe way to introduce new behaviours without relying on miners coordination. It’s in the latter’s best economic interest to extend the “most work” valid chain as determined by the consensus of network peers.
Perils of premature protocol ossification
What we have today is a broken activation system. — Shaolinfry, Litecoin China Roundtable and UASF
One could argue the conversation around the miners’ activation of SegWit has run its course. Despite overwhelming support by every notable companies, wallets & developers, a group of mining pools have dug their heels in and now stand between users and a myriad of improvements to Bitcoin’s scalability. Exhaustion has lead many participants to attempt various compromises that ignore that SegWit is the only pragmatic solution on the table today. These type of “people compromises” are not an acceptable outcome of protocol development.
Even worse is the “horse-trading” sort of compromise: “I object to your proposal for such-and-so reasons. You object to my proposal for this-and-that reason. Neither of us agree. If you stop objecting to my proposal, I’ll stop objecting to your proposal and we’ll put them both in.” That again results in an “agreement” of sorts, but instead of just one outstanding unaddressed issue, this sort of compromise results in two, again ignoring them for the sake of expedience. —Internet Engineering Task Force (IETF), On Consensus and Humming in the IETF, 2014
In this case, capitulation would expose every future proposals to the same political wars and endangers the long term progress of the protocol. While SegWit addresses many long-standing issues in Bitcoin, developers are already considering other significant improvements that could be stalled provided we remain vulnerable to the dynamics enabled by the current activation progress.
Therefore, what we need is an engineering compromise, one that does not require poor tradeoffs but rather, introduces an alternative way to implement the desired features. Otherwise, expect additional attempts to force governance structures on top of Bitcoin, more roundtables and many other instances of communication failures.
It’s likely that any further changes to the protocol may come at a slower pace than they have in the past but it is important that we prevent them from becoming impossible. Despite the enormous improvements made to the software over the last few years, Bitcoin remains a young technology and it will require significantly more work to support its growing economy. Moreover, expect these type of debates to heat up even more once we begin considering privacy & fungibility enhancements.
User Activated Soft forks (UASF) are compatible with Bitcoin’s incentives and offer an optimal way to align miners and users interests. While they present their own coordination challenge, they are, in essence, the mechanism most respectful of Bitcoin’s organic nature. Rather than rely on proxy signalling and depend on collaboration from a collection of self-interested mining pools, UASF enables technological development supported by bottom-up user adoption.
The unfortunate conclusion of the last few years of debate may be that we have reached a point of no return: previously dependable process have failed us. We are now facing two choices: either we concede defeat and grant authority in a system built to avoid it or we refine our understanding of the consensus upholding Bitcoin’s rules, stand together and act accordingly.
If you are interested in learning more about UASF, their implications and the various proposals built around their principles, I include a couple of links below:
Moving towards user activated soft fork activation by ShaolinFry
Litecoin China Roundtable & UASF by ShaolinFry
BIP148 by ShaolinFry
BIP148 Risk Analysis by Luke Dashjr
UASF Game-Theory Analysis by Alphonse Pace
BIP8 by ShaolinFry
