<blockquote>
<p>why not reduce the difficulty of PoW?</p>
</blockquote>
<p>I'm going to assume you mean we decrease the block interval, so that blocks are found more often than the current 10 minute target. Manually altering the difficulty would indeed allow blocks to be found faster, but only until the difficulty adjustment resets it.</p>
<p>So really, to change the block interval, you'd need to change the difficulty adjustment algorithm, so that the target time interval is shorter.</p>
<blockquote>
<p>If I understood correctly, this would speed up the mining of the blocks, so we could do more transactions for a still low cost and keep security, is that right ?</p>
</blockquote>
<p>Bitcoin's proof-of-work allows miners to <a href="https://bitcoin.stackexchange.com/questions/83951/how-does-proof-of-work-inspire-trust-when-the-work-is-just-guessing/83953#83953">turn energy into security</a>, so the <em>amount of energy spent per time</em> is equivalent to the <em>amount of security attained per time</em>.</p>
<p>So we could allow twice as many transactions per time, but assuming the amount of hashpower remains unchanged, <strong>we will still have the same amount of energy being spent per time to secure those transactions</strong>. This also means that at the moment of transaction confirmation, the &quot;security per transaction&quot; would be halved, since only half the time has passed. After two blocks, the transaction would have security equivalent to a single block's confirmation on the unaltered chain.</p>
<p>Related: this is why blockchains which claim to have 'faster finality than Bitcoin' are a farce: the Bitcoin network consumes more energy per time (and thus provides more security) than any other network. The number of blocks that have passed is meaningless as far as security is concerned, what really matters is <strong>the cost of rewriting those blocks</strong>. For example, rewriting 100 blocks of a low hashpower coin might be cheaper than 1 block on the Bitcoin network. So in this way the Bitcoin network's single block provides more security, more quickly.</p>
<p><strong>So, why don't we do this, and lower the block interval?</strong></p>
<p>With respect to the question you quoted, it is worth noting that halving the block time would be equivalent to doubling the block size, in terms of the computational, bandwidth, and storage (ignoring pruning) resources required. Doing so would put more strain on network nodes, as it would require more resources to run one. With an increase in required resources, we should expect that less nodes will exist, and that negatively impacts the degree of network decentralization. Having nodes remain as decentralized as possible is important for the bitcoin network, as the value proposition of the network largely depends on it.</p>
<p>As Pieter mentioned in the comments, another negative effect is increased block orphan rates. I'll copy the text from the link in Pieter's comment, which was written by Pieter, and is a great description of the issues with decreasing the block interval:</p>
<blockquote>
<p>There are two issues that get worsened by this:</p>
<ol>
<li>The shorter the inter-block interval is, the more advantage you're giving to an attacker. You see, blocks take time to propagate through the network to all miners, at the very least limited by the speed of light. Due to PoW resulting in a Poisson process for block generation time, there is a nontrivial chance for two blocks being found within a very short time of one another. If that period of time is so short that the first block has not had time to reach the miner producing the second, the second block will be a waste of power (both in terms of income and in security to the network). This wouldn't be a problem if it affected every miner equally, but it doesn't. More well-connected (geographically centralized) miners suffer less, as they're relatively closer to everyone. But most importantly, a 51% attacker does not suffer from this at all, as he only builds on top of his own blocks, and thus never needs to wait for propagation. For some numbers, at block interval 600s there is about a 0.83% chance that two blocks are produced within 5s of each other. With block interval 60s that goes up to around 8.0%. If block propagation takes 5s, that means giving a direct 8% cost reduction to a mining collusion attack.</li>
<li>Overall resource consumption for full nodes. If you have 10x more blocks of the same size, full nodes will need 10x more resources to verify history and maintain in sync (bandwidth, CPU, I/O, storage, ...).</li>
</ol>
</blockquote>
<p>In my opinion, considering these negative effects, the linear gains in scale achieved would not be worth the work and risks involved in pushing out a rule change like this.</p>

