I've heard that faster blocks would cause mining to become more centralized. How do these things fit together?

2 Answers 2


Why faster blocks?

This conversation often starts with someone pointing out that shortening the block interval would allow for a quicker first confirmation, reduce variance in mining revenue, and could provide more blockspace.

Beyond the fatal argument that such a change would require a hard fork, the responses usually point out that confirmations would still be too slow for point-of-sale scenarios even at feasible shorter block intervals, thin clients would be more expensive due to the larger blockheader count, and it would cause more frequent chaintip reorganizations. I want to explore the last argument further.

How do reorgs happen?

Bitcoin is a distributed system. Propagating a new block in the network takes time. Even if every node could message every other node directly that a new block was found, the limited speed of light would still result in a notable delay until every other node would receive this message. After nodes hear about a new block, they still need to validate the block before forwarding it to their peers (although nodes may permit their peers to forward before validation in the high-bandwidth compact blocks relay mode). Miners can only build a new block template after validating the block, and then it may take some more time to update all devices to the new instructions. So, while the successful miner can immediately switch over, the other miners continue to work on a competing block for a short time window. If another miner finds a competing block before hearing about the other, they'll announce it as well. From the point-of-view of each miner, their own block was seen first and they are on the best chaintip.

Block Propagation Delay History via DSN Research Group, Kastel, KIT

Over the years, improvements in block propagation and validation have lowered this latency. The number of chainsplits and stale blocks got reduced from about once or twice every day to once every two weeks.

Why are reorgs bad?

Hashrate working on a competing chaintip does not go towards the proof-of-work securing the best chain. Frequent reorganizations make the first confirmation less reliable.

While mining itself is progress-free (every hash is an independent event with a chance to find a block), the author of the latest block has the advantage that they can immediately start mining the next block.

How much does the propagation latency benefit larger miners?

Let's assume it takes 6s for a block to reach other miners and compare 60s vs 600s block intervals for miners with 5% vs 30% of the hashrate. 6s is a very rough estimate for the time until most nodes have received a block after Compact Blocks.

The propagation delay is both an advantage and disadvantage: it gives the author a headstart for the next block, but also gives time for a competing block to emerge which may oust the author's block. Let's assume that each author works on their own chain, and the remaining hashrate is split half-half on each competing chaintip.

Finding blocks is a Poisson process that we can model such:

Chance for events in a Poisson process

We can calculate the chance of finding one or more blocks in a time interval by starting with a probability of 100% and deducting the chance of finding 0 blocks. The chance to find 0 blocks in a time frame where we'd expect λ blocks is p(0|λ) = exp(-λ)*(λ^0)/(0!) = exp(-λ)*1/1 = exp(-λ).

600s block interval

Given a 600s block interval, we'd expect 0.01 blocks to be found in 6s by 100% of the hashrate, 0.05×0.01 = 0.0005 blocks to be found by the 5% miner, and 0.0030 blocks by the 30% miner.

As noted above, we'll simplify to expect half the remaining hashrate to work on a competing block whenever one is found. In case of the 5% miner the split is therefore 52.5% to 47.5% of the hashrate, and it's 65% to 35% for the 30% miner.

The author wins either when they find another block during the headstart or when their collaborators find the next block, and loses when both a competing block is found and it sires the successor: P_loss = (1-e^(-λ_comp))×comp/2×e^(-λ_self)

(That's a simplification, because we don't cover the case where both sides find at least one block in the headstart time window, but the competitors find more blocks.–I think we can get away with it.)

Small miner: P_loss = (1−e^(−0,0095))×0,475×e^(−0,0005) = 0.0045. I.e. the 5% miner mines at a handicap of 0.45% and has an effective hashrate of 5%×(1-0.0045)=4.98%.

Big miner: P_loss = (1−e^(−0,007))×0,35×e^(−0,003) = 0.0024. I.e. the 30%-miner mines at a handicap of 0.24% and has an effective HR of 30%×(1-0.0024)=29.93%.

60s block interval

Given a 60s block interval, we'd expect 0.1 blocks to be found in 6s by 100% of the hashrate, 0.05×0.1 = 0.005 blocks to be found by the 5% miner, and 0.030 blocks by the 30% miner.

