The Block Size Debate

By: David Marc
Updated: May 18, 2018

To raise the cap or not to raise the cap?  That is the question.

The bitcoin protocol was initially designed to allow 32 MB of data in transaction blocks, which offers support for approximately 64 transactions per second. High levels of spam, fears of denial of service attacks, and little need for what was then (and still is now) an extremely high limit led to the institution of a 1MB block size cap in 2010. This was considered to be a temporary move, to be scaled up when and if required.

There is now a difference of opinion among leading bitcoin developers as to the appropriate course of action to take vis-a-vis block size limit. Gavin Andresen, Chief Scientist at the Bitcoin Foundation, has led the charge for increasing the block size now. He has decided to force the issue by lobbying large interests such as exchanges, wallets, miners and merchants to support what is effectively an alternative client, Mike “rage-quitter” Hearn’s Bitcoin-Xt patch. Bitcoin-Xt will include a mechanism for increasing block size – first to 8 MB in a hard fork planned for January 2016 – then doubling every other year. A miner supermajority of 75% is required for each and every increase, including January’s. Miners signal agreement by placing a special message in the headers of their successfully mined blocks.  Apparently, Mr. Andresen has gotten 60% of the large miners on board to date.

There are differences of opinion, which will be briefed below, as to the efficacy of Mr. Andresen’s particular plan. However, Mr. Andresen circumvention of the standard processes by which core developers come to agreement – submit a BIP (bitcoin improvement proposal), debate, come to consensus or drop it – has raised the eyebrows of some in the bitcoin community. Does the pressing nature of block size scalability warrant what some view as a drastic action, or do the ends not justify the alteration of previously established means?

Arguments against increasing the block size now

The idea of a hard fork not universally agreed upon is a scary proposition. Failure to arrive at consensus – not just amongst miners but also wallets and merchants – could lead to parallel chains, a double spending nightmare scenario which would cause huge disruption to the bitcoin project and its four billion current market cap.

But leaving aside this nightmare scenario, many are concerned there will be additional unintended consequences. For instance, what effect will increasing block size have on node decentralization? A larger block size will result in fewer validating nodes as the amount of memory required to host the bitcoin client will increase accordingly. The argument suggests that the eventual result will be a few very large nodes validating transactions, an affront to bitcoin’s decentralized mandate.

While most mining interests support larger block size, there is a segment of Chinese miners who fear their relatively weak broadband service will place them at a disadvantage when hosting a much larger client. Some also argue that greater block size might also result in large transaction fee reductions, which could have negative repercussions as rewards begin to decline. In the absence of transaction fees and assuming low reward amounts, mining will no longer be profitable, leading to undermining and a corresponding threat to security.

The most vehement disagreement, coming from, among others, BitTorrent creator Bram Cohen in webmag Medium, is that Messrs Andresen and Hearn’s forceful pressing of the issue threatens a larger crisis in which, according to Mr. Cohen’s article, bitcoin could be “undermined by a developer who’s gone rogue, using his political influence to convince vendors…to accept his own extraordinarily bad pet solution to the problem, and as a result hurtling the entire ecosystem towards potential disaster.” He then describes what a hard fork might look like – again, a double spending catastrophe for the network.

He likens the current “compromise proposal” of an increase to 8MB, which has the support of 60% of the mining population, the equivalent of discussing whether to “stab someone with a 6 inch knife instead of a 12 inch knife”. And who says there is no drama in web development?!

Argument for increasing the block size now

Mr. Andresen’s main argument is obvious – failure to increase the blocksize will prevent the network from processing increased transactional demand and artificially limit growth, which is an objective fundamental to the project. “The intent”, he writes in a bitcoin foundation blog post, “has always been to raise the limit when transaction volumes justified larger blocks.” And while he admits that “‘Because Satoshi Said So’ is not a valid reason”, staying true to the original vision is important because it has inspired people to invest time and money in the project.

His extraordinary step of lobbying for the adoption of Bitcoin-Xt without developer consensus is a result of frustrations with an inability to reach agreement, any agreement, on an issue viewed by him as existential. Moreover, without specifying now the long term solution for future block size increases, the debate would continue to resurface over the years. Better to rip the bandaid off now, so to speak, and allow focus to return to more constructive issues. If nothing else, Mr. Andresen’s tactics have indeed forced the issue, and it seems most of the community recognizes that this issue must be sorted at once, one way or another.

As to the specific counter arguments – the argument that current transaction size do not warrant an increase are dismissed out of hand. First, while the network currently utilizes only 30% of block size on average, this is not a linear utilization. Blocks are mined at an average of once every 10 minutes, yet there can be unlucky spells in which block solutions are not found for much longer than that. If a few unlucky blocks occur one after the other, it can result in an extremely long transaction delays, dropped transactions and reduced faith in settlement efficiency. Additionally, the current cap will be hit sometime in 2016, and so preparation must begin now.

Mr. Andresen acknowledges the risk of centralization, but posits that growth in computer memory, if not continuing according to Moore’s Law (doubling every two years), should be able to handle increases along the lines of what is proposed. The average home computer should maintain the ability to host the client without overly negative effects to performance and overall memory. And for those that can’t, the emergence of more and more bitcoin products, many which require hosting of the client, provides somewhat of a counterbalance. As to the transaction fee reduction argument, he offers the obvious alternative view, in which blocks with more transactions will have a greater number of smaller fees, and thus should balance out. And the bitcoin-Xt proposal has the support of the Chinese mining community, who must be comfortable in the ability of their broadband to manage the proposed increase.

Jeff Garzik’s BIP100

The most promising alternative plan is Jeff Garzik’s BIP100, which notably emerged shortly after Mr. Andresen threw down the bitcoin-Xt gauntlet. (It is important to note that, since publication of this article, Mr. Garzik forced a hard fork of bitcoin, which spectacularly collapsed due to technical incompetence.  So take the rest of this section with a grain of salt).

In it, Mr. Garzik suggests removing the hard 1MB block cap and replacing it with a floating cap. This cap could increase or decrease quarterly by up to 100%, with 1MB and 32MB representing the lower and uppermost boundaries. There seem to be a number of advantages to this proposal.

In his commentary, he laments the lack of actual economic modeling for arriving at a decision, suggesting indirectly an arbitrariness in Mr. Andresen’s 8MB-doubling plan and making the case that such economic decisions should be put out to the free market. His BIP100 framework, in which the miners are offered frequent opportunity to arrive at blocksize increase consensus, takes the decision out of the hands of developers and pushes it out to the miners, who are closest to the ground and thus best suited to make these tactical economic decisions.

The proposal, without running any surveys, would seem to satisfy most demographics – those concerned as to the lack of scalability in the current hard cap; miners worried that current broadband services are not sufficient to handle a large increase; and those that don’t understand the pressing need for such a large jump in blocksize in the short term.

This episode has raised greatly the passions of some within the bitcoin community.  Motives have been questioned, feelings hurt, invectives thrown.  In our opinion all actors involved are motivated from a sincere desire to do what is best for bitcoin, and it would be best to put the knives away. Mr. Garzik makes an interesting point on the nature of the block size debate which we believe places things in their proper perspective. “Major policy changes in an open source project are messy,” he writes. “What would, in a central bank, be a closed door policy discussion is instead held out in the open, with all parties airing their opinions in an open forum. Transparency wins, even if sometimes a painful process”.  We sit together in this open boardroom. If we choose not to directly participate, we are at least offered a seat to watch this fantastic experiment, warts and all, take form.