Opinion: There is No Block Size Problem


This is the guest post by Eugene Radchenko from AIRA DAO on blocksize debate and related issues. The views expressed are his own and do not necessarily represent the views of Forklog.

In recent months, the issue of Bitcoin’s block size increase has become a burning point separating the community. Some stand for it, others demur, and most of those people use general concepts to prove themselves right. However, when it comes to actual facts, both sides tend to engage in personalities or start ignoring the opponent. That’s what happened almost anytime I tried to talk about it.

As for me, I most definitely support the idea of increasing block size. The material below is to explain why, with facts and numbers only.

Block Size and Data Storage Systems

The basic argument used by block increase naysayers is their concern that the blockchain will swell so bad that people will lose any incentive to run full nodes. However, the naysayers forget that data density in storage systems grows as well. Let’s take a look at the numbers.

Image and data by idema.org

Image and data by idema.org

This is Seagate’s roadmap for ten years’ time. What can we see from this figure? It’s 2016 now, and the year corresponds to density of 1 to 1.3 Tb/in2. If we visit any computer store, we’ll see it sells HDD with 1 to 1.3 TB plates. Thus, the roadmap data almost precisely correlate with those numbers. This means that by 2025 average HDD will have 10 TB capacity. It means that actual memory will grow by 1 TB a year.

Getting back to Bitcoin, let’s assume block size remains 1 MB, with 100% usage of blocks. As there is roughly 1 block mined every 10 minutes, there are nearly 6 MB mined during an hour’s time, 144 MB a day, and 52,560 MB a year. The table below shows other options for block size.

Block Size

The table below shows both HDD and blockchain capacities increase.


As we can see, there’s nothing fatal in increasing block size to 8 MB. An abrupt relative growth in the first two years will end by 2020. In addition, it’s worth reminding that we base on the assumption that blocks are 100% full, which usually just doesn’t occur. Anyway, blockchain size at current growth rates of data storage density will not be able to outpace average HDD capacity. In order to do so, the block size should be around 20 MB.

Data Transmission Speed

Let’s consider another argument popular with block increase haters, the block transmission speed. There are two aspects here.

  1. Internet speed. Rest assured the situation here is pretty similar to that with HDD’s. Just recall 2005 or 2006. What was your internet speed back then? Moore’s law is still applicable, and there’s no sign that it will cease to be so as yet. It gets extrapolated to all technical advancements.
  2. Speed of block finding may impact mining speed of particular nodes. It means that if a block is found by Node 1, the node will have an edge as long as other nodes get the same block. This aspect is often levelled out by aspect one. Moreover, there’s nothing that prohibits you to start mining at the moment when Node 2 gets a new block’s header, and check it for consensus when the complete block is downloaded. It’s a purely development issue.


The next popular argument is centralization. There are gradually less bitcoin nodes, and I agree with the concerns, but I disagree with the solution, or in fact total lack thereof. Retaining 1 MB blocks is hardly a solution. Artificial limitations imposed on the system’s scalability is a cul-de-sac for me. I believe that rewarding full nodes with coins is way more reasonable. Why people don’t want to run a full node? It involves additional personal expenses. Why don’t we reimburse their costs at least partially? There are examples of cryptocurrencies doing so, like Dash. Particular implementation of the concept is not the issue appropriate for covering here, however, I believe that countering centralization shall use rewarding full nodes in the first place.

Why Increasing the Block?

Here are some arguments why block size should be increased.

Black Friday. Everybody knows what it is. Just like everyone waits for to-the-moon. And now, let’s recall how the latter works. At some point in time, some people decide they’ll die without bitcoin and will buy it. The history tells us that the number of transactions grows abruptly at such instances. Let’s take a look at current block size.

Image and data by Blockchain.info

Image and data by Blockchain.info

Presently, we’re at 900 kB, or 90% of the system’s capabilities. Eventually, we might have an unpleasant situation, when an emerging to-the-moon will face insuperable technical difficulties. But even we discard our to-the-moon dreams, I believe that any financial system shall have a several-fold spare of scalability. With block size of 1 MB, there’s almost no spare left.

Security. In 2015, we all witnessed several companies standing for block size increase spamming the network. Many cursed them, though it hardly was the companies’ intent. When it comes to Bitcoin spamming, one should think about its cost in the first place. Those spamming periods were to demonstrate how cheap it actually is. Nowadays, the network processes nearly 7 transactions per second with minimum fee of 0.0001 BTC. It’s 420 per minute, 25,200 per hour, or 604,800 per day. Then multiply it by 0.0001, and its 60.48 BTC a day. Paralyzing Bitcoin doesn’t take huge investment. But as the block size increases, the amount will also increase proportionally.


So, what do we have now? We have a wonderful financial experiment dubbed Bitcoin supported by mathematicians, coders, and enthusiasts. But then it expanded in technical and monetary terms. An avalanche of price growth caused the community to grow, which, unfortunately, resulted in deterioration of its quality. Any proposal concerning the network’s development meets hatred from people too lazy to use a calculator, and who believe they are smarter than the developers. It all halts Bitcoin’s development and may eventually destroy it.
Hopefully, I’m wrong.

by Eugene Radchenko, AIRA DAO

Found a typo? Highlight text and press CTRL+ENTER

Subscribe to our Newsletter


Related posts

Tags: , , ,