How would faster blocks cause mining centralization?

Question

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

Answer 1

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.

^{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:

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%!

Conclusion

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.}

Answer 2

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.