CC BY-SA 4.0
2019-07-16T01:37:22.817Z
This seems incorrect to me. Every transaction gets all the security corresponding to all blocks built on top of it. Increasing the rate of blocks would still result in the same security per transaction per time unit if the total hashrate is not changed. The other reasons for not doing this you point out are correct, but there is another one: increasing orphan rates (I've written about this recently here: https://www.reddit.com/r/Bitcoin/comments/cbfyue/why_10_minute_intervals/etff0pi/?context=3).
Pieter Wuille
CC BY-SA 4.0
2019-07-16T01:41:29.190Z
@PieterWuille hmm I think the distinction is that you would have the same amount of security, but now after two blocks, instead of just one. At the moment of transaction confirmation, you would have half the security. My answer wasn't very clear in this regard, I'll work on an edit of it, thanks for pointing that out.
chytrik
CC BY-SA 4.0
2019-07-16T01:59:44.107Z
Thank you for your answer!

So I have another question, with the proof of stake, the block security does not require heavy computation, does that mean it is less secure than proof of work ?
Thibault Santonja
CC BY-SA 4.0
2019-07-16T02:02:36.497Z
While true that if you halve the difficulty, blocks will be twice as easy to find at half the security, that doesn't answer the question *why wouldn't we do this*?
hedgedandlevered
CC BY-SA 4.0
2019-07-16T02:13:08.830Z
@ThibaultSantonja that should be posted as a new question, not just a comment :)
chytrik
CC BY-SA 4.0
2019-07-16T02:15:10.910Z
@hedgedandlevered true, I edited it to be more clear that the last bit includes the reasoning of why/why not.
chytrik
CC BY-SA 4.0
2021-05-18T13:21:01.587Z
This puts a lot of weight on the value of a confirmation, which doesn't seem that important as Pieter already explained above. This answer could be improved by elaborating the downsides of faster blocks.
Murch
CC BY-SA 4.0
2021-05-18T23:03:44.223Z
@PieterWuille I've edited this answer again to hopefully be more helpful, and as part of that I've copied the text you linked to above into it. If you'd rather post that text as an answer yourself, I'm happy to revert my edit.
chytrik
CC BY-SA 4.0
2019-07-16T01:32:47.733Z
2021-05-18T23:01:02.653Z
2021-05-18T23:01:02.653Z
chytrik
<p>Litecoin, Dash, and other bitcoin forks have taken this approach. There are a few issues which are not immediately obvious. </p>

<p>The big one though:</p>

<p><strong>Increased Data storage and transmission costs</strong></p>

<p>Although 1mb per ten minutes sounds very low, increasing that amount to 2-4 mb will prevent some very slow internet connections from being able to ever sync. </p>

<p>Today, the slowest internet available worldwide seems to be about 256kbps</p>

<p>If you wanted to, you could run a full bitcoin node on this wifi, though the initial sync would take a while. at 256kbps, or about 900mb/hour, syncing the blockchain would take about 250 hours, or 10 days. 
This is the key to bitcoin's relatively small block sizes: <strong>Even with this slow connection, it only takes 10 days to fully
   validate every transaction that has taken place in the last 10 years</strong> </p>

<p>Perhaps more importantly, a full day of 1mb blocks would take 576 seconds, or just under 10 minutes. This means that, daily, a person in a remote area with no internet connection, could come into town, sync the blockchain on very slow internet, participate in the local economy, all the while never needing to rely on any 3rd party to hold or verify their money. This allows the bitcoin blockchain to achieve a level of decentralization that many other blockchains lack.</p>

<p>Keep in mind that doubling the block size of the blockchain will not just double the time it takes to sync the blockchain, but rather more than double it, <em>because the blockchain will be growing faster while you are syncing</em>.</p>

<p><strong>Increased orphan rate</strong></p>

<p>Miners will have their blocks orphaned more often. This creates the incentive to join larger mining pools, since the larger a mining pool, the more miners will start mining on your block, rather than mining on a competing block at the same block height. This is much worse with <em>larger</em> blocks, rather than <em>more frequent</em> blocks, but either way, there is a point at which this increased benefit is not a trivial difference. Once the network matures, if there is a significant advantage, we would expect the market to eventually tend toward that "solution", which would increase centralization</p>

<p><strong>Decreased scarcity of on-chain data storage</strong></p>

<p>The fact that there is only 1mb available in bitcoin per 10 minutes creates what is essentially a bidding war on that 1mb. Although this is bad for the <em>medium of exchange</em> property of bitcoin in the short run, it may prove to be a very important characteristic in the <em>store of value</em> property in the far distant future as block rewards go to zero, as we now extra value from rarity: storing data on Bitcoin.</p>

<p><strong>Tradition</strong></p>

