Is it better to lower the block size of Bitcoin?

Talking about religious or political topics at the table often leads to heated debate. Similarly, don't mention block size issues in front of Bitcoin enthusiasts. Today, asking for a reduction in block size is certainly controversial. Bitcoin itself is facing serious scalability problems. How can the problem be solved by making the block smaller? At least that is counter-intuitive.


Image source:

However, there are certain reasons for the smaller blocks. The less data in each block, the easier it is to check the transactions in it. As the transaction will be verified by more parties, the block will be more trustworthy. Moreover, from a philosophical point of view, the smaller blocks are consistent with the concept of decentralization of Bitcoin: the more active the participants verify the transaction, the stronger the resilience of the network.

Who doesn't want a more central, more resilient Bitcoin blockchain?

How small is the block?

Luke Dashjr, the advocate of the block, voted, and Bitcoin enthusiasts can vote for the community from August 1st to December 31st, 2019. If most nodes agree, the Bitcoin network will have soft forks that support smaller blocks.

As a Bitcoin core developer, Luke Dashjr explained on Twitter: "This patch will perform a very simple soft fork to reduce the Bitcoin block size to approximately 300kB." At that time, the block size is current. In the case of 1/3 (1 MB), these blocks, or more lightweight blocks, will contribute to block verification while suppressing the total weight of the BTC blockchain.


Block size reduction

Now is the right time to reduce the block size?

Interestingly, this is not the first time Luke has proposed this concept. As early as January 2017, he proposed a BIP (Bitcoin Improvement Program) that required the block size to be reduced to 300kB. However, at the time, his proposal was ignored. There are currently two situations that are making support and attention for proposals to reduce block size.

Node reduction

The number of active nodes on the Bitcoin network has been decreasing.

Here you need to simply add the following information: Two types of nodes allow users to connect to the blockchain.

– Fully validate the node (also known as the full node) and verify each transaction in the new block. Unfortunately, these nodes are expensive to operate and difficult.

– SPV nodes (simple payment verification nodes, also known as lightweight nodes) are easier to operate. However, it has two limitations: they need to access the blockchain through the full node, and they only accept but not verify the block's transactions.

Luke Dashjr warned that the number of full nodes has been reduced from 100,000 to 60,000 in the past year alone. This decline is worrying because the fewer the number of nodes, the higher the risk of network security. In fact, if the number of full nodes continues to drop, the lightweight node may one day have to resort to a centralized service to connect to the Bitcoin blockchain.

As explained by Blockstream's strategy director, Samson Mow, in Hard Fork's article, block size affects the degree of network decentralization: if the full node is too heavy, the network will eventually form a pole around the data center.

Lightning network is rising

In 2019, the way to solve the problem of higher cost and longer trading time for the block is obvious: let us transfer more transactions to the lightning network.

Bitcoin developers did not deny the damage caused by the block, but thought that using a second-tier solution would offset this problem. Lightning Network is such a second layer solution.

The timing of the Luke proposal may serve to convince some people. Vinny Lingham, an Internet entrepreneur known as the Bitcoin oracle, has been fairly neutral in past block size debates, but he now supports Dashjr.

Does the community support Luke?

In addition to the people who completely reject the block like Roger Ver, many cryptographers believe that Luke Dashjr is technically correct. However, they do not believe that switching to smaller blocks is the only solution.

For example, the problem of a decrease in the number of full nodes can be solved without changing to a smaller block. For example, a fraud proof patch can bridge the gap between a lightweight node and a full node. If a full node detects an anomaly in the block to be verified, it will issue a "fraud certificate" to the rest of the network as a warning to isolate the block.

It's worth noting that while fraud proves that it can address the overall security risks, it does not raise the security of lightweight nodes to the level of the full node.

The proposal was blocked by consensus

However, the problem of bitcoin block size is not a technical issue, it is a human problem. As a public chain, Bitcoin requires the consensus of most participants to upgrade.

Unfortunately, many Bitcoin enthusiasts are reluctant to make changes. Just as the "millennium bug" problem of the late 1990s (referring to some problems in computer programming, the computer may be handling the date and time after January 1, 2000, incorrect operation may occur, which may lead to some sensitivity The industrial sector and banks, government and other departments stopped working at 0:00 on January 1, 2000, and even catastrophic results. The unknowns brought about by structural changes completely prevented any upgrades. No one wants another BCH.

in conclusion

In summary, limiting the size of the block will simplify the verification process. The more people who can contribute to the verification block, the more reliable the network becomes, the more resilient it is, and the more decentralized it is.

Regardless of block size, network resilience depends on the authenticity of each transaction. Chain congestion will be a short-term trade-off for the block, but the community will soon ensure the sustainability of the network and the attributes of value storage.

As the debate progresses, consensus remains the biggest obstacle to any change. The technology is there, the theory is justified, but the application is elusive. Swinging thinking and mentality is much harder than patching a piece of code.