Bitcoin XT, Bitcoin Classic, Bitcoin Unlimited, SegWit2MB, and the latest bcoin.io extension blocks proposal. All of those have one thing in common and I am not referring to bigger blocks.
Rather, what they share is a concerning disregard for the established FOSS development process in Bitcoin and a disparaging attitude towards the sovereignty of the peers supporting the network.
For those needing a memory jog, /u/sound8bits on Reddit produced a rather comprehensive compendium of the origins of the block size debate. The most obvious trend observed there is the communication break down and the subsequent attempts by various parties at skirting previously established peer-review practices.
Bitcoin-XT
After a series of grandstanding blog posts from interested developers failed to convince the ecosystem as well as the technical community, BIP-101, a hard fork proposal, was merged to Bitcoin-XT which was then promoted as a consensus incompatible implementation despite the advertised risks. Failing to get any traction amongst peers (aside from obvious sybil attacks), XT advocates initiated what I consider to be the first instance in a long series of betrayal of Bitcoin users by promoting lobby of centralized actors as a way to steer the direction of protocol development.
Oblivious to community sentiment, letters were handed down from industry & mining ivory towers. Bitcoin users were implicitly told that consensus did not require their input. Incidentally, this setup also created a context where Bitcoin developers could be singled out for “stalling” progress by refusing to pressure users into changes that were demonstrably contentious.
It would be irresponsible and dangerous to the network and thus the users of the software to risk forks, or to take a leading role in pushing dramatic changes. Bitcoin Core developers obviously have the ability to make any changes to the codebase or its releases, but it is still up to the community to choose to run that code.
Some people have called the prospect of limited block space and the development of a fee market a change in policy compared to the past. I respectfully disagree with that. Bitcoin Core is not running the Bitcoin economy, and its developers have no authority to set its rules. Change in economics is always happening, and should be expected. Worse, intervening in consensus changes would make the ecosystem more dependent on the group taking that decision, not less.
So to point out what I consider obvious: if Bitcoin requires central control over its rules by a group of developers, it is completely uninteresting to me. Consensus changes should be done using consensus, and the default in case of controversy is no change. — Pieter Wuille
As we are all aware by now, the efforts highlighted above lead nowhere. By dismissing the concerns of the economic majority, proponents of XT painted themselves into a corner and ultimately revealed their ploy as a power grab aimed at imposing a governance model on top of Bitcoin’s protocol development.
After such spectacular failure, which lead to the rage-quit of a prominent advocate, you would have expected promoters of contentious hard fork proposals to refine their approach and learn from their mistakes. You would be wrong. They took the playbook introduced by XT and ran with it.
Bitcoin Classic
Classic would follow closely in its path by organizing backdoor meetings where lobbyist would shop the proposal around and, by confusing people on their intent, get them to co-sign their initiative.
What’s worse, they doubled-down on the sybil masquerade and went so far as to insult everyone’s intelligence by creating a dubious “voting” platform dubbed “consider.it” which inevitably dealt with its own share of sybil problems.
Bitcoin Unlimited
Not many are familiar with the early bubbling of the Bitcoin Unlimited implementation. It is not by mistake. Inconvenient history is thrown into the memory hole. Newspeak is how they “emerged” as the new contender. Unable to satisfy the community with an agreeable approach to the block size problem, the usual suspects thought a user configurable GUI might just provide enough illusion of power to get users to side with them. Once again, it did not pan out as expected. Devious as they are, they did not give up and surprisingly flipped the script on everyone and in a feat of Orwellian proportion, persuaded their supporter that the one valid chain was in fact the one extended by 51% of the hashing power.
SegWit
Unfortunately, early communication with regards to the SegWit proposal was also marred with confusion and well intentioned initiatives steered the project off its track. While the idea was openly presented to a panel of academics and developers in a collaborative setting, political attempts to reach “consensus” for it opened the door for controversy and further eroded trust between every ecosystem participants. The result is a sound and mature technical proposal that has yet to activate because of the noise and emotions surrounding it.
They say the more things change the more they stay the same. The most recent extension block proposal is yet another stark reminder of how our ecosystem has lost touch with its peer-to-peer and open source tenets. Proposals that challenge the balance of Bitcoin’s consensus should not be unilaterally sponsored by any entity or introduced via top-down communication channels. PR campaigns, industry letters and roundtables are not compatible with the grassroots movement that has made Bitcoin the success that it is. We cannot afford to stray away from the best practices that have been handed down to us by decades of FOSS development.
Any attempt to sidestep or privilege certain actors over others necessarily leads to mistrust and stalls the development process. While we all would hope that proposals would be evaluated on their technical merits alone, these unnecessary and selfish attempts distract the attention of contributors away from the engineering work and invites further political gish galloping.
Emphasis should be put on allowing a process that is as organic as possible so that inclusion is encouraged and that every inputs can be considered before pushing any initiative to further stages and a wider audience. Just as backroom arrangements are incompatible with the open-source ethos, throwing proposals into the public arena and expecting sound technical feedback is not an appropriate approach to consensus building.
The Bitcoin Improvement Proposal (BIP) process was specifically designed to provide a standardized, implementation-independent, way for developers to introduce new features and facilitate community feedback. Because BIP proposals are expected to be reasonably fleshed out and accurately documented before being submitted, contributors are also invited to get initial feedback on their ideas through the Bitcoin-dev mailing list as well as the various Bitcoin channels on IRC freenode (#bitcoin & #bitcoin-wizards). Other venues focusing on technical collaboration and driven by academic standards are another way to disseminate ideas and encourage constructive conversations around a proposal. Examples of those include, but are not limited to, the SF Bitcoin Devs meet-up, NYC Bitcoin Devs, Bitcoin Milano meet-up, the Paralelni Polis Bitcoin meet-up, the Scaling Bitcoin conferences.
The views expressed in this post are mine only and should not reflect on the opinion of my employer or colleagues.
