Bitcoin Core Devs in ‘Civil War’ Insist We’re Not Getting The Whole Story

Bitcoin has never been a boring technology. At first glance you might figure that a seemingly tiny design decision, Bitcoin's "blocksize," would be a departure from that. But the debate, which has been raging for years, is far from boring (we're talking about a debate where a data scientist wrote a 18-page paper analyzing the Bitcoin subreddit to determine whether fake accounts were rigging the discussion). And it seems to have reach a high point with a recent proposal to split the network.

But developers think that recent coverage is getting it wrong. When I talked to Bitcoin developer Peter Todd, he called more than one article "embarrassing," arguing that he and other developers needed to do better at getting the facts out.

Backing up, what's the blocksize? Every 10 minutes, a Bitcoin block filled with transactions is added to the blockchain, each of which supports a maximum of 1 MB worth of transactions. Developers Gavin Andresen and Mike Hearn announced an upcoming January fork, the code is called XT, which is exactly like Bitcoin Core, but with the blocksize limit raised to 8 MB. Users can now download and run a Bitcoin XT node in a "vote" to leave the the current network. (Motherboard's Sarah Jeong breaks the controversy down further.)

Many outlets note the blocksize increase is controversial, but fail to mention the fork's unpopularity among Bitcoin's most active protocol developers, including Wladimir J. van der Laan, Gregory Maxwell, Pieter Wuille, and its community of volunteers.

These developers claim that the "schism" is more like two rogue developers against everyone else (and then there are a few out there, like Bitcoin core developer Jeff Garzik, who seem in the middle). Nick Szabo, whom some suspect is Bitcoin's original creator, called it a "reckless act to be performing on a $4 billion system," sided with a more conservative fork, and posted a photo of a heartbreaking space shuttle disaster with the caption, "What happens when the managers and investors ignore the engineers and scientists…."

The blocksize increase aims to avoid what Hearn calls a "crash landing," where Bitcoin nodes "die" and people have to suffer through a backlog of Bitcoin transactions, potentially damaging Bitcoin's reputation. Bitcoin developer Peter Todd argued that most developers think that this scenario is unlikely. It didn't play out when Bitcoin brokerage company Coinwallet.eu flooded the Bitcoin network, filling blocks in a so-called stress test. Still, Hearn argues that the Bitcoin network will run into trouble as it hits the 1 MB blocksize, which may be the next time Bitcoin's price swells and transactions increase alongside it.

Furthermore, developers are irked that Andresen is often called Bitcoin's "Chief Scientist" in this articles. Andresen served as Bitcoin's lead developer for years, but has not contributed much to the Bitcoin Core software since he stepped down last year. He's still Chief Scientist of the Bitcoin Foundation, but the organization doesn't have anything to do with development anymore. MIT Media Labs recently took over developer funding. Similarly, Mike Hearn has hardly contributed to the protocol, although he's worked on Bitcoin payment channels and developed the Java client.

Back to the technical debate. Bitcoin isn't good at handling lots of users and transactions—far from it. "There's strong consensus among practically everyone that blockchains fundamentally don't scale well," Todd said, pointing out that even Andresen says that raising the blocksize is "just a short-term 'kick the can down the road' fix."

When I asked Hearn whether the blocksize increase was a short-term fix he said, "Probably not. The very first question ever asked about Bitcoin was essentially this, and Satoshi showed with some basic calculations that hardware improvements were very likely to outpace Bitcoin growth for decades into the future."

Bitcoin works better than it did years ago. That's because its core developers have coded up dozens of fixes. Developer Greg Maxwell listed a handful of the "literally hundreds" of ways developers have enhanced Bitcoin scalability to support more users. He argued that if most, or all, of the scalability-focused developers are raising concerns, then others should be more cautious of supporting the fork. While the scalability developers are carefully calculating each coding decision, Maxwell likens the Bitcoin XT crew to a "guy standing on the sidelines with a beer cup hat."

There might be a better way of scaling Bitcoin in the long term, and that's adding extra layers to it, similar to the internet. Lightning Network is a "layer 2" protocol that supports off-chain transactions that ultimately settle on the blockchain, or "layer 1." It supports faster transactions at a larger volume.

That's not the whole story either. Developers are working on it, sure, but it will take time. That's why it's hard for developers to pin down the best possible scalability solution. Gavin and Hearn have a point when they ask what will happen in the mean time. Next month developers and academics are meeting in Montreal for a scalability workshop to discuss potential solutions.

There's no shortage of opinions. Richard Brown, executive architect for banking innovation at IBM UK, noted that both sides are weighing imperfect options. And still other developers contend that the fork's risk is blown out of proportion.

Even so, it's worth considering that those closest to Bitcoin's scalability problems are worried about what will happen.