Governance, Consensus, and Marketing in a Decentralized Ecosystem
Bitcoin Governance
Behind the debate on blocksize is the larger question of governance and consensus. To a certain extent, bitcoin can be considered an autonomous program, executed exactly by software according to a raison d’etre written into code. Because things like mining difficulty calculation, the rewards calendar and the overall money supply have been preprogrammed, they become sacrosanct, autonomously applied without human interaction.
It is at those points where human intervention is required where things become less clear. What was intended? Who decides and how? It is easy to see how these questions can lead to all the nasty things characteristic of political discourse. The challenge ahead is, as Jim Harper wrote in his article Bitcoin and the Politics of Non-Political Money, “to discover how governance of a project like bitcoin will proceed so that politics (in the derogatory sense) can be minimized. Stable governance will help bitcoin compete with governmental monetary and record-keeping systems. Chaotic governance will retard it. We just need to figure out what “stable governance” is.”
There are three main implementations for increasing blocksize and one can discern a set of governing principles behind each, whether unwillingly or by design. We will take a look at each of these systems and try to determine the implications behind each for the future of bitcoin governance.
Bitcoin Classic
Bitcoin Classic might be thought of as a softer version of Bitcoin XT. The homepage lists the contributing developers – Gavin Andresen, Jeff Garzik, Jonathan Toomin, Peter Rizun and Ahmed Bodiwala – as well as an impressive list of miners and companies that have shown support for the project.
The second sentence greeting users when entering the site claims “we are writing the software that miners and users say they want”. And apparently what is wanted is a hard fork to a 2 MB limit, meant to be implemented once 750 of the previous 1,000 blocks contain a message in support. Two weeks after, those that have not updated their software would be working on an old, incompatible block chain.
It is interesting to note that Mr. Garzik had been the most visible proponent of bitcoin classic, as he would eventual go on to lead a disastrous hard fork attempt characterized by entirely insufficient technical engineering. It collapsed out of the gate.
Bitcoin and Democratic Governance
So, what form should this nascent democratic movement take? Surely breathing and being of legal age is not adequate criteria for having a vote, and yet one must draw the line somewhere. How about bitcoin ownership? Could any demonstrable owner of bitcoin have a vote? Most would likely agree that the vote of the proud new owner of .5 bitcoin should not be assigned the same weight as that of a learned long-term holder of hundreds of bitcoin.
What about voting rights based on the number of “bitcoin days” held in a voter’s wallet? This would grant large, long-term holders, who theoretically have the most at stake as well as a more informed opinion, a larger voice.
Of course, as one commentator pointed out in his “con” vote to this suggestion, length of ownership ≠ intelligence. Additionally, depending on how voting rights would be weighed, this could lead to some sort of bitcoin oligopoly, and one with a few pretty public pressure points should external actors wish to influence the debate. So this does not really feel right either.
One interesting suggestion floated was the introduction of a representative, or delegative, democracy into the voting process. While the exact parameters are undefined, essentially this would allow people to pick a delegate that is representative of their particular viewpoint to debate and vote on their behalf. This would ensure that authenticity of voters – one would assume delegates would have greater reputation within the community and could easily be verified – thus doing away with the clutter of a more direct democracy, while filtering out some of the dumbness.
Of course, all of this somewhat assumes that questions with highly technical answers should be decided, or heavily influenced, by a democratic process. Others would argue that developers with the most intimate and deep knowledge of bitcoin should be the ones determining how to implement a roadmap for its future.
Bitcoin Core
Let’s have a look at the top contributors to the bitcoin core since launch in 2009, sorted by number of commits. We’ll just go through the top 12:
| Wladimir J van der Laan | 1,205 |
|---|---|
| Peter Wuille | 640 |
| Gavin Andresen | 484 |
| Cory Field | 330 |
| Matt Corrallo | 288 |
| Jonas Schnelli | 223 |
| Luke Dash Jr | 199 |
| Greg Maxwell | 133 |
| Mike Ford | 118 |
| Marco Falke | 112 |
| Jorge Timon | 106 |
| Peter Todd | 91 |
The list above, perhaps crudely, is a who’s who of the top bitcoin engineers in the world, those who have basically carried bitcoin forward since 2009. Notice something else that these names have in common? With the exception of Gavin Andresen, not a single one can be found on the homepage of bitcoinclassic as a supporting developer. Ditto bitcoin unlimited. Ditto bitcoin cash.
For the most part, the engineers above are not compensated monetarily for their contribution to bitcoin; it might be said that their work is motivated by a belief in the justice and magnitude of what they are doing. Perhaps a commonality of purpose and righteousness of cause has led to a capital-I-Inspired level of development – bitcoin has attracted the best, and gotten the best of them.
Bitcoin development has operated over the years as a sort of technocratic oligarchy with a popular mandate. There is a definite democratic element to the way things have worked – spirited, public debates and the ability for the bitcoin community to have their voices heard through the forums – at the end of the day the buck stops with the core developers.
In practice it has worked like this: proposals for new features, enhancements, etc. to the protocol have been aired for debate amongst the bitcoin development community, after 2011 using Bitcoin Innovation Proposals (before then hashing it out on the dev email list). Generally speaking the ideas behind these proposals are first vetted within the bitcoin community, using forums or other means, to determine their likelihood of being acceptable. If it seems the proposals have a good chance of acceptance, the BIP is submitted, debated on the bitcoin dev mailing list (which can be publicly viewed) and, if consensus is reached in the affirmative, the code written and submitted for inclusion into the bitcoin protocol. This process proved to be at times cumbersome, but this facilitated a default conservatism which many would view as preferable.
So. For all intents and purposes, we had an ultra-knowledgeable core group of benevolent and altruistic developers, lovingly crafting the protocol to balance scalability, speed, security and decentralization. The system worked – until the big, divisive issue of the blocksize cap came to a head with the introduction of bitcoin-xt. Not only were the core developers surprised at the way in which Hearn and Andresen had flipped over the chessboard, they had to contest with a very public PR push on behalf of bitcoin-xt amongst the community – including big interests like mining conglomerates, exchanges etc.
And this is where stuff really started to go south. The moderator of the bitcointalk forum and the bitcoin subreddit, Michael Marquardt aka Theymos, began to censor favorable mentions of bitcoin-xt, including posts from people like Gavin Andresen. This not only was a horrible disservice to the community and against the decentralized spirit of bitcoin, it reflected poorly on the core developers who stayed mum on his actions. They became guilty by association, and whereas before their altruistic contributions to the bitcoin protocol were seen as the height of virtue now people began to worry that they were acting as a bitcoin ruling class, intolerable of dissent, doing what they wanted without engaging the democratic process.
This forced the erstwhile trusted technocrats to engage with a wider audience and address its needs. To that end, they’ve established a website meant to offer a forum for the bitcoin community to interact with the core developers, similar to bitcoin classic’s town hall forum approach, as well as to explain as simply as possible the positions of the core group vis a vis issues such as the blocksize cap.
Their position/solution is called “Segregated Witness” aka Segwit, is a rather elegant hack that doubles the amount of transaction that can be held in a block, doesn’t increase the size of the blocks, and is backwards compatible. (As a side note, terming the proposal Segregated Witness, which sounds like the title of a detective novel set in the pre-bellum South, is a brilliant example of a linguistic disconnect between the technically and non-technically minded.) Essentially, Segwit drops the signatures from the transaction blocks and sets them up in their own, parallel blocks.
A technical explanation may be found on the site or checking out the transcript of Pieter Wiulle’s presentation to scaling bitcoin Hong Kong. And for an excellent visual explanation of how Segwit works, check out the infographic made by bitcoin subreddit contributer u/cryptoconomy.
The community is now engaged in a vigorous debate on the merits of bitcoin classic versus Segwit. In true democratic fashion, most seem to favor both. Democracy likes compromise.
The new Democratic Consensus
So it seems we have arrived at a new era of democratic governance by two different paths. Bitcoin Classic emerged from a rebellion against the Core’s approach, which was conservative or paralysed depending on one’s perspective. Perhaps the classic group realized more quickly the ramifications a more diverse bitcoin ecology would have; billions in venture capital; massive mining conglomerates; mega exchanges; SPV wallets and various other products comprise powerful demographics with lots of skin in the game, lots of influence, and lots of opinions. Ignore at your own peril.
Additionally, Mike Hearn’s behaviour demonstrated the danger in having an insulated elite that more or less makes decisions on behalf of the community. Their legitimacy was based on respect for their outsized contribution and knowledge which, when combined with internal consensus, was enough. Once cracks emerged in consensus, it was a short walk for renegade developers to grab the code, introduce a larger block size and a few other bits and bobs, and lobby support behind it. Perhaps Hearn’s heart was in the right place, though his quitting sure did make him seem a tantrum-inclined egoist. The democratic process, with its additional level of legitimacy, should better guard against a future evil Mike Hearn.
It will also most likely dumb things down. Most of us are not adequately technically versed to meaningfully contribute to the conversation. A recent tweet by Gavin Andresen unwittingly shows us the danger of a more democratic protocol:
6,039 words in the segregrated witness BIPs versus 615 in the draft “2MB bump” proto-BIP. I like segwit, but it it is not simpler.
— Gavin Andresen (@gavinandresen) February 1, 2016
People are most likely to prefer bumper stickers to technical specs. We should take heed of the sage words of Isaac Asimov:
“Anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that ‘my ignorance is just as good as your knowledge.'”