<p>The above were only theoretical, that is, assuming this idea was adopted, what system would result. In practice, the network would <em>surely</em> fork if such an event took place. If the past is any indication of the future, such a huge change would result in a (minority) fork, leaving bitcoin at 1mb and the fork at the changed size. Another part of what gives bitcoin its <em>store of value</em> property is that the underlying protocol is extremely change-resistant, and it is likely that it is "antifragile", that is, it is becoming more resistant to being changed/broken as attempts to change it have failed (see segwit2x, and numerous forks).</p>

CC BY-SA 4.0
2019-07-16T02:08:59.317Z
For "Decreased scarcity of on-chain data storage" point, this means that bitcoin is less and less interesting for daily transactions (and therefore of a relatively small amount) as it grows?

It will therefore be used exclusively for large amount transactions or when fees do not matter to the person making the transaction, is it right ?
Thibault Santonja
CC BY-SA 4.0
2019-07-16T13:04:25.380Z
Likely that eventually, bitcoin will be used for mostly for opening/closing of lightning channels (or some other implementation that requires only a couple non-reversible transactions to enable unlimited nearly free transactions)
hedgedandlevered
CC BY-SA 4.0
2019-07-16T01:45:34.883Z
2019-07-16T02:26:21.543Z
2019-07-16T02:26:21.543Z
hedgedandlevered
<p>The following seems right to me, but I haven't given it a ton of thought, so will be glad to be corrected:</p>
<p>There is free entry into mining; therefore (except for those with extraordinary skills or access to extraordinary resources) miners cannot (in expectation) earn economic profits (defined as profits in excess of what they could have earned elsewhere with the same inputs of capital and labor).  (If economic profits become positive or negative, then miners enter or leave until profits are driven back to zero.)   Therefore, to a good approximation, no change to the system can change the rewards earned by a typical miner.</p>
<p>Halving the block time (without changing the block reward) would have, to a first rough approximation, the following effects:</p>
<ol>
<li><p>The total earnings of all miners from block rewards would double.</p>
</li>
<li><p>The earnings of the average miner would stay fixed.</p>
</li>
<li><p>Therefore the number of miners would double.</p>
</li>
</ol>
<p>Presumably more miners means more security (at least over some range, as I'm quite sure that a system with one miner would be quite insecure) so at least part of what was lost in security from reducing the block difficulty would be gained back from the increased number of miners.</p>
<p>To make this more realistic, we should add a fourth effect:</p>
<ol start="4">
<li>The supply of transactions would double; demand would presumably be largely unaffected (unless the implied changes in security affected the number of people willing to use Bitcoin as a payment system).  This means that point 1) above should be modified to say that total rewards to miners would <b>less</b> than double, and might even fall.  You can then adjust points 2) and 3) accordingly.</li>
</ol>

CC BY-SA 4.0
2021-05-19T03:50:57.850Z
2021-05-19T03:50:57.850Z
WillO
<p>After reading <a href="https://bitcoin.stackexchange.com/questions/81698/why-is-increasing-block-size-in-the-bitcoin-network-considered-to-decrease-secur">Why is increasing block size in the Bitcoin network considered to decrease security?</a>, I have a follow-up question about increasing block sizes:
why do we not reduce the difficulty of PoW?</p>
<p>If I understood correctly, this would speed up the mining of the blocks, so we could do more transactions for a still low cost and keep security, is that right ?</p>

<mining-theory><block-interval><block-propagation-time>
Why not speed up block mining?
Thibault Santonja
# Why not speed up block mining?

(Asked by: username_0 on 2019-07-16)

