Alternative Bitcoin Implementations Can Co-Exist

In my previous article I responded to the Hearn outburst and that is a good precursor to this article. Now I’m going to talk about the future of Bitcoin development and how alternative Bitcoin implementations change the landscape.

First some background. For years Bitcoin had only only one serious implementation, the reference client, which is nowadays called Bitcoin Core. This is the one Satoshi Nakamoto started, handed over to Gavin Andresen, who handed it over to Wladimir J. van der Laan, who is now the current “maintainer” of Bitcoin Core.

Under the “rule” of Satoshi and then Gavin, Bitcoin development closely resembled a “benevolent dictator” model. After Wladimir took over, a new model based on “developer consensus” has taken over. This model basically means that the developers constantly vote amongst themselves on different proposals either by signaling ACK (Acknowledgment) or NACK (Negative-Acknowledgment).

One of the reasons for the arrival of competing implementations is the fact that the new leadership model of Bitcoin Core is much less decisive than before. Solutions to many important issues are only considered viable if they get unanimous or near-unanimous consensus within the Core developer community. This can literally mean that one “NACK” is all it takes to postpone the solving of an important issue by months or even years.

In recent years we have seen multiple alternative implementations of Bitcoin such as btcd. Btcd It is fully compatible with the Bitcoin protocol and talks to all the other nodes normally but it is made with a completely different programming language. Btcd has not challenged any hard protocol rules of Bitcoin so it is a bit different than the most recent alternative implementations of Bitcoin.

Then comes Bitcoin XT which was started by Mike Hearn & Gavin Andresen. This alternative implementation is different in the sense that it includes code that will update the hard protocol rules of Bitcoin and essentially create a new “fork” of the Bitcoin blockchain.

The main change in XT is a significant increase in Bitcoin blocksize, in order to increase the capacity of the network. This change was originally denied by Core due to concerns over the level of centralization in the network. But Hearn & Andresen thought that the capacity increase was so important for the future of Bitcoin, that they have to circumvent Core.

These new rules will activate if 75% of the mining network installs the XT update but until then XT is fully compatible with all the rules of Bitcoin. This implies miners are in control of the network but in reality miner majority is used mainly because it can be reliably measured. In truth it is Bitcoin businesses and users that have as much say on hard protocol rules as do the miners (explanation).

Bitcoin XT failed to get enough traction to cause a rule change in the Bitcoin protocol but it is still up & running. Currently around 9% of the nodes in the Bitcoin network are running XT.

Even though XT failed and the guy who started it, Hearn, actually now quit the community entirely, the legacy of XT lives on. The era of alternative implementations is not over, it has just begun. In the aftermath of the XT situation we have now recently seen Bitcoin Unlimited join the fray. Currently 2,2% of nodes are running BU.

And last but definitely not least, there is now Bitcoin Classic. It is a project backed by notable developers such as Gavin Andresen and Jeff Garzik. It has company backing from many major companies in the ecosystem such as Coinbase, Blockchain.info, Xapo, Circle, OKCoin, Bitstamp and so on. And most importantly, it has serious miner backing. Approximately 70% of the mining hash power has now reportedly given their support (by word) to Classic.

But, it’s important to keep in mind that Classic doesn’t have their code out yet. They are still working on it and plan to release updates to all major Bitcoin versions at the same time, for all relevant operating systems. The actual change in Classic is fairly simple, the only thing they want to change in the Core codebase at this time is the blocksize. And as a one-time lift to 2MB. Although there is talk regarding the controversial Replace-By-Fee update and potentially reverting it.

We still don’t know if Classic can get enough backing to push a hard fork through. There is good backing now, but I think more is needed as it is a full scale protocol update (everyone has to update).

But the question now becomes, what happens to Core if Classic is able to push a hard fork through? This is something I want to explore, as there are a couple of wildly different scenarios for this.

Classic vs Core

The current attitude amongst some of the prominent Core developers is concerning. They have taken a “my way, or the highway” attitude on hard forks and many threaten to quit Bitcoin development if there is a rule change they don’t agree with. In fact many Core supporters are using this as an argument to not change the rules, “because the Core developers are so important”.

Let me get this straight. Core developers are the most technically talented people in Bitcoin space. They know their stuff. However, the current crisis is not about technical know-how, it is a crisis of leadership. And in this regard I think Core has been struggling, to say the least.

One of the issues is that Core does not have a process of any kind for gathering consensus for a hard fork. They talk about consensus all the time but what they talk about is “developer consensus” which they can arrive at easily using their ACK/NACK system. But when we talk about the whole eco-system (which is relevant in the case of a hard fork), the question becomes more political, and they are extremely ill-equipped at handling anything political.

