Taking an unconventional approach, Core developers proposed to reduce the block size to 300KB first, and then increase it to 31MB year by year

The block size debate, a long-standing defining challenge facing the Bitcoin technical community, has taken an interesting turn in the last month.

The years-long discussion about how best to scale the $15 billion bitcoin network has largely become a two-pronged debate between those who support a 1MB block size increase via Segregated Witness (SegWit) and those who support a hard fork to increase the block size to 2MB or more .

So far, you may have noticed that neither party has called for a block size reduction.

However, Bitcoin Core developer Luke Dashjr submitted a Bitcoin Improvement Proposal (BIP) to the Bitcoin Development Mailing List, “Three BIPs Related to Hard Forks”, expressing the view of reducing the block size.

Specifically, Dashjr’s proposal suggests temporarily reducing the block size to 300KB (starting from the time this BIP is activated), and then slowly increasing the block size year by year to reach 31MB by 2045.

The proposal was submitted on January 27, just before the Bitcoin network was congested and the number of unconfirmed transactions exceeded 60,000 before slowly decreasing.

In a more detailed proposal, Dashjr cited the amount of disk space currently required for the bitcoin blockchain — currently around 100GB — as a prohibitive factor for those who want to run a full node (hardware that stores the complete transaction history of the blockchain ledger).

Dashjr wrote:

“Today we often hear new users complain about how long it takes to install a Bitcoin node. Some older community members recommend that they downgrade to non-full wallet software and not run a full node. However, this will result in new users only getting Bitcoin as a currency, rather than becoming Bitcoin security itself. If this situation expands, it will undermine the integrity of the Bitcoin network as a whole.”

Dashjr’s views are not unexpected, as the vitality of the bitcoin node network has become an obvious political football in this scaling debate.

Without a vibrant network of nodes, developers worry that the operation of the Bitcoin ledger will fall into the hands of a few large operators, undermining the decentralized nature of the Bitcoin network.

The community has a lukewarm response to the proposal

Although the block size reduction proposal has received the most attention in recent times, the proposal actually calls for a 17% increase in block size each year to keep pace with the growth in bandwidth in recent years.

But subsequent discussion criticized the 17% annual increase as too conservative and failing to take into account the non-linear pace of technological change - especially considering future developments.

Overall, the proposal did not receive widespread support from the community, with most responses on the mailing list criticizing the proposal.

However, the block size increase may not be the only controversial point. Dashjr’s proposal requires a hard fork, which could split the Bitcoin network if it fails to gain consensus (even the definition of a hard fork seems to be controversial at present).

Bitcoin Core contributor Johnson Lau responded by saying that he believes both increasing and decreasing the block size is undesirable .

"To me, both approaches lack innovation and responsibility."

He also expressed a common sentiment that hard forks are too dangerous at the moment. He added:

“1MB, whether you like it or not, that’s the current consensus. Any attempt to change this size limit (increase or decrease) would require broad consensus from the entire community, which is very difficult to achieve.”

This may explain why the revised Dashjr proposal released by developer Andrew Chow (which canceled the block size reduction and directly increased it year by year from 1MB) also failed to gain a warm welcome from the community.

Some people support the plan

Dashjr cited a Twitter poll in discussing his proposal, which showed 20% of participants in favor of lowering the block size — far from a majority, but a large portion that thinks it’s worth considering.

However, he also pointed out how difficult it is to make changes to the network when a majority of the hashrate is required to accept them.

He said:

“Many people think that if my proposal is implemented, it will take 7 years for the block size to increase from 300KB to 1MB, which is too long. Polls show that many people prefer it to be faster. Also 10% of the survey participants are against any hard fork that permanently increases the block size - this would basically kill any chance of such a proposal gaining consensus.”

Based on the feedback received from the community so far, Dashjr said he has no plans to develop the BIP draft and will not apply for formal proposal coding.

However, if support for lowering the block size exceeds 20%, some of Dashjr’s ideas may resurface in the future.