What Happens When Bitcoin Developers Disagree?
Fred Wilson, writing in AVC, nicely sums up the ideological underpinnings of the current scaling debate: “Should Bitcoin be Gold or should bitcoin be Visa”? Jon Evans in techcrunch expands on the comment, assigning, a bit too neatly perhaps, the former school of thought to most bitcoin core developers and their supporters, the latter to bitcoin-Xt (RIP) proponents – most notably Mike Hearn, whose “whiny ragequit” brought the debate primetime.
This divergence of opinion is nothing new, though it has gotten progressively louder as the network draws closer to the blocksize cap. However, the bitcoin-xt episode changed the rules of game, which brought into stark focus the issue of how decisions are and ought to be made in a network with no central control.
Bitcoin as Visa
As we have written elsewhere in greater detail, developers Mike Hearn, Gavin Andresen, and Jeff Garzik view the blocksize cap of 1 MB, which will be hit at some point in 2016, as an artificial impediment to the growth of the network. Tagged a “fee event” by Mr. Garzik, this will result in competition amongst transactions for inclusion in blocks, leading to inflating fees that will eventually “price some actors out of the system”. This would, of course, greatly undermine the ideal of bitcoin as visa, or a ubiquitous settlement system cheaply managing thousands of transactions per second rather than the current seven tps.
Mr. Garzik argues that, contrary to what one might assume, doing nothing is not actually the conservative or cautious approach. A fee event fundamentally alters today’s bitcoin economy, which he characterizes as something of a transaction fee “race to zero” in which all comers generally get their transactions processed within a few cycles at most. Another, more comprehensive examination of this point can be found in Peter Rizun’s fascinating presentation on blockchain economics given at the Scaling Bitcoin Montreal conference. He applies the term “deadweight loss” to the current blocksize cap, which is an economic term applied to production quotas which artificially limit free-market equilibrium. To add an exclamation point to the whole argument, this 1 MB cap was temporarily added in early days to prevent against DDoS spam attacks, and was meant to be lifted – Thus Spoke Nakamoto.
Adherents to this school of thought feel both a sense of urgency in dealing with the impending fee event as well as frustration at the reluctance of the most active core developers to sort out the issue once and for all. Mr. Hearn, specifically, took the argument to the public with his launch of bitcoin-xt, an alternative network with a larger block size that would require a hard fork once a consensus of 75% was achieved.
The eventual repudiation of this idea by the market precipitated Mr. Hearn’s disowning of the bitcoin project in a very public mike-dropping in which he tagged the core developers as “completely controlling the system”, leading to a network characterized with, among a number of additional points, “wildly unpredictable fees and rising fast…controlled by China…in which companies and people building it were in open civil war.” Ignoring his contribution to the last point, is he right?
Bitcoin as Gold
Bitcoin as goldists would argue that we already have excellent networks for a visa-level amounts of transactions per second – visa for instance does a good job – and what makes bitcoin unique and valuable is its position as a decentralized store of value – uncensorable, available for anyone, and immune to manipulation. While most would agree that for bitcoin to appreciate in value the user base must expand – and thus higher transaction volumes must be accommodated – this takes a backseat to maintaining bitcoin’s core value proposition. From this perspective, the urgency to do something, and to do it fast, loses it’s edge.
And what exactly does the growing transactional demand consist of, a developer might argue? What percentage of transactions come with the prefix micro, transfers often worth fractions of pennies? Is it the place of the bitcoin blockchain to facilitate such tiny transactions that are at times worth less than an appropriate fee? Visa works just fine for your every-day needs, the bitcoin network should not and can not support these types of transactions. Will a fee event simply push these transactions, which might be considered network spam, out of the blocks in favor of transactions able to pay a fee? Yes, we need to sort out scalability, but this molehill is not a mountain. And thus, what Mr. Hearn sees as a matter of existential importance the core developers do not, and they view Mr. Hearn’s means to his ends as much more dangerous.
First, many in the community take umbrage in the manner by which Mr. Hearn broke rank to push his particular vision for bitcoin’s future. Unable to garner the necessary support using the standard bitcoin innovation proposal (bip) method, he cloned the bitcoin software, implemented his desired changes, and put it out to the public as an alternative, pending consensus. After 75% consensus would be reached, there would be a hard fork and the network would begin running on the new client. The danger in this is obvious.
Second is, of course, the danger of a hard fork. A hard fork is a change at protocol level that is not backward compatible. In the event of a non-universal split, it would lead to two entirely different blockchains, something with the potential to do existential damage to the network. See here the core developer stance on hard forks, a policy that was established after Bitcoin-Xt. It is important to note that deploying a hard fork has not previously been done, and there has been no real-world testing on how miners, wallets, exchanges and developers would cope.
And perhaps most importantly is the effect that an increased block size could have on miner centralization – an issue the core developers see as existential.
Creeping miner centralization is a problem that already exists, but would most likely exacerbate by the introduction of larger blocks. The majority of hash power is based in China where internet speeds are slower than in the West, and outgoing transmissions must deal with additional latency from the great firewall of China (GFC). This becomes even more pronounced the bigger the transmission, or blocks in our case.
Imagine a scenario in which two different mining pools, one based in China the other in the United States, solve a block around the same time. Both of these pools then relay the solution to the network – one would think the US miner, benefiting from having much faster internet as well as the majority of nodes residing in closer proximity, would have his block propagate more quickly. The Chinese block thus has a better chance of being orphaned, i.e. belonging to a shorter chain and thus not receiving the mining reward as subsequent blocks are appended to the other chain.
Actually, it’s more likely the opposite. Mining outfits utilize a central relay network, which quickly transmit messages to one another first to avoid the above scenario. They receive successful block messages faster than non-mining nodes do. However, the GFC slows this down, meaning that mining operators within China will see compatriot blocks prior to western miners seeing it, and vice versa. This encourages the addition of hash power within existing geographic groups, forming a sort of mining majority cartel to lower stale block rates (blocks that end up not being the longest, meaning rewards are invalid). This would serve as a pressure point if governments -i.e. China – wanted to slow down or disrupt the network.
Additionally, if these geographically clustered miners were just a bit evil, they would fill up blocks with tons of transactions – to the max – effectively slowing down the transmission of the message to the different geographic clusters. Every second between the block being found and the block reaching those other miners is a second in which those other miners are wasting time mining old blocks. Follow the scenario through to its end and one easily sees how the mining network is incentivized towards centralization. Peter Todd was fretting over this point way back in the beginning of 2013, and explained it better than I.
Additionally, the core group worries that larger blocks will cause a reduction in the number of full nodes in the network. Running the full blockchain on a computer takes up space, and larger blocks will take up more space. Though new computers can handle the size without much of an issue, it will no doubt impact at least some full node computers. The number of nodes is a key indicator of network health, and doing something that diminishes node amount is thus counterproductive.
Check out our next article on bitcoin governance, in which we flesh out how difficult it is to come to an agreement in a decentralized system.