After reading [Why is increasing block size in the Bitcoin network considered to decrease security?](https://bitcoin.stackexchange.com/questions/81698/why-is-increasing-block-size-in-the-bitcoin-network-considered-to-decrease-secur), I have a follow-up question about increasing block sizes:
why do we not reduce the difficulty of PoW?

If I understood correctly, this would speed up the mining of the blocks, so we could do more transactions for a still low cost and keep security, is that right ?

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


---

## 3 answers

### Answer by username_1 on 2019-07-16. Score: 2 | Accepted answer

> why not reduce the difficulty of PoW?

I'm going to assume you mean we decrease the block interval, so that blocks are found more often than the current 10 minute target. Manually altering the difficulty would indeed allow blocks to be found faster, but only until the difficulty adjustment resets it.

So really, to change the block interval, you'd need to change the difficulty adjustment algorithm, so that the target time interval is shorter.

> If I understood correctly, this would speed up the mining of the blocks, so we could do more transactions for a still low cost and keep security, is that right ?

Bitcoin's proof-of-work allows miners to [turn energy into security](https://bitcoin.stackexchange.com/questions/83951/how-does-proof-of-work-inspire-trust-when-the-work-is-just-guessing/83953#83953), so the *amount of energy spent per time* is equivalent to the *amount of security attained per time*.

So we could allow twice as many transactions per time, but assuming the amount of hashpower remains unchanged, **we will still have the same amount of energy being spent per time to secure those transactions**. This also means that at the moment of transaction confirmation, the "security per transaction" would be halved, since only half the time has passed. After two blocks, the transaction would have security equivalent to a single block's confirmation on the unaltered chain.

Related: this is why blockchains which claim to have 'faster finality than Bitcoin' are a farce: the Bitcoin network consumes more energy per time (and thus provides more security) than any other network. The number of blocks that have passed is meaningless as far as security is concerned, what really matters is **the cost of rewriting those blocks**. For example, rewriting 100 blocks of a low hashpower coin might be cheaper than 1 block on the Bitcoin network. So in this way the Bitcoin network's single block provides more security, more quickly.

**So, why don't we do this, and lower the block interval?**

With respect to the question you quoted, it is worth noting that halving the block time would be equivalent to doubling the block size, in terms of the computational, bandwidth, and storage (ignoring pruning) resources required. Doing so would put more strain on network nodes, as it would require more resources to run one. With an increase in required resources, we should expect that less nodes will exist, and that negatively impacts the degree of network decentralization. Having nodes remain as decentralized as possible is important for the bitcoin network, as the value proposition of the network largely depends on it.

As username_2 mentioned in the comments, another negative effect is increased block orphan rates. I'll copy the text from the link in username_2's comment, which was written by username_2, and is a great description of the issues with decreasing the block interval:

> There are two issues that get worsened by this:
>
> 1. The shorter the inter-block interval is, the more advantage you're giving to an attacker. You see, blocks take time to propagate through the network to all miners, at the very least limited by the speed of light. Due to PoW resulting in a Poisson process for block generation time, there is a nontrivial chance for two blocks being found within a very short time of one another. If that period of time is so short that the first block has not had time to reach the miner producing the second, the second block will be a waste of power (both in terms of income and in security to the network). This wouldn't be a problem if it affected every miner equally, but it doesn't. More well-connected (geographically centralized) miners suffer less, as they're relatively closer to everyone. But most importantly, a 51% attacker does not suffer from this at all, as he only builds on top of his own blocks, and thus never needs to wait for propagation. For some numbers, at block interval 600s there is about a 0.83% chance that two blocks are produced within 5s of each other. With block interval 60s that goes up to around 8.0%. If block propagation takes 5s, that means giving a direct 8% cost reduction to a mining collusion attack.
> 2. Overall resource consumption for full nodes. If you have 10x more blocks of the same size, full nodes will need 10x more resources to verify history and maintain in sync (bandwidth, CPU, I/O, storage, ...).

In my opinion, considering these negative effects, the linear gains in scale achieved would not be worth the work and risks involved in pushing out a rule change like this.

> **Comments:**
> **username_2**: This seems incorrect to me. Every transaction gets all the security corresponding to all blocks built on top of it. Increasing the rate of blocks would still result in the same security per transaction per time unit if the total hashrate is not changed. The other reasons for not doing this you point out are correct, but there is another one: increasing orphan rates (I've written about this recently here: https://www.reddit.com/r/Bitcoin/comments/cbfyue/why_10_minute_intervals/etff0pi/?context=3).  
> **username_1**: @username_2 hmm I think the distinction is that you would have the same amount of security, but now after two blocks, instead of just one. At the moment of transaction confirmation, you would have half the security. My answer wasn't very clear in this regard, I'll work on an edit of it, thanks for pointing that out.  
> **username_0**: Thank you for your answer!  So I have another question, with the proof of stake, the block security does not require heavy computation, does that mean it is less secure than proof of work ?  
> **username_3**: While true that if you halve the difficulty, blocks will be twice as easy to find at half the security, that doesn't answer the question *why wouldn't we do this*?  
> **username_1**: @username_0 that should be posted as a new question, not just a comment :)  
> **username_1**: @username_3 true, I edited it to be more clear that the last bit includes the reasoning of why/why not.  
> **username_4**: This puts a lot of weight on the value of a confirmation, which doesn't seem that important as username_2 already explained above. This answer could be improved by elaborating the downsides of faster blocks.  
> **username_1**: @username_2 I've edited this answer again to hopefully be more helpful, and as part of that I've copied the text you linked to above into it. If you'd rather post that text as an answer yourself, I'm happy to revert my edit.  

---

### Answer by username_3 on 2019-07-16. Score: 1

Litecoin, Dash, and other bitcoin forks have taken this approach. There are a few issues which are not immediately obvious.

The big one though:

**Increased Data storage and transmission costs**

Although 1mb per ten minutes sounds very low, increasing that amount to 2-4 mb will prevent some very slow internet connections from being able to ever sync.

Today, the slowest internet available worldwide seems to be about 256kbps

If you wanted to, you could run a full bitcoin node on this wifi, though the initial sync would take a while. at 256kbps, or about 900mb/hour, syncing the blockchain would take about 250 hours, or 10 days.
This is the key to bitcoin's relatively small block sizes: **Even with this slow connection, it only takes 10 days to fully
validate every transaction that has taken place in the last 10 years**

Perhaps more importantly, a full day of 1mb blocks would take 576 seconds, or just under 10 minutes. This means that, daily, a person in a remote area with no internet connection, could come into town, sync the blockchain on very slow internet, participate in the local economy, all the while never needing to rely on any 3rd party to hold or verify their money. This allows the bitcoin blockchain to achieve a level of decentralization that many other blockchains lack.

Keep in mind that doubling the block size of the blockchain will not just double the time it takes to sync the blockchain, but rather more than double it, *because the blockchain will be growing faster while you are syncing*.

**Increased orphan rate**

Miners will have their blocks orphaned more often. This creates the incentive to join larger mining pools, since the larger a mining pool, the more miners will start mining on your block, rather than mining on a competing block at the same block height. This is much worse with *larger* blocks, rather than *more frequent* blocks, but either way, there is a point at which this increased benefit is not a trivial difference. Once the network matures, if there is a significant advantage, we would expect the market to eventually tend toward that "solution", which would increase centralization

**Decreased scarcity of on-chain data storage**

The fact that there is only 1mb available in bitcoin per 10 minutes creates what is essentially a bidding war on that 1mb. Although this is bad for the *medium of exchange* property of bitcoin in the short run, it may prove to be a very important characteristic in the *store of value* property in the far distant future as block rewards go to zero, as we now extra value from rarity: storing data on Bitcoin.

**Tradition**

The above were only theoretical, that is, assuming this idea was adopted, what system would result. In practice, the network would *surely* fork if such an event took place. If the past is any indication of the future, such a huge change would result in a (minority) fork, leaving bitcoin at 1mb and the fork at the changed size. Another part of what gives bitcoin its *store of value* property is that the underlying protocol is extremely change-resistant, and it is likely that it is "antifragile", that is, it is becoming more resistant to being changed/broken as attempts to change it have failed (see segwit2x, and numerous forks).

> **Comments:**
> **username_0**: For "Decreased scarcity of on-chain data storage" point, this means that bitcoin is less and less interesting for daily transactions (and therefore of a relatively small amount) as it grows?  It will therefore be used exclusively for large amount transactions or when fees do not matter to the person making the transaction, is it right ?  
> **username_3**: Likely that eventually, bitcoin will be used for mostly for opening/closing of lightning channels (or some other implementation that requires only a couple non-reversible transactions to enable unlimited nearly free transactions)  

---

### Answer by username_5 on 2021-05-19. Score: 0

The following seems right to me, but I haven't given it a ton of thought, so will be glad to be corrected:

There is free entry into mining; therefore (except for those with extraordinary skills or access to extraordinary resources) miners cannot (in expectation) earn economic profits (defined as profits in excess of what they could have earned elsewhere with the same inputs of capital and labor). (If economic profits become positive or negative, then miners enter or leave until profits are driven back to zero.) Therefore, to a good approximation, no change to the system can change the rewards earned by a typical miner.

Halving the block time (without changing the block reward) would have, to a first rough approximation, the following effects:

1. The total earnings of all miners from block rewards would double.
2. The earnings of the average miner would stay fixed.
3. Therefore the number of miners would double.

Presumably more miners means more security (at least over some range, as I'm quite sure that a system with one miner would be quite insecure) so at least part of what was lost in security from reducing the block difficulty would be gained back from the increased number of miners.

To make this more realistic, we should add a fourth effect:

4. The supply of transactions would double; demand would presumably be largely unaffected (unless the implied changes in security affected the number of people willing to use Bitcoin as a payment system). This means that point 1) above should be modified to say that total rewards to miners would **less** than double, and might even fall. You can then adjust points 2) and 3) accordingly.


---

