Bitcoin is heading into a wholly avoidable crisis, according to one camp of developers. It is being forced to evolve, according to the other. How it’s all happening is as much at issue as whether it will all work out.
Perhaps you’ve heard that Bitcoin is forking. In fact, a fork is only one possible outcome of the current situation: A faction of the core development team has splintered off, proposed a new and controversial version of Bitcoin, and is now standing back to see whether people will adopt it. That’s dangerous because if these developers to have their way, the Bitcoin blockchain would have to bifurcate into two competing, incompatible chains, and thus two distinct currencies. And if a split like this does not happen in a clean, organized fashion, it could potentially cause chaos for every participant in the Bitcoin network.
(To get up to speed on how the Bitcoin blockchain works, watch this video. We’ll wait right here until you’re done.)
A fork happens when a patch gets incorporated into the Bitcoin software that changes the rules of the game so substantially that the new version is no longer compatible with the old version. Miners—the computers that actually do the work of managing Bitcoin—running the new version begin adding blocks to the blockchain that get rejected by anyone who is running a previous version, and vice versa. So you end up with two, new transactional records growing in tandem.
In March of 2013, the core developers inadvertently caused a fork when they released an update that they didn’t realize would not be backward compatible. Although the chain split, the situation was rectified with remarkable speed when all of the miners on the network agreed to revert to the previous version.
The whole experience was a close call and a reminder of how critically important it is for all of the Bitcoin cogs to remain synchronized. And when the 2013 fork went down, Mike Hearn, a Bitcoin developer who took responsibility, summed up the situation in this way: “This sort of thing illustrates the dangers of Bitcoin and is perhaps one reason the developers tend to be more conservative about it than others.”
Ironically, Hearn who, among other things, wrote the java implementation of the Bitcoin protocol, is also one of the developers behind this latest fork attempt. The difference is, this time it’s intentional: The fork is being used as a referendum on a controversial amendment to the Bitcoin protocol.
Here’s the crux of the argument (which you can read in Hearn’s own words here): Bitcoin has a scaling problem. The blockchain, which records every Bitcoin transaction and which grows incrementally, is limited in how much data it can hold. A new block gets added every ten minutes (on average). But each block can only contain 1 megabyte worth of transactions. Most people agree that as Bitcoin grows and more people want to use it the block size limit will become a problem.
Dynamic fixes are in the works. But so far, the community has yet to reach a technical consensus on what the best solution looks like. Some argue that simply changing the block size would centralize mining operations, making the currency more vulnerable to manipulation. Others have voiced passionate opinions about how such an intervention would change transaction fees (the voluntary fees that users pay miners to expedite payments). A meeting has been scheduled to take place this September in Montreal to address the ideological concerns and to plug away at the solutions.
But there are those who think Bitcoin’s scaling problem deserves immediate, emergency attention, and after initially engaging in debate, they have decided to cut the deliberations short and throw the matter to a vote. On 15 August, Mike Hearn and Gavin Andresen (who recently stepped down as the lead developer of the Bitcoin core and who now acts as chief scientist for the Bitcoin Foundation) released an update called BitcoinXT. The update puts into effect BIP 101 (BIP stands for Bitcoin Improvement Proposal), a patch that increases the block size to 8 megabytes on 11 January 2016 and doubles the size every two years until it reaches a limit of 8,912 megabytes.
There is, however, a trigger embedded in the code. The backward-incompatible features of the new version only turn on if 75 percent of the mining nodes adopt it. Every hour, the BitcoinXT software monitors how many Bitcoin nodes are running the new version by looking at a version specification that gets stamped into each new block.
If not enough miners agree with the changes, then nothing will happen and Bitcoin will chug along just as it always has. But if the BitcoinXT software detects that three quarters of the miners are on board, then the switch will flip and the fork will begin.
After that, there’s really no telling what would happen. But only one scenario—where everyone switches at the same time—is ideal.
Unfortunately, it’s simply impossible to know whether a consensus has been reached until the changes go live. In a perfect world you would gauge not only whether miners have adopted the changes, but whether users have done so as well, because any users who do not switch over—either because they weren’t aware of the update or didn’t agree with it—will be left making transactions on the old chain. However, it’s not technically possible to identify how many users there are, let alone what version they’ve got downloaded. Miners are the only ones casting the official votes.
(Here’s an example of what can go wrong: Say I keep my Bitcoins in two different wallets, one a smart phone wallet, one on my computer. But they are running two different versions. If I know it and I want to manipulate it, I can spend the same Bitcoins on two different blockchains. If I don't know it, I could receive payment in one wallet and think I have the coins in the other, but I don't and overspend.)
And tallying those votes is actually even more complicated and less clear cut than I explained. After BitcoinXT came out, someone in the opposing camp released a protest version called NotBitcoinXT which is solely designed to cast doubt on any claims of consensus. NotBitcoinXT is in fact identical to the core (old) Bitcoin software but every block it mines gets stamped with the BitcoinXT version code, thus lying about its vote. Mining with NotBitcoinXT is like going to the polls and pulling the lever for one presidential candidate and then walking outside and telling a reporter that you voted for someone else. Except that it’s way more dangerous, because it means that ultimately a fork could be ratified with far less than the 75 percent participation rate.
NotBitcoinXT threatens to inflict harm and delegitimize either of the two chains that prevail. And so we’ve reached the cryptocurrency version of a nuclear stand-off.
“I’m not sure who implemented it, but that someone would sooner or later make counter-measures was predicted. People warned Mike and Gavin about this likely outcome. It seems like they misjudged the human factors. Anyway, here we are,” says Adam Back.
Back is a cryptographer who invented the proof-of-work algorithm that is the foundation of Bitcoin’s security model. More recently, he has been working on an additional functional layer to Bitcoin called Sidechains. And he has been one of the most vocal opponents to the BitcoinXT fork proposal. What follows is an edited conversation with him about the controversies leading up the BitcoinXT release, as well as his response to the tactics employed by the XT developers.
Morgen Peck: BitcoinXT is the first proposal for an intentional fork of the Bitcoin blockchain. Those who support the change argue that Bitcoin needs a larger block size in order to accommodate increased adoption. But you’ve argued that such a a change is likely to asymmetrically benefit large-scale miners. Can you explain how a larger block size would lead to increased centralization?
Adam Back: The worry with extremely large blocks is that they can be used to exacerbate a selfish mining attack. If you’ve got a large miner or a couple of large miners, they can create very large blocks and other people won’t be able to receive them or process them in time. So, they will gain an advantage in mining.
Bitcoin chose its parameters to make the advantage minimal so that it’s a level playing field between small miners and large miners. Right now, the interval between Bitcoin blocks is ten minutes. And the approximate time it takes to propagate, or send a block after it’s found, across the peer-to-peer network is about 10 or 15 seconds. You want the ratio between the propagation time and the block interval to be high enough, because, as a miner, while you’re waiting to receive a block, or while you’re processing a block to check it’s valid, you’re unable to mine. So, you lose money.
By having larger blocks, it’s going to take a longer time to process them. So, it’s going to favor miners with higher bandwidth or who are more centrally connected via high speed links to other miners. It gives them an advantage.
If you increase the block size rapidly, the level playing field is eroded. If it gets eroded too much, once miners are able to create blocks that only they and a couple of other big miners can mine, they can exclude everybody else because [other miners] can’t keep up.
MP: If BitcoinXT succeeds, do you think we’re likely to see many individual miners drop out of the game?
Back: If the block size goes up a lot, it chews up a lot more bandwidth. And people have other uses for that bandwidth. So, if it degrades their ability to watch YouTube, or to play online games, or makes their VOIP provider unusable or something, they’ll turn off the full node.
MP: Why should Bitcoin users care whether mining becomes more centralized?
Back: People need to understand what Bitcoin is. What is it that makes Bitcoin interesting? If you say it’s the fact that it’s permissionless, so that anybody can use it without permission from anybody, and it’s policy neutral, so you can pay anybody and nobody’s going to judge payments, or block your payments, or revoke your payments and that kind of thing—the fact that those properties are possible is because Bitcoin is a peer-to-peer system. Policy neutrality is implemented by decentralization.
Also, the fact that it’s a politically neutral currency—it doesn’t depend on a group of banks, it doesn’t depend on a government, it has the virtual gold-like property—many of these things depend on Bitcoin being reasonably decentralized.
MP: In his article introducing BitcoinXT, Mike Hearn broadly characterizes the opposition as standing firmly against any increase in the block size and claims that a faction of the core development team has obstructed rational proposals to scale Bitcoin in a way that would encourage more widespread adoption. Do you think this is a fair characterization?
Back: That’s simply, factually incorrect. There’s BIP 100 that Jeff Garzik posted, which was before Gavin’s. There’s BIP 102, which is also Jeff. There’s BIP 103, which Peter Wiulle made. There’s another by Greg Maxwell, which may be the most promising, called FlexCap, which doesn’t have a BIP yet. And to say that people don’t want to improve scaling, I mean that’s almost insulting, because people like Peter Wiulle and Greg Maxwell spent something like a thousand hours over the last year or so—mostly volunteer time—optimizing Bitcoin for scaling in terms of memory and CPU. The fact that it’s even possible to change to a larger block size, just in terms of the ability of CPUs and memory to handle it is down to that work. So, to say that those same people are not interested in scaling Bitcoin is ludicrous.
MP: But it is true, isn’t it, that you would like to see scaling happen in a way that allows for some transactions to occur off the main Bitcoin blockchain?
Back: It should be clear to people from a computer science background that blockchains have some inherent limitation and you can’t expect—in a time when it’s reached maximum adoption, where everybody’s cup of coffee or internet transactions, all of the shares and derivative transactions—these things to all fit on a blockchain. We would be saturating the Internet at that point.
There has to be a balance, right? So, if you want to scale Bitcoin, that’s good. And everybody wants to scale Bitcoin. But you can’t scale Bitcoin by just changing the block size parameters to a gigabyte or something ridiculous. Because, what would happen if you did that now is almost nobody would be able to validate it to receive a transaction. And there would end up being one or a handful of miners in a data center. And at that point you may just as well switch the mining off and sign the transactions and call it PayPal or something.
MP: There is also some economic tinkering going on here, isn’t there? Bitcoin transactions are subject to a voluntary fee, paid out to the miners. What happens to this fee if BitcoinXT is successful?
Back: They want to increase the block size because it will drive transaction fees to zero. Because people only have an incentive to pay any transaction fees if there’s any shortage of space.
MP: If, as you say, everyone can at least agree that it is necessary to improve the scaling of Bitcoin and to prepare for a future in which the transaction load substantially increases, how would you like to see this problem get solved?
Back: There are new protocols which can give a lot more scale without using on-chain space. This is the Lightning protocol. And it’s really an algorithmic improvement. I think some of the other proposals also include block size increases. But they’re trying to balance also some work on decentralization and some work on actually trying to improve scalability with the recognition that you can’t fully scale Bitcoin to its full potential by increasing this parameter.
But [the Lightning protocol] is relatively new. It’s not fully validated right now. So, if we have a couple of years, things will look different.
I think the reasonable balance in this situation is to increase the block size temporarily from let’s say one to two megabytes immediately, from two to four over a period of two years, and from four to eight over the next two years, to give four years of time where the block size is growing at the same rate as Gavin has proposed even. And that will give us time to see the effects of these other protocols.
MP: At the moment, it is entirely unclear whether Mike Hearn and Gavin Andresen will garner the support they need to fork the Bitcoin blockchain. But if it does happen, then one of many scenarios will play out. In an ideal world, everyone would rally around a single version of the blockchain. What are the less savory, potential narratives? What could go wrong?
Back: If 25 percent of the network doesn’t agree, then it’s quite bad, because the two versions of the network can diverge. Coins can be spent on both sides and people will make mistakes.
MP: So do you think it’s even possible to solve this problem with a hard fork? What would that take?
Back: The only way for non-backward compatible protocol changes to happen is if everybody agrees unanimously to do it and works in concert to make that happen smoothly. What you want is for everyone to be aware it’s happening, for really, literally everybody to upgrade all full nodes.
There are a range of things that can go wrong. I think mostly what people are saying is we should act very carefully. Everybody should be in agreement and we should try to do this in concert. You don’t want to rush ahead and break Bitcoin’s security to scale it now. A scaled solution that is broken is also not a good outcome.
MP: In a way though, BitcoinXT is also an avenue toward consensus. Hearn claims that Bitcoin’s core development team has reached gridlock and says he’s forcing a vote that would otherwise never take place. So, what’s wrong with that?
Back: The timing was exceedingly odd. In the past they might’ve said progress was slow, but they did this after two months of active progress. We were rather hoping in the circumstances that they would be collaborative and work in the process with everyone else. It seems like they were irritated that their proposal was not automatically winning.
In a way it’s less the details of the proposal and more the attempt to bypass the scientific review process and impose one design by lobbying, blogging, and populist campaign. I mean, what kind of message does it send. Should everyone else write a web page and go lobby companies? It’s not a constructive way forward and magnifies the risk of the fork failing. If it fails in an uncontrolled way it could be as much fun as a euro exit.
MP: If the blockchain forks and BitcoinXT prevails as the dominant chain, then that also establishes a new core team of developers, with Mike Hearn and Gavin Andresen in sole custody of the source code. How would this change the long-term governance of Bitcoin?
Back: Gavin naively thinks he'll do the coup, force the issue, and then invite people to participate in the coup. However, Mike states on the BitcoinXT website that he is the final decision maker (or benevolent dictator as he puts it). So, its clearly intended to change the decision making process. And Mike has not been without bias and controversy.
It seems quite unlikely from indications I see that any of the core people who maintain Bitcoin's security will participate in BitcoinXT. It is therefore not clear that BitcoinXT will have the resources or expertise to maintain it's safety and security.
MP: Even if core Bitcoin wins and the blockchain remains in the hands of the core development team, surely this episode has revealed the fragility of Bitcoin’s protocol governance. You have said that you would like protocol updates to be subject to more scientific review. How would that work?
Back: I look at the NIST design review process [for the SHA-3 cryptography algorithm] as an exemplar. Performance and security were in a tradeoff for a security critical application. They evaluated SHA-3, had some design competitions, multiple designs were submitted, they were evaluated, and eventually the cryptographers and security people decided what was best and that became standardized.
This story was corrected on 21 August 2015: A previous version conflated node adoption of BitcoinXT with miner adoption of BitcoinXT.
