“Cypherpunks write code. We know that someone has to write software to defend privacy, and since we can’t get privacy unless we all do, we’re going to write it. We publish our code so that our fellow Cypherpunks may practice and play with it. Our code is free for all to use, worldwide. We don’t much care if you don’t approve of the software we write. We know that software can’t be destroyed and that a widely dispersed system can’t be shut down.” – Eric Hughes
Bitcoin has reached a level of success that even the cypherpunks who got involved with the project in the early days could not have expected. However, this success has also led to difficulties when it comes to adding new protocol upgrades to the system. To get past the current stalemate, Bitcoin may need to return to its cypherpunk roots.
A number of methods for scaling Bitcoin have been proposed over the past couple of years, but none of them have been activated on the Bitcoin network. As it turns out, Bitcoin’s success has led to a diverse user base who cannot figure out how to coordinate further improvements to the network.
Bitcoin’s coordination issues have to do with the large amount of noise in the space. Whether it’s node counts or social media posts, there are a number of different signals out there that are vulnerable to Sybil attacks and therefore unreliable. The various agreements on changes to Bitcoin’s consensus rules made by Bitcoin companies and miners are attempts to get a better idea of the true social consensus of Bitcoin users, but these sorts of attempts have also failed to lead to the activation of further improvements.
To get rid of the noise and move forward, Bitcoin must return to its base foundation of free markets and computer science. Future Bitcoin protocol improvements can be enforced by nothing more than code and markets in a completely permissionless manner.
Permissionless Upgrades for Bitcoin
A possible solution to Bitcoin’s protocol stalemate is for developers to write code and then allow the market to accept or reject the various improvement proposals.
First, a developer must write a soft-forking improvement for Bitcoin. Then, a futures market can be created for two tokens that would be created by a hypothetical chain split caused by a soft fork that is not allowed by a majority of the network hashrate. For a detailed explanation of how this process works, read this recent article on how SegWit could be activated through the combination of a user-activated soft fork (UASF) with a futures market.
This is all that needs to happen for a protocol upgrade to be proposed and then decided upon. Any discussions around the proposal would just be noise (although they will also inform the market on what decision to take). How the market reacts to the written code is all that matters.
It Doesn’t Matter What Bitcoin Companies and Miners Want
Various Bitcoin companies and mining pools may speak out about a particular soft-forking improvement made to the Bitcoin protocol, but their words will carry no weight — or at least not as much weight as speculators on an exchange. These organizations can make their case to speculators, but the market makes the final call.
In short, no one can stop a developer from writing code, and the incentives are such that everyone should allow a soft fork to be implemented if the market desires it.
Exchanges have every incentive to get involved with the market for Bitcoin soft forks. By creating these futures markets for soft forks, exchanges are able to increase profits through trading fees. An imperfect illustration of this point was seen when Poloniex listed Ethereum Classic after the Ethereum hard fork for the purpose of bailing out DAO token holders.
Secondly, miners are in the business of earning block rewards. They are financially incentivized to follow the lead of users (speculators) when it comes to the future direction of the Bitcoin protocol. Miners want to mine on whatever blockchain will lead to the greatest return on their hashing power.
Lastly, wallets and any other company working with Bitcoin don’t really have much say in the matter at all (outside of their own developers and speculation on soft fork markets). These companies will simply be following the progress of protocol improvements and implement the necessary changes once the market has made a decision.
SegWit Will Be the First Example of This Upgrade Mechanism
The approach to protocol upgrades outlined here is not strictly hypothetical. There is a growing swell of support around BIP 148, which is a UASF for Segregated Witness (SegWit). There have also been indications that at least one exchange, Bitfinex, will create a futures market for this improvement proposal.
With code written and the possibility of a market for BIP 148 appearing on an exchange, the two main ingredients for a market-based soft fork are in the works. If this proposal gains support from the market, then the code will get implemented in Bitcoin Core or some other implementation of the Bitcoin protocol.
Side Notes on Hard Forks and Contentious Changes
There are some clarifications that should be made in terms of the process described above.
For one, the fact that a change is desired by a majority of the Bitcoin economy does not mean the market will decide that it should be implemented. If there is a strong minority that is against the change, it may be in the economic majority’s best interest to “vote” against the change as the incentives are for everyone to remain on the main chain. The majority may not want to see a chunk of the ecosystem break away into an altcoin.
A version of the process described above can also be applied to hard forks; the only problem is that hard forks are more difficult to execute without a notable chain split. The market may decide that a hard fork is not worth it unless there is agreement from 95 percent or more of the economy on the hard fork proposal.
Picture from Wikimedia Commons.