Bitcoin Stability Threatened by Developer Rift

Share with your network!
"In the worst case scenario, if the miners and the rest of the bitcoin community end up in some kind of like full fledged war, that would basically wreck bitcoin." Mike Hearn “... the ledger will diverge as soon as a single double-spend happens, and never share a block again, companies will go instantly insolvent, and chaos will break out.” Adam Black The anonymity of Bitcoin makes it the payments system of choice for various forms of cybercrime. The massive recent growth in ransomware, for example, has been fueled in part by the ease of collecting ransom using Bitcoin, and it also facilitates Dark Net sales of drugs and other illegal merchandise. However, the current Bitcoin ecosystem is approaching a capacity limit, and in the worst (or perhaps best) case scenario, cybercriminals may be forced to find another way of transferring money. A bitter debate on the technical future of Bitcoin is currently raging on Reddit and more cogently on the Bitcoin developers’ mailing list and various blogs. Both sides agree that the proposed changes have the potential to do massive damage to the Bitcoin system, but the proponents feel that there is no alternative and are threatening to unilaterally take control of Bitcoin development to make this change. The debate revolves around a single parameter, the size of blocks on the Bitcoin blockchain. The blockchain is a distributed ledger that permanently records every Bitcoin transaction for all time. Currently Bitcoin miners create a new block about every ten minutes, and blocks have a maximum size of one megabyte. The new transactions go in that block, presuming they will all fit. This limits the current capacity of the Bitcoin system to about seven transactions per second. The actual block size created is a function of the number of transactions in that block. This has been increasing as the number of Bitcoin transactions grows, and is fast approaching the limit.
Bitcoin Block Size
The two sides in the debate differ on what will happen if this limit is reached. Mike Hearn, the leading proponent of the block size increase, believes it will be a “crash landing” with long delays in transaction processing causing a loss of faith in Bitcoin by both users and developers. On the other side, Bram Cohen, the developer of Bittorrent, describes this as a “fake crisis” and claims that the only impact on Bitcoin will be an increase in transaction fees, and that paying a higher fee will ensure faster processing for critical transactions. In either case, increasing the size of blocks on the blockchain would seem to be a simple change, so why not go ahead and make it? The problem is that the new blockchain would be incompatible with the old software. For this change to be successful, everyone mining bitcoin or running one of the six thousand or so full Bitcoin nodes that maintain the integrity of the distributed blockchain would have to upgrade to support the new larger block size. In the open source community this is called a “hard fork”. If some upgraded and some did not, it’s possible that we would end up with two incompatible blockchains, and that older Bitcoins could be spent twice, once on each blockchain. Currently five core developers maintain the Bitcoin code, along with a number of other volunteers. One of the core developers, Gavin Andresen the former lead developer, is a strong supporter of Mike Hearn’s proposal to increase the block size, and is working on the code changes to do this. The others, including the current lead developer Wladimir J. van der Laan, appear to be more cautions about the risks of a hard fork, and would like to consider other options such as reserving the main blockchain for high value transactions and processing others on side chains. In the past all changes have been made by first establishing consensus between the core developers and the wider Bitcoin development community. Though not formally codified, in practice each of the developers has veto power over any code change, and there have been very rare cases in which one developer has backed out a change that another has made because they were not happy with it. Mike Hearn was the sponsor of one of these vetoed changes, and as a result he appears to be dissatisfied with the Bitcoin change process. Hearn and Andresen did widespread lobbying of Bitcoin miners and exchanges in support of increasing the block size to twenty megabytes before submitting a formal proposal to the Bitcoin Improvement Process (BIP) that drives changes to core Bitcoin code. A lot of Bitcoin mining currently takes place in China, fueled by cheap hydroelectricity, and about 80% of all Bitcoin purchases are made there, either to speculate against the Yuan or to avoid Chinese exchange controls. Some Chinese Bitcoin miners claimed that the bandwidth limitations imposed by the Great Firewall of China would make the twenty megabyte block size impractical. Hearn’s initial response to this was to say that, "...if miners in China can't get the trivial amounts of bandwidth required through their firewall and end up being outcompeted then OK, too bad, we'll have to carry on without them.” However Chun Wang, the admin of the F2Pool which currently mines 20% of all Bitcoins, pointed out that China’s dominance of the Bitcoin market would create problems:
Ignorant. You seem do not understand the current situation. We suffered from orphans a lot when we started in 2013. It is now your turn. If Western miners do not find a China-based VPN into China, or if Western pools do not manage to improve their connectivity to China, or run a node in China, it would be them to have higher orphans, not us. Because we have 50%+.
In response the proposed increase was changed from twenty to eight megabytes, with further increases over time. While Andresen has finally submitted a BIP, Hearn has made it clear that he plans to go ahead with the change even if the Bitcoin core developers do not approve it, by trying to get the leading miners to accept Andresen’s version of the code rather than the Bitcoin core version. Two weeks after seventy five percent of the transactions on the blockchain are flagged as being compatible with the new system, the new size limit would take effect. However, Hearn's cavalier attitude towards Chinese miners does not seem to have made him any friends there, and the latest news is that the leading Chinese mining pools, who between them control 30% of all Bitcoin mining resources, have said that they will not run a unilateral hard fork of the Bitcoin code, and have insisted that Hearn and Andresen reach a consensus with the remaining core Bitcoin developers. Regardless of he technical merits of Hearn and Andresen’s proposal, some members of the Bitcoin community have expressed concern that if they are successful, control of the Bitcoin software would pass from a community operating by consensus to a dictatorship where one or two developers are making all the decisions. With the huge amounts of untraceable currency in the Bitcoin marketplace, those people would be subject to threats and blackmail from criminals or legal pressure from nation states. Andresen, on the other hand, has argued that successful open source projects require either a benevolent dictator or a clear voting system. It is interesting to see the Libertarian supporters of a crypto currency that is free of central government management claiming in their own community the need for the trappings of government, either democracy or fascism. Of course, in the long run the market will decide. People with either choose to upgrade to the new software or not. However, contrary to Libertarian dogma, markets don’t always make the right decision, and both sides in this debate agree that the consequences of a bad decision could be catastrophic for Bitcoin.