Why Bigger Might Not Be Better For Bitcoin Scaling

The block size debate, long one of the defining challenges hanging over bitcoin's tech community, took an interesting twist late last month.

A years-long discussion about how best to scale the functioning $15bn economic network mid-flight, the debate has largely been characterized by a face-off between those who would increase the 1MB block size via an efficiency improvement called SegWit, and those who want to change the hard-coded block size limit to 2MB or more.

You'll notice that, so far, neither side has called for a block size decrease.

But that was exactly the view represented in a Bitcoin Improvement Proposal (BIP) submitted to the bitcoin-dev mailing list by Bitcoin Core developer Luke Dashjr, in a message titled "Three hardfork related BIP’s".

Specifically, Dashjr’s proposal suggested a temporary block size reduction to 300KB (dependent on the date that the BIP was activated), slowly rising in yearly increases to a limit of 31MB in 2045.

The timing of the proposal, released on 27th January, came just days after a huge increase in transaction backlog saw unconfirmed transactions spike to over 60,000 before returning to lower levels.

In a more detailed proposal, Dashjr cites the amount of disk space demanded by the blockchain – currently around 100GB – as a significant disincentive for anyone wanting to run a node, hardware that stores the full ledger history.

Dashjr writes:

"It is a regular occurrence to see new users complain about the time to setup a node, and established members of the community recommending downgrading to non-full wallet software, which results in the new user gaining bitcoin as a currency, but not the security of bitcoin itself, and compromises the integrity of the network as a whole by widespread usage."

The remarks are not surprising as the viability of bitcoin's node network has emerged as one of the more prominent political footballs in the debate.

Without a vibrant node network, developers fear that the operation of bitcoin's ledgers will fall into the hands of a few big operators, thus defeating the purpose of a decentralized payment network.

Cool reception

Although the proposed reduction is what has garnered most attention, the proposal actually calls for an annual block size increase of 17% per year, intended to keep pace with the growth rate in bandwidth seen in recent years.

But critics of the ensuing discussion have suggested that this figure is overly conservative, and that it does not account for the non-linear pace of technological change – especially when projected into the future.

In general, the proposal has seen little support from the wider community, with most responses on the mailing list expressing skepticism toward the proposal.

The block size decrease might not have been the sole point of contention, however. Dashjr's proposal requires what's called a hard fork, a way to upgrade a blockchain that can split the network if not all participants agree. (Even this definition, it seems, remains contentious).

Bitcoin Core contributor Johnson Lau responded to argue that neither a block size increase nor a decrease is desirable. "For me, both approaches just show the lack of creativity, and lack of responsibility," he said.

He further expressed the common view that a hard fork would be too dangerous right now, adding:

"The 1MB is here, no matter you like it or not, it’s the current consensus. Any attempts to change this limit (up or down) require wide consensus of the whole community, which might be difficult."

This might explain why even a modified version of the proposal, which removed the block size decrease, released on 5th February by developer Andrew Chow, failed to generate enthusiasm from list members.

Some support

Discussing his proposal and the response with CoinDesk, Dashjr cited a Twitter poll that showed 20% support for a block size decrease – far from a majority, but a large enough number to merit serious consideration.

However, he also pointed out the difficulty of moving forward with modifications to the network when a supermajority of hashing power is required to accept them.

He said:

"Many seemed to think seven years before the increases began was too far out. A poll showed the majority would prefer it sooner. But that same poll shows that 10% oppose any hard fork that increases the block size limit ever – which basically kills any chance of such a proposal gaining consensus."

In light of the community's response, Dashjr said that he did not intend to develop the BIP draft any further at the present time, and would not be pursuing it to the point of receiving an official proposal number.

If there really is 20% support for a reduction in block size, though, some of Dashjr's ideas may still reemerge through other channels in future.

Tiny food image via Shutterstock