Due to this issue the developer team at Core has been spending more and more time figuring ways to change the rules of Bitcoin without everyone needing to upgrade (called soft forks), so they can conveniently skip the larger consensus issue and just implement stuff together with the miners. This is not sitting well with many Bitcoin users & companies who feel that Core is not taking their needs sufficiently into account.

Bitcoin Classic has a different kind of process. It is not afraid of hard forks and it already has tools to measure the consensus level across the whole eco-system. There is a voting platform called consider.it which allows voting on general Bitcoin issues and issues related to Bitcoin Classic specifically. Users at consider.it can be verified and they can be extra-verified to be developers, miners, company representatives. And votes are transparent and can be filtered.

How Classic uses those tools in the long run is still a work in progress but it is remarkable that Classic has been in existence for a little while but it already has better political consensus mechanism’s than Core has ever had.

The main issue that Bitcoin companies have with the Core way of doing things is that they don’t really have a say. There needs to be a process where companies have a say. Where users have a say. And where the developers make compromises with the eco-system in deciding what to implement.

This capability to compromise, especially when it comes to hard forks, is non-existent at Core. There is a lot of fobia and fear-mongering in relation to hard forks as well, which by many smart estimates are extremely safe when done with sufficient consensus, enough time window and active communication.

The attitude of no-compromise is so total and absolute that today, a prominent Core developer Gregory Maxwell actually said in a Reddit comment that they are considering doing a protocol rule change that would change the Proof of Work algorithm of Bitcoin which would bypass all the current miners and create a permanent fork of the Bitcoin blockchain.

That would be exactly the kind of scenario we never want in a hard fork — it is the only way things can go really bad.

Core developers must understand that if the majority of the Bitcoin economy is behind a rule change (users, businesses and miners), the new rules are Bitcoin. And that must be respected by everyone, including Core developers. Developers are serving the user community at large, not the other way around.

Healthy competition between alternative clients

The final chapter of my becoming-long article is about the potential for a healthy competitive future between alternative clients.

First of all, the developers need to let go of the idea that they are in charge. They are only in charge of what they personally contribute to on code level but they are not in charge of what rule changes go into Bitcoin or what kind of changes users actually want to apply.

I believe the development of Bitcoin should be a joint project between developers, users, businesses and miners. Everyone should have a say and each party should have capabilities for political compromises. Bitcoin Classic is currently experimenting with a direct democracy model but a return to the “benevolent dictator” model within a certain implementation could also be interesting.

Importantly, the implementation that contributes the most, will still be the one appreciated the most. Core thinks that it is game-over for them if Classic “wins” — this is far from being the case. The strategy of Classic is to copy everything from Core even in the future as they don’t have comparable development resources yet. And this goes both ways, Core could copy from Classic in the future as its development resources increase.

Additionally there is potential for implementations that are not free. Just like Red Hat for enterprises in the Linux world, there could be enterprise implementations of Bitcoin where the developers get proper funding from Bitcoin companies and the companies can better make sure that features they appreciate are also implemented.

Ever wonder why the companies in Bitcoin space aren’t paying a lot for Bitcoin development? Maybe because there is a significant disconnect between what the companies want in regards to Bitcoin development and what actually happens. Could be other things as well, in this regard I’m simply speculating.

Still, I’m not advocating for company control of Bitcoin development. It can be dangerous especially if we think about the potential of government, bank interference and so on. There needs to be a balance between developers, users of different type, miners and businesses in how the rules of Bitcoin are decided.

Bitcoin Classic is here because if users want a hard fork rule change, they must do it by some other route than Core. Core has explicitly stated that they view hard forks only as emergency last resort measures. Therefore a hard fork is never going to happen with the initiative of Core unless there is a massive emergency situation already present.

Finally, I’d just like to say that no one who supports Bitcoin Classic wants to fire a single talented Bitcoin Core developer. This is a false argument. The developers who would leave because community consensus overrided the Core plan, are quite literally firing themselves.

Embrace the result of the larger eco-system rule consensus (either way) and keep doing what you do. That is my advice for all developers, regardless of which “camp” they feel they belong in. Core & Classic & all the other implementations can co-exist in the long run even after a hard fork. In healthy competition.

Disclaimer: These opinions are my personal opinions only. The company that I have co-founded in Bitcoin space does not currently have an official stance on any of these issues and is staying neutral for now.