Bitcoin has entered into a new phase of its existence. Prominent developers Mike Hearn and Gavin Andresen have made changes to the alternative Bitcoin implementation Bitcoin XT, designed to fork Bitcoin’s blockchain in order to allow for bigger blocks.
Bitcoin users and – in particular – miners are, therefore, faced with a choice. Will they support Bitcoin XT and vote for an 8 megabyte block-size limit – doubling every other year? Or will they stick to Bitcoin Core with 1 megabyte blocks, limiting the Bitcoin network to a maximum of seven transactions per second?
Or at least that is the choice as it is often presented. In reality, the possibilities are not binary. At the time of publication of this article, two other Core developers have proposed three more Bitcoin Improvement Proposals (BIPs) to increase the block-size limit, and an even wider spectrum of ideas has been suggested on the development mailing list, forums, chat rooms and other media. This article presents an – undoubtedly incomplete – overview of these ideas, categorized in six types of solutions.
Solution 1: No Cap on Block Size
A first option is a full removal of the block-size limit. Such a cap on the block size, after all, constricts the number of transactions on the Bitcoin network, which could become a barrier to adoption or utility at scale.
Satoshi Nakamoto originally implemented the block-size limit as a quick fix to avoid denial-of-service (D0S) attacks on the Bitcoin network. But since Bitcoin’s creator has gone silent, most of Bitcoin’s developers have come to believe that the block-size limit might actually serve more purposes than just the prevention of DoS attacks. The arguments to keep a block-size limit today are diverse, but can be divided into two main categories.
First, a block-size limit might be needed to avoid centralization of the Bitcoin network, and, in particular, further centralization of mining. Perhaps most importantly, bigger blocks would take longer to propagate to other miners when first found. A longer propagation time should lead to a higher orphan rate, as more miners would be mining on older blocks, while newer blocks are still finding their way through the network. That would, in turn, incentivize miners to join larger miner pools, as they find blocks more often, and therefore don’t need to wait for the propagation of new blocks as often.
Second, facing a diminishing block reward, and barring radical alternative solutions, scarcity in the blocks might actually be needed to secure a long-term income for bitcoin miners. After all, miners effectively sell the space in blocks to fill them with transactions. But if the space in these blocks is not scarce, competing miners could always undercut other miner’s fees in a race to the bottom, until fees reach a near-zero level and miners earn close to nothing to reinvest in hashing power. The end result could be an insecure network.
Solution 2: A Fixed Cap on Block Size
The simplest and current solution to solve this problem is the implementation of a fixed cap; a block-size limit set by Bitcoin’s core development team and embedded in the Bitcoin protocol. This fixed cap is currently still 1 megabyte, as set by Satoshi Nakamoto, but is slowly coming within reach as the number of transactions on the Bitcoin network continues to increase.
In order to prevent blocks from filling up, several other limits have been proposed. As a last-ditch effort before shifting his efforts to Bitcoin XT, Andresen suggested raising the block-size limit to megabytes– although this was never formalized into a BIP. A conglomerate of Chinese mining pools later indicated that 20 megabytes might be problematic, as “the great firewall of China” could limit the propagation of Bitcoin blocks over the network, and instead proposed a compromise to 8 megabytes. And since consensus was still not reached, Core developer Jeff Garzik recently submitted BIP102 to double the maximum block size to 2 megabytes in order to buy time to come up with better solutions. Naturally, every other size could be picked as a possible limit as well, whether it’s 4 megabytes or 400 gigabytes, or even a decrease in size as Core developer Luke Dashjr suggested.
A slight variation to this idea, as recently proposed by Core developer Sergio Lerner, is to hold onto the 1 megabyte limit, but speed up the block interval. If 1 megabyte blocks are found every five minutes instead of 10, that would allow for double the amount of transactions on the network while also decreasing confirmation times.
Solution 3: A Growing Cap
Arguably the biggest problem with a fixed cap – any fixed cap – is that it is hard to change. A change of the block-size limit requires a hard fork, meaning all users need to make the switch in order to not be left behind on the old blockchain. This is no easy feat on a decentralized network, especially if different participants of that network vary in their preferences. Furthermore, since the number of transactions on the Bitcoin network is optimistically expected to keep rising, while the cost of bandwidth and hardware is optimistically expected to keep falling, it is broadly assumed that the block size should grow over time.
This is why Andresen proposed a growing block-size limit. Based on Moore’s Law and Nielsen’s Law, his first public suggestion was to automatically increase the limit by 50 percent per year, which he later readjusted to 41 percent per year – or 100 percent per two years. Combined with an initial bump to 8 megabytes (a number picked in accordance with Chinese mining pools), he formalized this proposal in BIP101. Since it was not adopted by the Bitcoin Core development team, Andresen has programmed BIP101 into Bitcoin XT, to be triggered once 75 percent of hashing power has expressed support.
Another Core developer, Pieter Wuille, thinks Andresen’s preferred growth rate is much too progressive. Based on research by Blockstream colleague Rusty Russell, Wuille believes average internet connection speed will not be able to keep up with Andresen’s proposal. Wuille has, therefore, proposed to increase the block size limit by 17.7 percent per year starting in 2017, which he formalized in BIP103.
But much like the fixed cap, any set growth rate can theoretically be picked. Perhaps Russell’s revised figures – he now suggests 30 percent yearly growth should be OK – will lead to another BIP in the near future?
Solution 4: A Dynamic Cap
Regardless of the preferred figures, a set growth rate has its own problems. Most importantly, it typically includes predictions about the future – and no one can reliably predict the future. The growth of Bitcoin usage has proved to be rather unpredictable over the past years, and historic technological improvement rates defined by Moore’s Law or Nielsen’s Law are in reality not laws at all – rather, trends.
This is why some suggest that Bitcoin might need a dynamic cap instead of a fixed cap or a cap based on a set growth rate. A dynamic block-size limit would, much like the mining difficulty, readjust itself automatically, based on a pre-defined rule set. And again, there have been multiple ideas on how to define this rule set.
Another of Andresen’s suggestions is to readjust the block-size limit on the basis of the size of recent blocks. This in itself can be done in multiple ways, and Andresen agreed to take the average size of the last 144 blocks (about a day’s worth), and double it to represent the new limit. If the blocks of the past day were an average of 1 megabyte in size, the limit would automatically be set on 2 megabytes.
A similar proposal entailed to adjust the maximum block size once a certain threshold is reached. For instance, when a series of blocks would on average reach 90 percent capacity, the block size limit could automatically readjust upward. Or, if a series of blocks would not even reach 50 percent of the maximum allowed block size, the limit could automatically readjust downward.
But it’s also possible to use parameters not even directly related to the block size. The block-size limit could, for example, be linked to the total amount of fees in a block. Or it could be based on the mining difficulty, as proposed by Core developer Gregory Maxwell. As long as it’s an internal parameter, Bitcoin’s block size limit can be tied to it.
Solution 5: A Cap Chosen Through Voting
Almost all interesting dynamic cap suggestions, however, seem to have one common weakness: The data that informs the new dynamic cap on the block-size limit can often be manipulated. For instance, miners could send transactions to themselves in order to fill up blocks or to increase fees.
Therefore, a more transparent solution could be a direct vote, possibly on some kind of regular interval. This solution begs another question: Who gets to vote? An obvious option would be to allow all Bitcoin users a vote. But unfortunately, it’s not really possible to determine who Bitcoin’s users are, while it’s easy to game elections by posing as multiple entities.
However, it is possible to vote with bitcoin. This could easily be done by setting up burn-addresses as voting booths. Anyone could partake in the elections, though it would cost money to do so, as the bitcoin used to vote would be lost forever. This way, the side of the debate that is prepared to spend most bitcoin on its desired solution wins. Elections would literally, and intentionally, be up for sale.
It’s also possible to organize a one-bitcoin-one-vote election without the need to burn bitcoin. As endorsed by Core developer Peter Todd, bitcoin holders could vote on the block size with the bitcoin they control, meaning the biggest stakeholders in the Bitcoin economy would have most of the influence on the block-size limit.
And lastly, of course, there is the voting method that is already used to determine consensus within the Bitcoin network: hashing power. Hashing power currently gets to determine what the longest chain is, and it also could be used to vote on the block-size limit. This idea was formalized by Core developer Jeff Garzik in BIP100. BIP100 transfers the power to set the block-size limit from the Core development team to the Bitcoin miners by allowing miners to include a message into freshly mined blocks indicating they want to mine bigger – or smaller – blocks. If 90 percent of hashing power endorses either bigger or smaller blocks, the block-size limit will double or halve each 90 days.
As a possible downside of BIP100, miners – and especially large mining pools – would of course gain even more power over the network than what they have today. But at least it would be transparent.
Solution 6: Extension Blocks
A completely different solution is conceived by hashcash inventor and Blockstream CEO Adam Back. In what is perhaps the most advanced idea to date, Back proposed allowing so-called “extension blocks” on the Bitcoin network. In essence, extension blocks would be an opt-in solution. The 1 megabyte limit could remain intact, while users and miners who’d be willing to handle bigger blocks – say 10 megabytes in size – could run software to process these as well. This would introduce a new dimension to Bitcoin usage, as it would essentially create multiple blockchains with the same bitcoin – the 1 megabyte blockchain would simply be more secure than the 10 megabyte blockchain.
Furthermore, it would still be possible to accept, store and spend bitcoin on the 10 megabyte blockchain, while running only a full node for the 1 megabyte blockchain – or even no full node at all. Users could, for instance, run a full node for the 1 megabyte blockchain on which they store the bulk of their money, while using an SPV wallet for the 10 megabyte blockchain for day-to-day payments. Bitcoin would, of course, be transferable from the 10 megabyte to the 1 megabyte blockchain, though the decreased security on the 10 megabyte blockchain would suggest to wait for some extra confirmations before trusting the payment on the 1 megabyte blockchain.
Bonus Solution: Flexible cap
Finally, flexible caps deserve a mention. While not really a complete solution to the block-size issue as a whole – some type of limit still needs to be set somehow – flexible caps could relieve the Bitcoin network from a lot of stress. Separately proposed by Core developers Meni Rosenfeld and Gregory Maxwell, flexible caps don’t really have a hard limit on the maximum block size, but, instead, penalize miners for producing bigger blocks. As such, a sudden influx of new users, or a surge in transaction volume, would not lead to a severe backlog of transactions that could potentially crash the network. Instead, flexible caps would allow room for growth, while at the same time indicating the limit should be adjusted to improve network performance.
The Good News and the Bad News
The good news is that the block-size issue is being widely discussed by smart people coming up with inventive solutions. A number of new ideas have been proposed, while it’s also possible to combine different solutions into new proposals. A dynamic cap, for instance, could easily be combined with a voted cap. Or a flexible cap could be attached to a fixed cap. Or an extension block joined with set growth. It’s even possible to mix three or more solutions to construct a completely unique approach. And, who knows, maybe some genius mathematician or programmer will come up with an entirely novel long-term solution for the block-size issue.
The bad news, however, is that this long-term solution has probably not yet been conceived; every single possibility so far seems to effectively “kick the can down the road.” All sides of the debate acknowledge that Bitcoin will ultimately need additional scaling solutions built on top of the protocol layer, and possibly a revision of the funding structure to reward miners. Bitcoin is still an experimental work-in-progress, with no clear-cut solutions. In an often heated debate, that is the one thing practically everyone agrees upon.
