<p>You are correct that changing either block size or block frequency would successfully allow more transactions to be confirmed per unit time.</p>

<p>However, changing the block frequency means changing the difficulty adjustment formula.  This requires a hard fork just like changing the maximum block size would.  In either case, network nodes that do not adopt the new rules will consider the new blocks as invalid, and if not everyone agrees to adopt the new rules, the currency will effectively split in two.  </p>

<p>If you are going to have a hard fork anyway, changing block size has somewhat fewer technical pitfalls than changing the difficulty adjustment formula.  For instance, increasing the frequency will lead to a higher rate of orphaned blocks, where two miners each find valid blocks almost simultaneously and neither builds on the other.  </p>

<p>Also, increasing the block frequency means that "confirmations" would not mean the same as they used to.  We think of "6 confirmations" as a benchmark for a transaction that would be extremely hard to reverse, but what that really means is "60 minutes of mining time".  If you adjusted the frequency so that the average block time was one minute, now everybody would have to use "60 confirmations" as the benchmark for equivalent security, and all software that counted confirmations would have to be updated.   (For instance, think of exchanges that don't want to credit a user's account until their deposits are sufficiently confirmed).  Any software that isn't updated will lose 90% of its security against double spend attacks.  So this would be more disruptive than changing block size.</p>

<p>Here is an example.  The current Bitcoin difficulty is about 6.8e11.  This means that an average of 6.8e11 * 2^32 = 2.9e21 hash operations are needed to mine one block.  Say you have a transaction in block number 400000 in the main chain, and it has 6 confirmations, so we are now at block height 400005.  In order to double-spend, someone would have to create a conflicting transaction in a conflicting block whose parent was block 399999, so the new block would also be at height 400000.  Then they have to mine 5 more blocks on top of their new block to get their new chain to be at least as long as the existing one, and hope that future miners will mine on their new chain instead of the old one.  So this requires mining 6 blocks = 6 * 2.9e21 = 1.7e22 hash operations.</p>

<p>Now imagine you want the average block time to be 1 minute instead, so you cut the difficulty to 6.8e10.  It now takes only 2.9e20 hashes to mine one block.  So a transaction with 6 confirmations under this new scheme only takes 1.7e21 hashes to reverse.  If you want the same security as before, i.e. 1.7e22 hashes needed to reverse, you have to wait for 60 confirmations.</p>

CC BY-SA 3.0
2017-06-28T17:39:10.977Z
Thanks, I understand your points about hard fork and orphaned blocks but the last one I'm not quite sure of. Why would the security be 60 minutes and not six hashes?
Eliahu Horwitz
CC BY-SA 3.0
2017-06-28T17:49:35.093Z
@EliahuHorwitz: I added an example which may help.
Nate Eldredge
CC BY-SA 3.0
2017-06-28T17:53:17.463Z
Thanks! Apart from segwit and sharding are there any other scaling suggestions? Is the tangle network implemented at IOTA any good?
Eliahu Horwitz
CC BY-SA 3.0
2017-06-28T17:54:17.550Z
Ask as a new question, please (but search for existing questions first).
Nate Eldredge
CC BY-SA 3.0
2017-06-28T17:27:53.943Z
2017-06-28T17:49:25.580Z
2017-06-28T17:49:25.580Z
Nate Eldredge
<p>Somewhat new to bitcoin, trying to understand the tech...
For my understanding all the transactions go into a block, every 10 minutes the block is mined and all transactions in it are confirmed. With every block confirmed (meaning every 10 minutes) the older blocks get harder to hack. The blockchain algorithm knows to adjust its own difficulty so that every 10 minutes a block is mined. Is the above correct? </p>

<p>If it is then how come the scaling problem is block size and not block frequency? If the network can adjust it self to the compute power why not resolve a block every minute while decreasing the amount of BTC to be produced with every block and keeping block size at 1MB? </p>

<p>Thanks</p>

<bitcoin-core><segregated-witness><scalability><block-size-increase>
Blocks, scaling and segwit question
Eliahu Horwitz
# Blocks, scaling and segwit question

(Asked by: username_0 on 2017-06-28)

Somewhat new to bitcoin, trying to understand the tech...
For my understanding all the transactions go into a block, every 10 minutes the block is mined and all transactions in it are confirmed. With every block confirmed (meaning every 10 minutes) the older blocks get harder to hack. The blockchain algorithm knows to adjust its own difficulty so that every 10 minutes a block is mined. Is the above correct?

If it is then how come the scaling problem is block size and not block frequency? If the network can adjust it self to the compute power why not resolve a block every minute while decreasing the amount of BTC to be produced with every block and keeping block size at 1MB?

Thanks

**Tags:** bitcoin-core, segregated-witness, scalability, block-size-increase


---

## 1 answers

### Answer by username_1 on 2017-06-28. Score: 2

You are correct that changing either block size or block frequency would successfully allow more transactions to be confirmed per unit time.

However, changing the block frequency means changing the difficulty adjustment formula. This requires a hard fork just like changing the maximum block size would. In either case, network nodes that do not adopt the new rules will consider the new blocks as invalid, and if not everyone agrees to adopt the new rules, the currency will effectively split in two.

If you are going to have a hard fork anyway, changing block size has somewhat fewer technical pitfalls than changing the difficulty adjustment formula. For instance, increasing the frequency will lead to a higher rate of orphaned blocks, where two miners each find valid blocks almost simultaneously and neither builds on the other.

Also, increasing the block frequency means that "confirmations" would not mean the same as they used to. We think of "6 confirmations" as a benchmark for a transaction that would be extremely hard to reverse, but what that really means is "60 minutes of mining time". If you adjusted the frequency so that the average block time was one minute, now everybody would have to use "60 confirmations" as the benchmark for equivalent security, and all software that counted confirmations would have to be updated. (For instance, think of exchanges that don't want to credit a user's account until their deposits are sufficiently confirmed). Any software that isn't updated will lose 90% of its security against double spend attacks. So this would be more disruptive than changing block size.

Here is an example. The current Bitcoin difficulty is about 6.8e11. This means that an average of 6.8e11 \* 2^32 = 2.9e21 hash operations are needed to mine one block. Say you have a transaction in block number 400000 in the main chain, and it has 6 confirmations, so we are now at block height 400005. In order to double-spend, someone would have to create a conflicting transaction in a conflicting block whose parent was block 399999, so the new block would also be at height 400000. Then they have to mine 5 more blocks on top of their new block to get their new chain to be at least as long as the existing one, and hope that future miners will mine on their new chain instead of the old one. So this requires mining 6 blocks = 6 \* 2.9e21 = 1.7e22 hash operations.

Now imagine you want the average block time to be 1 minute instead, so you cut the difficulty to 6.8e10. It now takes only 2.9e20 hashes to mine one block. So a transaction with 6 confirmations under this new scheme only takes 1.7e21 hashes to reverse. If you want the same security as before, i.e. 1.7e22 hashes needed to reverse, you have to wait for 60 confirmations.

> **Comments:**
> **username_0**: Thanks, I understand your points about hard fork and orphaned blocks but the last one I'm not quite sure of. Why would the security be 60 minutes and not six hashes?  
> **username_1**: @username_0: I added an example which may help.  
> **username_0**: Thanks! Apart from segwit and sharding are there any other scaling suggestions? Is the tangle network implemented at IOTA any good?  
> **username_1**: Ask as a new question, please (but search for existing questions first).  

---

