When Clay Shirky said that “collaborative production is simple: no one person can take credit for what gets created, and the project could not come into being without the participation of many,” he could have been talking about Bitcoin. The digital currency was created anonymously, and is currently run by a handful of core programmers and a broad network of “miners” whose computers do the actual work of validating and publishing transactions, and an even broader network of “nodes” who help to maintain the public ledger of who sent what to whom. This is crowdsourcing almost at its purest. No one person decides what happens to the program, and no one person can unilaterally make a change to how it works.
While that no doubt has already raised some sceptical eyebrows, the system has worked pretty well since its initial roll-out in 2009. There have been differences of opinion, and accidents that needed fixing, but so far decisions have been made with the common good in mind. Because one of the beauties of this system is that the common good has, so far, equated to the individual good. If Bitcoin were to fail, all players would lose out.
The scene has changed, though. Now Bitcoin is coming up against a fundamental problem that has generated heated debate, with its share of prognoses of doom. The various sides are digging in, because each seems to be convinced that Bitcoin will fail if his adaptation isn’t universally adopted. This weekend core Bitcoin developers are gathering – apparently for the first time – in Montreal, Canada in the first (and sold-out) “bitcoin scalability workshop” to start the attempt to reach a consensus.
The upcoming problem is this: the volume of transactions is growing. It’s a problem because transactions are grouped into blocks for processing, and the original and current protocol stipulates a block size limit of 1MB. At first that wasn’t a problem, and even now, it’s not really an issue, as the average block size hovers around 425K. But if Bitcoin keeps growing, which it will, the limit is expected to be hit sometime next year. Smaller transactions will start to get pushed aside until a block comes along with space. The current confirmation time lag of about 10 minutes (the time between each block confirmation) could end up being hours or even days, which would seriously reduce its utility. We could end up in a bidding war, with miners giving preference to transactions with higher fees attached. Fees would climb to a level that would price out smaller transactions, which would further limit Bitcoin’s usefulness.
The debate is centred on the issue of a block size limit increase. Should there be one? And if so, to what? And when? It’s not a simple matter, as bigger block sizes can slow down the system and require even more bandwidth and energy to process. The main complication, though, comes from the democratic process. Opinion is divided. So who decides? Which option is best for the system as a whole?
The jury is still out on that, and will be at least until the end of the year. That’s when, effectively, the votes will be counted on the various proposals put forward by the Bitcoin factions (yes, I know, “votes” is an over simplification… I’ll talk more about this process another time). Let’s go over them:
- Stay as we are. This group doesn’t see any reason to touch the block size. Miners like the idea of higher transaction fees, as it means more profits for them. Most, however, do realize that if Bitcoin transactions slow down, its growth will be limited, which will eventually hurt their income. Another possibility is that Bitcoin continues to grow, but with more and more transactions being done on sidechains (more on these later), so the actual blockchain capacity won’t need to increase. Sidechains tend to not enjoy the same level of decentralization as Bitcoin. But larger blocks could also lead to an erosion of the fundamental decentralizing principle.
- BIP100. (BIP stands for Bitcoin Improvement Proposal). This proposal was authored by core developer Jeff Garzik, and stipulates a gradual increase of the block size, with thorough testing at each stage. This option is popular, largely due to the gradual increases proposed, and the voting power given to the miners. Every 90 days or so, miners can state what block size limit they would like to see, and the winning target becomes the new block size. This means that the block size can go down as well as up. The mining pools like this idea, but other major stakeholders (wallets, exchanges, etc.) worry about the concentration of influence.
- BIP101 – by core developer Gavin Andresen, this proposal also suggests that the block size be gradually increased over time, at a linear rate, starting from 8MB on 11th of January 2016, and increasing linearly up to 8,192MB on the 6th of January 2036. This proposal has received support from big players such as Xapo, BitPay, Blockchain.info and Circle, among others.
- BIP102 – another proposal by core developer Jeff Garzik (confused yet?), who proposes here an increase of the limit to 2MB. Jeff suggests this as an “emergency fallback” if consensus is not achieved on the other proposals.
- BIP103 (actually, for some reason this BIP doesn’t technically have a number, but people seem to be referring to it as BIP103) – Bitcoin core developer Peter Wiulle thinks that we should increase the block size by 17.7% a year, starting in January 2017. Why 17.7%? Apparently that’s the estimated amount needed to stay in line with technological growth.
- BIP105 – this is similar to BIP100 in that it lets the miners vote on block size increases. The difference is that BIP105 stipulates a cost to the miners if they vote for an increase. Miners would pay for an increase if it is profitable for them, but it would become costly to do so just to gain a competitive or political advantage. Although it sounds counterintuitive, adding a cost to a proposed increase would increase efficiency, as miners would not want to waste their resources on a vote unless they were reasonably sure that other miners would vote the same. BIP100 stipulates an upper limit of 32MB. BIP105 lowers that to 8MB.
- BIP106 calls for a dynamically adjusted block size limit, according to the previous block size, with the possibility of including the previous transaction fees in the calculation. If the average block size is almost full, double the size. If it’s not even half full, halve the size. If it’s sort of in the middle, the block size stays the same.
- Reassess. Adam Back’s idea is similar to BIP102 (Jeff Garzik’s suggestion that the block size increases to 2MB in the short term if no other solution has been agreed on) in that the increases only contemplate the short term, since no-one really knows what the Bitcoin world will look like in the future. Back proposes a 2MB increase as soon as possible, eventually going up to 8MB after four years. Once we get there, then we can reassess, and see if further increases are necessary.
There are actually a ton of other interesting ideas out there to solve the scalability issue, but these seem (to me) to be the main ones. How important is the question of size? That itself is open to debate. Satoshi himself said back in 2010:
It would be nice to keep the [block chain] files small as long as we can.
The eventual solution will be to not care how big it gets.
But it is worth bearing in mind that Satoshi started the ball rolling, and then left the developer community to continue with the experimentation, tweaking and adjustments. As with just about any invention, no creator can foresee all future bottlenecks, bugs and case scenarios.
More than the future of Bitcoin is at stake here. Bitcoin is more than an efficient payment system. It’s more than an entirely new way to transfer value and verified information. It’s a social experiment. Can we, as a group, manage a concept as potentially powerful as Bitcoin, without a clear chain of command? Are we capable of that level of teamwork?
Looking further ahead, a more interesting question than “Can we?”, is “What if we can?”.