After reading Why is increasing block size in the Bitcoin network considered to decrease security?, 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 ?


3 Answers 3


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, 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 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:

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.

  • 3
    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: reddit.com/r/Bitcoin/comments/cbfyue/why_10_minute_intervals/…). Commented Jul 16, 2019 at 1:37
  • 1
    @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
    Commented Jul 16, 2019 at 1:41
  • 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 ? Commented Jul 16, 2019 at 1:59
  • 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? Commented Jul 16, 2019 at 2:02
  • @ThibaultSantonja that should be posted as a new question, not just a comment :)
    – chytrik
    Commented Jul 16, 2019 at 2:13

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.


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

  • 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 ? Commented Jul 16, 2019 at 2:08
  • 1
    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) Commented Jul 16, 2019 at 13:04

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:

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

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.