Begun, this Bitcoin Clone War has!
I ask you, dear reader, please forgive me. I am going to break from my normal “impartial observer” commentary on the Bitcoin space and speak personally about a project that I am involved in, because I believe it matters.
There is an election going on in Bitcoin space. At least this is what the media is going to call it very shortly (perhaps in a months time, after it is all settled, as mainstream media is apt to do… always late to the party). This election, like any, is political. It is a battle of wills, of differing philosophies, of ways of thinking. But like all elections, I believe that the will of the people, the majority, will determine the results.
Bitcoin Classic, is an implementation headed by Gavin Andreson, Jeff Garzik, Jonathan Toomim and others, which aims to deliver an alternative implementation of Bitcoin, aimed at addressing the demands of the users and businesses in Bitcoin.
We seek to work cooperatively with all implementations of Bitcoin, including BitcoinCore! This has been the philosophy of Bitcoin Classic from the beginning. To promote freedom of choice, in users being able to help guide the priorities of the project, and to work together with developers cooperatively to make Bitcoin better. Indeed this is the guiding principle of open source code. As a investor in Bitcoin, I feel it is my right to have a say in the direction I want Bitcoin to evolve and develop, but the existing maintainers have been consistently telling everyone that we cannot have the freedom of choice. The majority must succumb to the oppression of the minority, because the small minority of experts knows what’s best for us. This view would normally be well and good if this minority were publicly elected officials, but they are not. They are just people who inherited the Bitcoin codebase and taken custodianship of the network, of the capital and businesses it represents, of _ my_ money.
Pro-Rules vs Pro-Choice
At Bitcoin Classic, the policy has been one of free choice, of allowing people to choose which features they want, instead of the ones that the developers think are best for us. For example, a highly contentious feature, Replace by Fee, which was not well explained to the public and on the surface looks to open up attacks on instant transactions over Bitcoin, was forced into the codebase without much more than a cursory explanation of what it was, and why it was necessary. It has since become a contentious topic. (it actually makes things like Lightning network work better). Core devs should not be blamed for their behaviour though. Many of them are really hard working selfless volunteers. But they are open source developers, who are unaccustomed to asking for permission or interacting with the users of the system. In a company, the project managers would fill the role of negotiating with stakeholders about which features they wanted, and made sure that the developers created a product that fit the users demands. This is unfortunately not the current development process being employed. Bitcoin, is the world’s first open source project with over 6 billion dollars riding on it. The developers have all the right to be overly cautious. Unfortunately, that level of caution has come at the expense of them being completely disconnected with what the real stakeholders in the system want.
Instead of listening to the users, Blockstream (the company which employs many of the Core devs) advocated strict enforcement of the “no contentious changes shall pass” in order to force consensus.
Block size is one such change. They insist that consensus rules (written by them) are inviolate, and that everyone needs to respect them, even if a majority of the stakeholders may not agree with them. This is just another way of saying the defacto law is that the minority rules, and the majority must suffer the oppression of the minority, because math!
Well, who writes the math(computer code)? It doesn’t matter what language rules are written in, whether it be C++, or the legal language of legislators, rules are created by people, who in real life are voted in by the people. The fact that Bitcoin’s consensus laws are written in computer code and secured by cryptography just means that they are easier to enforce, without the need for an army of big brutes with guns to do it. Think about that for a second. If you can essentially make laws, and you don’t need a police force to enforce them, then that means you can’t really stop people from disobeying them, unless you can convince them it is for their own good, that they don’t have a choice. And that is exactly what the Core supporters are trying to do presently, in every way they can.
In real life politics we at least have a semblance of a choice in the matter. We vote. We allow for competing parties with competing ideological platforms. Not so in Bitcoin! If the Blockstream line is to be believed. Nobody voted in the Core developers, they devoted their own time, many without pay, and volunteered for the job. This model has gotten us up to this point, but the time has come when the prodigal son needs no leave the homestead, to set off into world at large to live on his own. It is time to let the Bitcoin project go, into the world, to try and stand on its’ own two feet.
I have advocated for the need to have diversity and freedom of choice in Bitcoin, in order for it to grow out of its infancy, and the developer teams who write the code are no exception to this requirement. How can it become the money which stands for freedom, when the incumbent team is strictly enforcing compliance to its own agenda?
Stage One: First they ignore you…
When Classic was first announced, it was dismissed by Core as “Bitcoin XT2.0” by Adam Back (CEO of Blockstream) This was in reference to the previous attempt by Mike Hearn to create an alternative implementation of the Bitcoin code base. That effort failed for its own reasons, but it has no relation at all to the current Classic project.
Stage Two: Then they laugh at you…
It started with hooligan attacks such as the vandalizing of the Classic teams shared google documents, and attempts at trying to get us to violate our own democratic policies. LukeJr, notable Core supporter, put in a code pull request into the BitcoinClassic system, which proposed changing the Proof-of-Work algorithm of Bitcoin, so that all the existing mining companies would be obsoleted. (by making their mining hardware useless). This suggestion, something that he has been advocating for years, while technically ‘legitimate’, was a poison pill, whose motivation may have been to cast doubt on the ability of the Bitcoin Classic democratic model to work effectively. It was quickly voted down, democratically. Next the Blockstream supporters* switched strategies and tried to filibuster the Classic forums with ‘strawmen’, people whose task it is to fill the chatrooms with endless rhetoric and debate so that legitimate users voices are drowned out, and all the channels turn into never ending shouting matches so as to deter any real exchange of information. They were asked to desist, but they remained. In the final attempt to ‘win the debate’ in a /r/btc reddit exchange, Adam Back (adam3us) came forward with the reasons why he was so adverse to hard forks, one of which was a claim to moral hazard, to which Jonathan Toomim (jtoomim) decisively rebuffed here. This was when it started to become apparent that the Core supporters did not have much technical merit to their argument, nor any claim to moral superiority.
Stage Three: Then they fight you…
The tone changed drastically when BitcoinCore supporters started to see the support of the majority was leaning towards BitcoinClassic.
This culminated with Adam himself coming onto the Classic chatrooms and leaving not-so-subtle hints that several Core developers would quit their work on Bitcoin, if a hard fork was ever done, regardless of how successfully it was deployed, and what percentage of the population agreed with it, so long as it was controversial (can you spot the catch-22? As long as anyone thinks it is controversial, it is.)Basically he is saying that unless the changes are made by us, we aren’t going to go along with them and will instead rage quit like somebody else recently did.
The first offensive shots were fired when, despite days of civilized debate in the BitcoinClassic forums, The tactics of the Core supporters changed from trying to convince everyone of the over-exaggerated dangers of a hard fork to outright sabotaging of the BitcoinClassic code.
We would have liked to think that people would behave civilly and in good faith, but the truth is undeniable it seems, and Blockchains are War and Andrew Poelstra was right when he said that we have to expect adversaries everywhere in crypto. We just didn’t expect the adversaries to come from within the Bitcoin ranks though. The attack was directed at impeding the progress of the project in releasing its awaited first version of the code.
How? Through the informal democratic process, which specific system features to include in the first release were voted upon. For instance, whether or not to remove the controversial Opt-in RBF, and whether to make the block size scaling choice a simple 2mb static bump vs a 2–4mb linear algo etc. After discussion, the conclusion was arrived at to just do a simple 2mb bump first, as it seemed that the world just needs to be convinced that a simple hard fork can be done safely, if well planned and with a majority consensus of the entire network. But soon the decision for a simple 1-feature-only change became an unexpected necessity…
Within a day of this decision, many malicious buggy changes were put into Classic’s code repository many by anonymous users, in a sort of ‘Denial-Of-Service’ attack on the project’s developers. This had the effect of slowing down the real work that needed doing as efforts were diverted in order to weed out the bug injection attempts from the honest code updates. Such bugs if not caught could have been used to publicly declare the supposed lack of competence of the Bitcoin Classic developers.
Stage Four…
I’m hoping that stage four will be “and then they join us” instead of “we win”, and I sincerely hope that any logical developer on the Core dev team would agree with me. The real enemies to the Bitcoin movement are elsewhere, and it doesn’t help the Bitcoin community at large for us to remain divided for long. Like all elections after all is said and done, we need to reconcile our differences and push forward together. Even if they don’t join Classic intends to work with Core, in helping to make sure that their code is compatible with the network post hard fork.
If you want to show your support for choice then choose a alternative Bitcoin implementation that supports people’s voices! (BitcoinClassic, BitcoinUnlimited). If the message is heard loud and clear by the Core team, then I would like to hope that they change their minds and realize that Bitcoin has evolved to a stage where it cannot be controlled by any one centralized team any longer. The honey badger naturally rejects centralization, even in its own development teams!
* To be absolutely fair, I do not believe that Blockstream is officially condoning the malicious behaviours in any way. I think they are just as frustrated about this drama as everyone else. All the developers working there have contributed countless years of unpaid work in maintaining the Bitcoin codebase. They should not be vilified for the actions of a few bad apples. Do not, repeat, do not give them any undeserved hassles or show them any ill will. This is not about disagreeing with the people, it is about disagreeing with the message.
Originally published at https://www.wallstreettechnologist.com on January 20, 2016.
