<p>In principle, yes, what you suggest could work, even in your "extreme case".  But in practice, if it took very little work to create a valid block, then there would be trillions of blocks created per second (by both good and bad actors), and it would become impossible simply to store or transfer that much data, not to mention trying to sort them into a chain.  You'd also have a lot more people stepping on each other's toes by creating multiple blocks naming the same parent, leading to many forks in the blockchain that would take a while to be resolved.</p>

<p>But there would be nothing wrong with altering the difficulty schedule so that blocks get created at a somewhat higher average rate (note that the Bitcoin standard is 0.1 blocks per minute, i.e. one block every 10 minutes, not 10 blocks per minute).  The choice of 0.1 blocks per minute was arbitrary and a different rate would work fine.  Litecoin, for instance, uses a rate of 0.5 blocks per minute.</p>

<p>It is helpful not to have it too fast, so that most of the time there is at least a few seconds between blocks, and the block has a chance to propagate through the network before a new one is found.  Otherwise you get more forks, as mentioned above.</p>

<p>Also note that a common misconception is that reducing the block time would speed up confirmation of transactions.  The security of a transaction against double-spend is related to the <em>total work</em> done on top of it in the blockchain, not just the number of blocks.  So if Bitcoin increased the block rate to 0.5 per minute like Litecoin, that would mean each block demonstrates only 1/5 as much work as before.  To get equivalent security to the current standard of 6 confirmations, you would now have to wait for 30 confirmations, and it would still take 60 minutes. </p>

<p>So while there wouldn't be any particular problem with increasing the block rate (other than those inherent in changing the protocol through a hard fork), there wouldn't be any dramatic benefits either.</p>

CC BY-SA 4.0
2018-11-07T18:11:48.307Z
all right this sounds like varying pow doesnt open a security issue and pow is for usability, efficiency, etc. reasons;
Cyker
CC BY-SA 4.0
2018-11-08T15:02:38.163Z
Good answer overall, but the "common misconception" is not a misconception.  Imagine 2 chains, A targeted for 1-minute blocks and B for 10-minute blocks.  After 10 minutes, A has about 10 blocks and B has about 1 block.  If an attacker wanted to keep private a longer chain and publish it after 10 minutes they would need approximately 11 private blocks for A and 2 private blocks for B.  Even if they were able to produce blocks at half the rate of the rest of the network the chances of that would be about 1 in 2^11 on A and 1 in 2^2 on B, so A allows shorter confirmations for similar confidence.
Briguy37
CC BY-SA 4.0
2018-11-07T14:51:43.283Z
2018-11-07T14:51:43.283Z
Nate Eldredge
<p>i am reading the proof-of-work (aka: pow, target threshold, difficulty, etc.); my understanding is that pow adds a requirement to validate block headers, so that both benign and malign nodes need a reasonable amount of time to create a valid block; but i dont see how this rate limit relates to <strong>safety</strong>; even if there is no pow, so that every block is valid, as long as benign nodes have the majority of computing power, couldnt they still guarantee the main chain is correctly formed?</p>

<p>for example, assuming benign nodes are the majority:</p>

<ul>
<li><p>with pow, malign nodes generate new blocks at <code>m</code> blks/min, while benign nodes at <code>b</code> blks/min, and <code>b &gt; m</code>;</p></li>
<li><p>without pow, malign nodes generate at <code>100000m</code> blks/min, while benign nodes at <code>100000b</code> blks/min; we still have <code>100000b &gt; 100000m</code> (even though the public ledger now grows much larger);</p></li>
</ul>

<p>above is an extreme example, but you could imagine adjusting pow step by step, from current 10 blks/min to 20 blks/min, to 30blks/min, etc. does the bitcoin protocol become less secure from the adjustments?</p>

