<p>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.</p>
<p>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.</p>
<p>Fast blocks also require faster disks and faster network. 10 minute blocks vs 1 minute blocks vs 6 second blocks and lower.</p>
<p>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.</p>

CC BY-SA 4.0
2022-07-13T14:21:04.723Z
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
CC BY-SA 4.0
2022-07-27T08:35:10.097Z
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
CC BY-SA 4.0
2022-07-27T10:05:57.897Z
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
CC BY-SA 4.0
2022-08-10T18:18:07.617Z
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
CC BY-SA 4.0
2022-08-10T18:25:30.673Z
The segwit softfork replaced the 1,000,000 byte blocksize limit with a 4,000,000 weightunit blockweight limit: https://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
CC BY-SA 4.0
2022-10-25T18:37:42.573Z
That is useful, but complicated info to grok in one hit. Sorry for the delay & thank you for persevering with the explanation.

I see where I have been led astray - I have been looking at equihash blocks, which have 2kB of header info, and the blocks I have been basing my case for contain regular multi-sig transactions >1kB.

Given the 80 B header & 128 B transaction for a coinbase, my argument of additional storage doesn't hold at all on those numbers, regardless of a decade long collection of data on either 10min or 1 min blocks.
Mylo Mylo
CC BY-SA 4.0
2022-07-13T10:14:54.070Z
2022-07-13T10:14:54.070Z
Mylo Mylo
<h2>Why faster blocks?</h2>
<p>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.</p>
<p>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 <em>it would cause more frequent chaintip reorganizations</em>. I want to explore the last argument further.</p>
<h2>How do reorgs happen?</h2>
<p>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.</p>
<p><a href="https://i.sstatic.net/Dm3QG.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Dm3QG.png" alt="Block Propagation Delay History" /></a> <sup>via <a href="https://www.dsn.kastel.kit.edu/bitcoin/#propagation" rel="nofollow noreferrer">DSN Research Group, Kastel, KIT</a></sup></p>
<p>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.</p>
<h2>Why are reorgs bad?</h2>
<p>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.</p>
<p>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.</p>
<h2>How much does the propagation latency benefit larger miners?</h2>
<p>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 <a href="https://www.dsn.kastel.kit.edu/bitcoin/#propagation" rel="nofollow noreferrer">most nodes have received a block</a> after Compact Blocks.</p>
<p>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.</p>
<p>Finding blocks is a Poisson process that we can model such:</p>
<p><a href="https://i.sstatic.net/cI3lo.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/cI3lo.png" alt="Chance for events in a Poisson process" /></a></p>
<p>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 <code>0</code> blocks in a time frame where we'd expect <code>λ</code> blocks is <code>p(0|λ) = exp(-λ)*(λ^0)/(0!) = exp(-λ)*1/1 = exp(-λ)</code>.</p>
<p><strong>600s block interval</strong></p>
<p>Given a 600s block interval, we'd expect <code>0.01</code> blocks to be found in 6s by 100% of the hashrate, <code>0.05×0.01 = 0.0005</code> blocks to be found by the 5% miner, and <code>0.0030</code> blocks by the 30% miner.</p>
<p>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.</p>
<p>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: <code>P_loss = (1-e^(-λ_comp))×comp/2×e^(-λ_self)</code></p>
<p>(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.)</p>
<p>Small miner:
<code>P_loss = (1−e^(−0,0095))×0,475×e^(−0,0005) = 0.0045</code>. I.e. the 5% miner mines at a handicap of 0.45% and has an effective hashrate of <code>5%×(1-0.0045)=4.98%</code>.</p>
<p>Big miner:
<code>P_loss = (1−e^(−0,007))×0,35×e^(−0,003) = 0.0024</code>.
I.e. the 30%-miner mines at a handicap of 0.24% and has an effective HR of <code>30%×(1-0.0024)=29.93%</code>.</p>
<p><strong>60s block interval</strong></p>
<p>Given a 60s block interval, we'd expect <code>0.1</code> blocks to be found in 6s by 100% of the hashrate, <code>0.05×0.1 = 0.005</code> blocks to be found by the 5% miner, and <code>0.030</code> blocks by the 30% miner.</p>
<p>At 60s blocks for the small miner:
<code>P_loss = (1−e^(−0,095))×0,475×e^(−0,005) = 0.043</code>.
I.e. the small 5%-miner mines at a handicap of 4.3% and has an effective hashrate of <code>5%×(1-0.043)=4.79%</code>.</p>
<p>At 60s blocks for the big miner:
<code>P_loss = (1−e^(−0,07))×0,35×e^(−0,03) = 0.023</code>.
I.e. the bigger 30%-miner mines at a handicap of just 2.3% and has an effective hashrate of <code>30%×(1-0.023)=29.3%</code>. At the same handicap as the smaller miner, the big miner would only have an effective hashrate of 28.7%!</p>
<p><strong>Conclusion</strong></p>
<p>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.</p>
<p>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.¹</p>
<p><strong>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.</strong></p>
<p>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, <strong>profit might be a small portion of the revenue</strong>. If profit were e.g. only 10% of the revenue, 2.1% more revenue would translate to a profit increase of 21%.</p>
<p><strong>Note on assumptions</strong><br />
• 6s propagation is a bit long¹<br />
• Remaining hashrate would not be split 50:50<br />
• Headstart is not explicitly modeled</p>
<hr />
<p><sup>¹ 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.</sup></p>

CC BY-SA 4.0
2022-04-28T18:20:51.460Z
2022-05-06T15:06:31.993Z
2022-05-06T15:06:31.993Z
Murch
<p>I've heard that faster blocks would cause mining to become more centralized. How do these things fit together?</p>

<mining-theory><mining-profitability><decentralization><block-interval><block-propagation-time>
How would faster blocks cause mining centralization?
Murch
# How would faster blocks cause mining centralization?

(Asked by: username_0 on 2022-04-28)

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

**Tags:** mining-theory, mining-profitability, decentralization, block-interval, block-propagation-time


---

## 2 answers

### Answer by username_0 on 2022-04-28. Score: 13 | Accepted answer

## 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](https://i.sstatic.net/Dm3QG.png)](https://i.sstatic.net/Dm3QG.png) via [DSN Research Group, Kastel, KIT](https://www.dsn.kastel.kit.edu/bitcoin/#propagation)

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](https://www.dsn.kastel.kit.edu/bitcoin/#propagation) 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](https://i.sstatic.net/cI3lo.png)](https://i.sstatic.net/cI3lo.png)

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 by username_1 on 2022-07-13. Score: 0

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.

> **Comments:**
> **username_0**: 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.  
> **username_1**: 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?  
> **username_0**: 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.  
> **username_1**: 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.  
> **username_0**: The segwit softfork replaced the 1,000,000 byte blocksize limit with a 4,000,000 weightunit blockweight limit: https://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.  
> **username_1**: That is useful, but complicated info to grok in one hit. Sorry for the delay & thank you for persevering with the explanation.  I see where I have been led astray - I have been looking at equihash blocks, which have 2kB of header info, and the blocks I have been basing my case for contain regular multi-sig transactions >1kB.  Given the 80 B header & 128 B transaction for a coinbase, my argument of additional storage doesn't hold at all on those numbers, regardless of a decade long collection of data on either 10min or 1 min blocks.  

---

