Op Ed: No Governance for Old Men: Coordinating Protocol Upgrades in the Future

Make no mistake. We are witnessing a high-stakes protocol standards battle play out in real time. And it is just as important as last century’s battle for the internet’s TCP standard. 

Current capacity constraints on the Bitcoin blockchain have brought us to this impasse.

The Bitcoin protocol, as the dominant value transfer “network effect” leader, battles against upstart cryptocurrency protocols like Ethereum and Monero. But it also battles with itself as divergent forces push for either on-chain scaling or off-chain scaling, hard fork or soft fork, SegWit transaction format or original transaction format.

The so-called nuclear option is a prolonged, contested hard fork of the Bitcoin blockchain because it risks splitting the network into two competing chains, which is to no one’s benefit. Therefore, it should be reserved as a planned formality or a last resort for extreme situations rather than a perpetual form of “live” dispute resolution.

With so much individual and institutional wealth essentially stored on the Bitcoin blockchain, it can be extremely disconcerting when others try to “fork” around with your money. Chronic forking is not synonymous with wealth management and prudent capital accumulation, which require stability and predictability. Importantly, smart contracts and non-monetary applications will also rely upon relative stability since the same native digital token also facilitates the proof-of-work security model.

This article will examine how open-source governance was designed to work within the Bitcoin protocol and how users, miners and developers are locked in a symbiotic dance when it comes to potential forks to the immutable consensus. Solutions will be proposed and analyzed that maintain the decentralized nature of the resulting code and the blockchain consensus, while still permitting sensible protocol upgrades. Governance is not only about the particular method of change-control management, but also about how the very method itself is subject to change.

Let’s not deploy the nuclear option for every protocol upgrade.

Open-Source Protocols and Bitcoin

Generally referred to as FOSS, or free and open-source software, this source code is openly shared so that people are encouraged to use the software and to voluntarily improve its design, resulting in decreasing software costs; increasing security and stability, and flexibility over hardware choice; and better privacy protection.

Open-source governance models, such as Linux and BitTorrent, are not new and they existed prior to the emergence of Bitcoin in early 2009; however, they have never before been so tightly intertwined with money itself. Indeed, as the largest distributed computing project in the world with self-adjusting computational power, Bitcoin may be the first crude instance of A.I. on the internet.

In “Who Controls the Blockchain?” Patrick Murck confirms that Bitcoin is functioning as designed:

As a blockchain community grows, it becomes increasingly more difficult for stakeholders to reach a consensus on changing network rules. This is by design, and reinforces the original principles of the blockchain’s creators. To change the rules is to split the network, creating a new blockchain and a new community. Blockchain networks resist political governance because they are governed by everyone who [participates] in them, and by no one in particular.

Murck continues:

Bitcoin’s ability to resist such populist campaigns demonstrates the success of the blockchain’s governance structure and shows that the ‘governance crisis’ is a false narrative.

Of course it’s a false narrative, and Murck is correct on this point. Bitcoin’s lack of political governance is Bitcoin’s governance model, and forking is a natural intended component of that. “Governance” may be the wrong word for it because we are actually talking about minimizing potential disruption.

Where Bitcoin differs from other open-source protocols is that two levels of forking exist. One level forks the open-source code (code fork), and another level forks the blockchain consensus (chain fork). Since there can only be one consensus per native digital token, chain splits are the natural result of this. The only way to avoid potential chain splits in the future is to restrict the change-control process to a single implementation, which is not very safe nor realistic.

“Collaborate or fork” has become the rallying cry for Bitcoin Core supporters. L.M. Goodman, author of “Tezos: A Self-Amending Crypto-Ledger Position Paper,” writes:

Core development teams are a potentially dangerous source of centralization.

When it comes to Bitcoin Core, the publicly shared code repository hosts the current reference implementation, and a small group of code committers (or maintainers) regulate any merges to the code. Even though other projects may be more open to criticism and newcomers, this general structure reminds me of a presiding council of elders.

Making hazy claims of a peer-review process or saying that committers are just passive maintainers merely creates the facade of decentralized code. The real peer-review process takes place on multiple community and technical forums, some of which are not even frequented by the developers and Bitcoin Core committers. 

The BIP (Bitcoin Improvement Proposal) process is sufficient and it’s working for those who choose to collaborate on Bitcoin Core. Similar to the RFC (Request for Comments) process at the IETF, BIP debates about a proposed implementation can provide technical documentation useful to developers. However, it is not working for many involved in Bitcoin protocol development due to the advantages of incumbency and the false appeal to authority with core developers. If Bitcoin Core no longer maintains the leading reference implementation for the Bitcoin protocol, it will be 100 percent due to this intransigence.

Sensitive to the criticisms of glorifying Bitcoin Core, Adam Back of Blockstream recently proposed an option to freeze the base-layer protocol, but at the moment that will only move all of the politics and game-playing to what exactly the base-layer freeze should look like. It is a nice idea for separating the protocol standard from a single reference implementation and for transitioning the Bitcoin protocol to an IETF-like structure, although it’s extremely premature for now. 