CC BY-SA 4.0
2018-11-07T12:46:51.583Z
PoW and validation are completely separate things. You can PoW your cat pictures and that would be fine. Full nodes will do 100% of the validation for themselves and only pick valid Bitcoin blocks thus throwing out your cat pictures.
Jannes
<difficulty><proof-of-work>
is the proof-of-work for safety or efficiency?
Cyker
# is the proof-of-work for safety or efficiency?

(Asked by: username_0 on 2018-11-07)

i am reading the proof-of-work (aka: pow, target threshold, difficulty, etc.); my understanding is that pow adds a requirement to validate block headers, so that both benign and malign nodes need a reasonable amount of time to create a valid block; but i dont see how this rate limit relates to **safety**; even if there is no pow, so that every block is valid, as long as benign nodes have the majority of computing power, couldnt they still guarantee the main chain is correctly formed?

for example, assuming benign nodes are the majority:

* with pow, malign nodes generate new blocks at `m` blks/min, while benign nodes at `b` blks/min, and `b > m`;
* without pow, malign nodes generate at `100000m` blks/min, while benign nodes at `100000b` blks/min; we still have `100000b > 100000m` (even though the public ledger now grows much larger);

above is an extreme example, but you could imagine adjusting pow step by step, from current 10 blks/min to 20 blks/min, to 30blks/min, etc. does the bitcoin protocol become less secure from the adjustments?

**Tags:** difficulty, proof-of-work

> **Comments:**
> **username_1**: PoW and validation are completely separate things. You can PoW your cat pictures and that would be fine. Full nodes will do 100% of the validation for themselves and only pick valid Bitcoin blocks thus throwing out your cat pictures.  

---

## 1 answers

### Answer by username_2 on 2018-11-07. Score: 2 | Accepted answer

In principle, yes, what you suggest could work, even in your "extreme case". But in practice, if it took very little work to create a valid block, then there would be trillions of blocks created per second (by both good and bad actors), and it would become impossible simply to store or transfer that much data, not to mention trying to sort them into a chain. You'd also have a lot more people stepping on each other's toes by creating multiple blocks naming the same parent, leading to many forks in the blockchain that would take a while to be resolved.

But there would be nothing wrong with altering the difficulty schedule so that blocks get created at a somewhat higher average rate (note that the Bitcoin standard is 0.1 blocks per minute, i.e. one block every 10 minutes, not 10 blocks per minute). The choice of 0.1 blocks per minute was arbitrary and a different rate would work fine. Litecoin, for instance, uses a rate of 0.5 blocks per minute.

It is helpful not to have it too fast, so that most of the time there is at least a few seconds between blocks, and the block has a chance to propagate through the network before a new one is found. Otherwise you get more forks, as mentioned above.

Also note that a common misconception is that reducing the block time would speed up confirmation of transactions. The security of a transaction against double-spend is related to the *total work* done on top of it in the blockchain, not just the number of blocks. So if Bitcoin increased the block rate to 0.5 per minute like Litecoin, that would mean each block demonstrates only 1/5 as much work as before. To get equivalent security to the current standard of 6 confirmations, you would now have to wait for 30 confirmations, and it would still take 60 minutes.

So while there wouldn't be any particular problem with increasing the block rate (other than those inherent in changing the protocol through a hard fork), there wouldn't be any dramatic benefits either.

> **Comments:**
> **username_0**: all right this sounds like varying pow doesnt open a security issue and pow is for usability, efficiency, etc. reasons;  
> **username_3**: Good answer overall, but the "common misconception" is not a misconception.  Imagine 2 chains, A targeted for 1-minute blocks and B for 10-minute blocks.  After 10 minutes, A has about 10 blocks and B has about 1 block.  If an attacker wanted to keep private a longer chain and publish it after 10 minutes they would need approximately 11 private blocks for A and 2 private blocks for B.  Even if they were able to produce blocks at half the rate of the rest of the network the chances of that would be about 1 in 2^11 on A and 1 in 2^2 on B, so A allows shorter confirmations for similar confidence.  

---