At 60s blocks for the small miner: P_loss = (1−e^(−0,095))×0,475×e^(−0,005) = 0.043. I.e. the small 5%-miner mines at a handicap of 4.3% and has an effective hashrate of 5%×(1-0.043)=4.79%.

At 60s blocks for the big miner: P_loss = (1−e^(−0,07))×0,35×e^(−0,03) = 0.023. I.e. the bigger 30%-miner mines at a handicap of just 2.3% and has an effective hashrate of 30%×(1-0.023)=29.3%. At the same handicap as the smaller miner, the big miner would only have an effective hashrate of 28.7%!


We see that going from 600s blocks to 60s blocks, a 5%-miner goes from a 0.45% handicap to a 4.3% handicap, but a 30%-miner goes from a 0.24% handicap to a 2.3% handicap.

Also, the stale block rate would increase from one every ~100 blocks to about one in every ~10 blocks; increasing the portion of hashrate not contributing to security, the chance of multi-block reorgs, and easing majority and selfish mining attacks.¹

In effect, an individual miner contributing to a 5%-pool would make about 0.2% more money by joining a 30%-pool at 600s blocks, but the same move would gain 2.1% more money at 60s blocks.

However, when mining hardware is abundantly available and the exchange rate becomes less capricious, it would be expected that miners continue to invest in building out their hashrate as long as there is more money to be made. Eventually, an equilibrium would be reached where miner margins would be pretty tight, and less efficient miners would get pushed out of the market. Then, profit might be a small portion of the revenue. If profit were e.g. only 10% of the revenue, 2.1% more revenue would translate to a profit increase of 21%.

Note on assumptions
• 6s propagation is a bit long¹
• Remaining hashrate would not be split 50:50
• Headstart is not explicitly modeled

¹ Note that miners actually have a lower latency to each other than 6 seconds or we would actually see a stale block every day, but we actually only see them a few times per month.


A by-product of faster block times is larger storage requirements to store the chain data, also faster disks and faster network to propagate and sync these updates.

Based on this assertion, the cost of hosting the infrastructure of a mining pool goes up. A single copy of the chain is not too bad to think about in terms of costs, but when considering multi-site, multi redundant nodes.

Fast blocks also require faster disks and faster network. 10 minute blocks vs 1 minute blocks vs 6 second blocks and lower.

The miners themselves may be scattered geo-politically around the world, however, if they are getting their jobs from a central mining pool, or 2 or 3 of them, then this is where the centralization argument becomes relevant.

  • Faster blocks would not necessarily mean larger storage requirements. One minute blocks of 400,000 wu would have almost the same storage as 4,000,000 wu blocks every ten minutes. Smaller blocks would also propagate a tiny bit faster, but not to the same degree, so latency would remain an issue even when storage wouldn't change much.
    – Murch
    Commented Jul 13, 2022 at 14:21
  • I'm not understanding your comparison. 1 minute blocks after 1 year > 10 minute blocks after one year. The storage requirements at the end of year 1 are higher for 1 minute blocks, because there are more of them. Am i missing something?
    – Mylo Mylo
    Commented Jul 27, 2022 at 8:35
  • If you have 10 1-minute blocks with a tenth of the current block weight, that would not significantly increase the storage requirement over having one 1 10-minute block with the current block weight. However, the minimum latency (speed of light) remains the same even when you have smaller blocks.
    – Murch
    Commented Jul 27, 2022 at 10:05
  • What do you mean by "weight"? Block with no transaction size is: 2kB for example, header data etc. In 10 hours: 1 min blocks = 600 blocks = 600 x 2kB = 1.2MB 10 min blocks = 60 blocks = 60 x 2kB = 120kB Mining pools may only be sending out "jobs" or "shares" but they still need to maintain low-latency high speed networks to remain competitive. Connecting to 100s of peers to receive the latest block, to send the new block's jobs to miners. The storage is 10x for empty blocks. Network bandwidth & data are also higher with more blocks than less blocks. Leads to higher costs.
    – Mylo Mylo
    Commented Aug 10, 2022 at 18:18
  • The segwit softfork replaced the 1,000,000 byte blocksize limit with a 4,000,000 weightunit blockweight limit: bitcoin.stackexchange.com/a/53626/5406. The header data on a block is exactly 80 B, which would translate to about 38 MB more data per year for the additional blockheaders when going from 10 minute blocks to 1 minute blocks.
    – Murch
    Commented Aug 10, 2022 at 18:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.