Therefore, by default, that leaves us with several alternative Bitcoin implementations in an environment of continual forking.

Even Satoshi Nakamoto was critical of multiple consensus implementations in 2010:

I don’t believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.

That prevailing standpoint, however, may be changing, which Aaron van Wirdum addresses in “The Long History and Disputed Desirability of Alternative Bitcoin Implementations.” Wirdum cites Eric Voskuil of libbitcoin, who argues that there should not be one particular implementation to define the Bitcoin protocol:

“All code that impacts consensus is part of consensus,” Voskuil told Bitcoin Magazine. “But when part of this code stops the network or does something not nice, it’s called a bug needing a fix, but that fix is a change to consensus. Since bugs are consensus, fixes are forks. As such, a single implementation gives far too much power to its developers. Shutting down the network while some star chamber works out a new consensus is downright authoritarian.”

Multiple alternative implementations of the Bitcoin protocol strengthen the network and help to prevent code centralization.

Politics of Blockchain Forking (or How UASF BIP 148 Will Fail)

Contentious hard forks and soft forks all come down to hashing power. You can phrase it differently and you can make believe that two-day zero-balance nodes have a fundamental say in the outcome, but you cannot alter that basic reality.

A BIP 148 fork will undoubtedly need mining hash power to succeed or even to result in a minority chain. However, if Segregated Witness (SegWit) had sufficient miner support in the first place, the BIP 148 UASF itself would be unnecessary. So, in that respect, it will now proceed like a game of chicken waiting to see if miners support the fork attempt.

Mirroring aspects of mob rule, if the UASF approach works as a way to bring miners around to adopting SegWit, then the emboldened mob will deploy the tactic for numerous other protocol upgrades in the future. Consensus rules should not be easy to change and they should not be able to change through simple majority rule on nodes, economic or not. Eventually, these attempts will run headfirst into the wall of Nakamoto consensus. 

As far as the network is concerned, it’s like turning off the power to your node.

There is no room for majority rule in Bitcoin. Those who endorse the UASF approach and cleverly insert UASF tags in their social media handles are endorsing majority rule in Bitcoin. They are providing a stage for any random user group to push their warped agenda via tyranny of the nodes.

The prolific Jimmy Song says that having real skin in the game is what matters:

Bitcoin doesn’t care if you post arguments on Reddit. Bitcoin doesn’t care if you put something clever in your Twitter name. Bitcoin doesn’t care if you educate people, write articles, or make clever Twitter insults. Bitcoin doesn’t care about your wishes, your feelings or your arguments.

Let’s keep “majority rule” antics out of Bitcoin. There is no protocol condition that activates “if we are all united” and that is a good thing.

With enough hashing power, the mob-induced UASF BIP 148 will lead to a temporary chain split. However, the probability of a Bitcoin minority chain surviving for very long is extremely low due to the lengthy difficulty re-targeting period of 2,016 blocks. Unlike the Ethereum/Ethereum Classic fork, that is a long time for miners to invest in a chain of uncertainty.

Responding to a Reddit post for newbies who are scared of losing money around the 1st of August due to UASF, ArmchairCryptologist explains:

Your advice is sound, but realistically, the most likely scenario is that the UASF either wins or dies. If it gets less than ~12% of the hashrate, it will not be able to activate Segwit in time, and it will almost certainly die. If it gets less than ~20% I also wouldn’t be surprised to see active interference with orphaning to prevent transactions from being processed.

If on the other hand it gets more than ~40% of the hashrate, the chance for a reorg on the other chain is large enough that most miners will likely jump ship, and it will almost certainly win. At over ~20% block orphaning attacks won’t be effective, as it would split the majority chain hashrate and risk tipping the scale. Which means that the only situation where you will realistically have two working chains for an extended period is if you get between ~20% and ~40% of the hashrate for the UASF.

The collectivist UASF BIP 148 strategy will ultimately fail and that’s a good thing. It is driven primarily by those with very little at stake expecting the miners to stake everything by supporting a minority chain. Pretty soon, you run out of other people’s money. This commenter on Reddit understands:

The entire premise was that it was very cheap to switch, but very expensive to stay. That’s when I realized the folly of it all; [it’s] only cheap because they’re not staking anything. But someone has to stake something.

And that’s what is going to cause it to fail. That and the lack of replay protection. People like this guy flip it around and genuinely believe the mining problem will be solved by massively increased value. If they do somehow put enough pressure on exchanges that list UASF, despite the lack of replay protection, and if we take his logic a step further, UASFers are going to be pushing everyone to “buy, buy, buy” UASF and “sell, sell, sell” Legacy Coin. But without replay protection, they’re going to be obliterated by a few smart people who realize there are huge gains to be had.

Alphonse Pace has an excellent paper describing chain splits and their resolution. He walks us through compatible, incompatible and semi-compatible hard forks, arguing that users do have power if they truly reject a soft-fork rule change:

… users do have power — by invoking an incompatible hard fork. In this case, users will force the chain to split by introducing a new ruleset (which may include a proof-of-work change, but does not require one). This ensures users always have an escape from a miner-imposed ruleset that they reject. This way, if the economy and users truly reject a soft fork rule change, they always have the power to break away and reclaim the rules they wish. It may be inconvenient, but the same is true by any attack by the miners on users.

The Future of Coordinating Protocol Upgrades

What group determines the big decisions in Bitcoin’s direction? Ilogy doubts that it is the developers:

Theymos almost completely foresaw what is happening today. Why? Because Theymos has a deep understanding of Bitcoin and he was able to connect the dots and recognize that the logic of the system leads inevitably to this conclusion. Once we add to the equation the fact that restricting on-chain scaling was always going to be perceived by the ‘generators’ as something that ‘reduces profit,’ it should be clear that the logic of the system was intrinsically going to bring us to the point we find ourselves today.

Years later these two juggernauts of Bitcoin would find themselves on opposite ends of the debate. But what is interesting, what they both recognized, was that ultimately big decisions in Bitcoin’s direction would be determined by the powerful actors in the space, not by the average user and, more importantly, not by the developers. 

The developer role can be thought of as proposing a variety of software menu choices for the users, merchants and miners to accept and run. If a software upgrade or patch is deemed unacceptable, then developers must go back to work and adjust the BIP menu offering. Otherwise, mutiny becomes the only option for dissatisfied miners. 

In “Who Controls Bitcoin?” Daniel Krawisz says that the investors wield the most power, and because of that, miners follow investors. Therefore, the protocol upgrades likely to get adopted will be the ones that increase Bitcoin’s value as an investment, such as anonymity improvements being favored over attempts at making Bitcoin easier to regulate.

In the future, miner coordination via a Bitcoin DAO (decentralized autonomous organization) on the blockchain could be the key to smooth and uneventful forking. Self-governing ratification would allow diverse stakeholders to coordinate protocol upgrades on-chain, reducing the likelihood of software propagation battles that perpetually fork the codebase.

Attorney Adam Vaziri of Diacle supports a system of DAO voting by Bitcoin miners to remove the uncertainty around protocol upgrades. He readily admits that he has been inspired by Tezos and Decred.

Prediction markets have also been proposed as a method to gauge user and miner preferences through public forecasting, the theory being that these prediction markets would yield the fairest overall consensus for protocol upgrades prior to the actual fork.

The question remains: Is coin-based voting based on allocated hash power superior to the informal signaling method utilized today? Are prediction markets or futures markets a viable method to gauge consensus and determine critical protocol upgrades?

I’m not optimistic. On-chain voting and “intent” signaling are both non-binding expressions while prediction and futures markets can be easily gamed. Therefore, while Tezos and Decred represent admirable efforts in the quest for complete resilient decentralization, I do not think Bitcoin protocol upgrades of the future will be managed in this way.

The Bitcoin ecosystem doesn’t need to achieve a social consensus prior to making changes to the protocol. What has clearly emerged from the events of this summer is that Bitcoin has demonstrated an even stronger degree of immutability.

There is no failure of governance and there is no failure of the market. The non-authoritarian forces at play here are functioning exactly as they should. Protocol upgrades in a decentralized environment are an evolutionary process, and that process has matured to the current six stages of Bitcoin protocol upgrading, with some optional variances for BIP 91:

(a) BIP menu choices competing for mindshare, strategic appropriateness and technical rigor;

(b) Informal intent signaling based on miners inserting text into the coinbase for each block mined;

(c) Block signaling period where miners formally signal a designated “bit” trigger for BIP lock-in, based on “x” percent over a “y” number of blocks period;

(d) Block activation period after BIP lock-in, which sets a secondary period of “x” percent over a “y” number of blocks for activation;

(e) Primary difficulty adjustment period (2,016 blocks) where “x” percent of miners must signal for the upgrade to lock in;

(f) Secondary difficulty adjustment period (2,016 blocks) required for the protocol upgrade to activate on the network.

Conclusion

This would not be the first fork in Bitcoin and it won’t be the last. If we believe in the power of Nakamoto consensus and probabilistic security, then the secret to uneventful protocol upgrades is smoother and more reliable signaling by miners.

July has been a tough month for Bitcoin, but it has also been pivotal. Even though I doubt the probability of success for UASF BIP 148, some may say that the threat of the reckless UASF on August 1 played a role in the rapid timeline for SegWit2x/BIP 91, and I agree with that. Game theory is alive and well in Bitcoin.

The design of Nakamoto consensus provides the ultimate method for decentralized dispute resolution by placing that decision with the hashing power and the built-in incentives against 51 percent attacks. In fact, Tom Harding considers miners to be the only failsafe in Bitcoin:

Nakamoto consensus for the win. See you in November.

The views expressed in this op ed are those of its author, Jon Matonis, and do not necessarily reflect those of Bitcoin Magazine or BTC Media.