10 min (on average) for block time? is it a rule?

[sasageyo]

why not 9 min or 11? why it has to be 10?

[1714152985]

1714152985

[1714152985]

1714152985

[1714152985]

1714152985

[TryNinja]

TLDR: "Decreasing the block time would increase the number of orphan blocks."

Decreasing block time decreases the amount of time a newly made block has to fully propagate through the network.

Lets say you have 1 node which mines a block and sends it out into the network. 5 minutes later, the last node on the network receives the block, and starts working on the next one. If you decrease the block time to - lets say - 2 minutes, A node would send out a block and because it takes 5 minutes for the block to make it all the way through the network, a node on the other side of the network may also mine one and send it out before even hearing about the one that has already been mined. Now you have 2 competing blocks in the network. Most of the time, the network will instantly reject the block - an orphan block, but sometimes the blocks we're mined close enough together you can get a split in nodes, one following one block and the other following the other block - This is a fork.

In short this is a means of network security, and 10 minutes was selected as a happy medium between low orphans/forks and a fast network.

Source: https://www.reddit.com/r/Bitcoin/comments/7cblg8/why_the_standard_time_between_blocks_is_10_min/dpomrmf/?context=3

[bob123]

10 minutes have been chosen by satoshi. It also could have been 9 or 11. That wouldn't make much difference.
The reason for a blocktime greater than 1 or 2 minutes has been nicely quoted by TryNinja.

The blocktime also is NOT a rule. The difficulty adjusts each 2016 blocks (~ 2 weeks) to meet the target of 1 block per 10 minutes.
It is meaned as an average. Not as a strict rule.

Finding blocks is based on luck. This can take any time between a second and a few hours or days. But the difficulty adjusts itself to meet an average of 10 minutes.

[odolvlobo]

The goal was to minimize both the time between blocks and the orphan rate. 10 minutes was a convenient time that accomplished that goal well enough.

The 10 minute average is accomplished by adjusting the difficulty every 2016 block.

[aliashraf]

TLDR: "Decreasing the block time would increase the number of orphan blocks."

Decreasing block time decreases the amount of time a newly made block has to fully propagate through the network.

Lets say you have 1 node which mines a block and sends it out into the network. 5 minutes later, the last node on the network receives the block, and starts working on the next one. If you decrease the block time to - lets say - 2 minutes, A node would send out a block and because it takes 5 minutes for the block to make it all the way through the network, a node on the other side of the network may also mine one and send it out before even hearing about the one that has already been mined. Now you have 2 competing blocks in the network. Most of the time, the network will instantly reject the block - an orphan block, but sometimes the blocks we're mined close enough together you can get a split in nodes, one following one block and the other following the other block - This is a fork.

In short this is a means of network security, and 10 minutes was selected as a happy medium between low orphans/forks and a fast network.

Source: https://www.reddit.com/r/Bitcoin/comments/7cblg8/why_the_standard_time_between_blocks_is_10_min/dpomrmf/?context=3

It is the most naive analysis of such a critical subject, ever .

To have a solid understanding of block time issue one should perform a heavier analysis of the network considering  both  the actual propagation delay and its improvement opportunities.

It is sad. When we read something about how bitcoin is perfect and no further improvements is needed, we blindly accept it without any further research.

I have read^* a comprehensive analysis of this issue 2-3 years ago, when BIP 151 and other network layer enhancements were not around and authors have thoroughly proved that with very minor enhancements (like adding compact block transmission which is already done) we would have  no security issue with reducing block time substantially.

I strongly believe with even further improvements in bitcoin networking services we can reach to a rough 1 minute block time without any security draw back.

At the time of this writing we have less than %0.02 orphan blocks rate (only 11 blocks in last 12 months).

It is TOO low: an orphan block rate up to 1% is still to be considered secure! It proves a point: We are keeping bitcoin Too secure!

It is always true, set block time to 1 hour and you will get better security, but it is not what an engineer or a prominent developer do, you have always to trade-off and check what you are gaining for the utilities you are losing. In the block time case we can improve it right now without any considerable increase in orphan rate.

Note
     ^*: I'll provide the link asap.

EDIT:
This is the link to the article: On the Security and Performance of Proof of Work Blockchains  (pdf)

[butka]

At the time of this writing we have less than %0.02 orphan blocks rate (only 11 blocks in last 12 months).

Very interesting. I didn't know the rate was so low. I remember reading something about preventing orphaned blocks being one of the main reasons for 10-minute block time.

What about network bandwidth? Wouldn't we need higher bandwidth if there was 1-minute block time?

[aliashraf]

At the time of this writing we have less than %0.02 orphan blocks rate (only 11 blocks in last 12 months).

Very interesting. I didn't know the rate was so low. I remember reading something about preventing orphaned blocks being one of the main reasons for 10-minute block time.

What about network bandwidth? Wouldn't we need higher bandwidth if there was 1-minute block time?

No, we don't. We would need a minor support in networking layer to keep mining full nodes in closer distances and few more apis and right now we have FIBRE tremendously effective in reducing propagation delay. I could say without such improvements yet we are ready to jump very close to 1 minute block time 99% safe.

[aliashraf]

I have read^* a comprehensive analysis of this issue 2-3 years ago, when BIP 151 and other network layer enhancements were not around and authors have thoroughly proved that with very minor enhancements (like adding compact block transmission which is already done) we would have  no security issue with reducing block time substantially.

I read the paper a bit and i can't disagree, but there should be up-to-date research about this case since there's few protocol changes/client optimization, especially because people stuck with shorter block time is bad thing.
P.S i might have different opinion after read the paper thoroughly

I bet you would

I strongly believe with even further improvements in bitcoin networking services we can reach to a rough 1 minute block time without any security draw back.

As i mentioned on other thread, that would mess with coin production rate (even though it can be solved easily), timelock script which rely on block height and any 2nd layer which use it.

It would be a trivial job to tackle those issues, timeLock script codes are to be treated properly and would be obsolete and replaced with new opcode and block reward would be reduced respectively.

Besides, that would mean we might need more than 6 confirmation to reach same security with current block time.

I doubt it. The same hashpower is actively defending against any adversary. Nothing would change in terms of confirmations needed to secure a transaction, imo.

At the time of this writing we have less than %0.02 orphan blocks rate (only 11 blocks in last 12 months).

It is TOO low: an orphan block rate up to 1% is still to be considered secure! It proves a point: We are keeping bitcoin Too secure!

It is always true, set block time to 1 hour and you will get better security, but it is not what an engineer or a prominent developer do, you have always to trade-off and check what you are gaining for the utilities you are losing. In the block time case we can improve it right now without any considerable increase in orphan rate.

And the difficult problem is each people have different measure of acceptable orphan rate.

Don't agree. It is not an ideological issue. I have made some assessments regarding this issue and my results show that with a stale(orphan) block rate of less than 1% you need practically the same adversarial hashpower to commit a double spend attack on bitcoin (preserving the same 6 confirmations threshold de-facto standard) that you need with current %0.02 rate and I suggest reducing blocktime to 1 minute won't increase orphan rate even close to 0.5%.

It is very important to remember that we have now bip 151  active along with compact blocks, unsolicited block push , ... which are huge improvements that made it possible to have orphan rate dropped  form 0.41% (2016)  to current 0.02% in 2018.
The irony being that despite such an improvement apparently we have no plan to change anything. What a waste!

[gmaxwell]

that made it possible to have orphan rate dropped  form 0.41% (2016)  to current 0.02% in 2018.

We actually have little idea what the orphan rate is now: HB mode compact blocks radically reduced the _propagation_ of orphans, such that they're not well propagated anymore.  Whatever it actually is, I know it's higher than 0.02% because just collecting from a half dozen nodes I see more than 4 times that many in the last 38k blocks, but on any single node you only see a fraction of that.

Also, blockchain.info's orphaning figures have historically been rubbish, unrelated to recent behavior changes.

unsolicited block push

Sending whole blocks unsolicited severely hurts block propagation. We'd probably get a measurable improvement if nodes started automatically banning peers that violate the protocol that way. Fortunately it's not very common.

[aliashraf]

that made it possible to have orphan rate dropped  form 0.41% (2016)  to current 0.02% in 2018.

We actually have little idea what the orphan rate is now: HB mode compact blocks radically reduced the _propagation_ of orphans, such that they're not well propagated anymore.  Whatever it actually is, I know it's higher than 0.02% because just collecting from a half dozen nodes I see more than 4 times that many in the last 38k blocks, but on any single node you only see a fraction of that.

I think the actual rate is what we get from a single point in the network. You get your stat from 6 different nodes and you see 4 times more stall blocks, it is so natural.

The stalls alone are not the problem, the granolity of the nodes and the duration they are kept in shadow is. When a node avoids propagating a stall it is a good sign of it not being held in darkness.

Anyway, four times 0.02 is 0.08 and we have a lot of space to maneuver. 

unsolicited block push

Sending whole blocks unsolicited severely hurts block propagation. We'd probably get a measurable improvement if nodes started automatically banning peers that violate the protocol that way. Fortunately it's not very common.

What about unsolicited block header push?

[gmaxwell]

I think the actual rate is what we get from a single point in the network.

The rate of orphan blocks is the number of blocks created in some window which are not in the chain divided by the total number of blocks created. More modern relay has less node specific delays, and so as a result split propagation is now much more strongly geographically limited. A single node cannot be everywhere in the world at once... The harm that orphans cause the network in terms of centralization pressure is related to how many are created, not if any particular node's peers offered to give it to them.  Consider: if you turn your node off for a day it won't see any orphans created during that day at all... are all orphaning problems gone?  Obviously not.

In our case, nodes now see far fewer of the orphans that exist because they now forward along blocks to consenting peers before they've validated them, and as a result get to the point where they're unwilling to propagate an alternative much faster. This speedup lowered the actual orphaning rate but it also largely blinded nodes to orphans.

[aliashraf]

I think the actual rate is what we get from a single point in the network.

The rate of orphan blocks is the number of blocks created in some window which are not in the chain divided by the total number of blocks created. More modern relay has less node specific delays, and so as a result split propagation is now much more strongly geographically limited. A single node cannot be everywhere in the world at once...

I maintain that it should be experienced from a single point:

An adversary is just a node, a point, for this node it is necessary to experience such a stall rate to take advantage of it for committing any attack.  Modern physics has shown it thoroughly and comprehensively: Relativity and Quantum theories share the same idea of measurement: you have to observe/experience physical objects with your coordinate system. You interact with the universe reliably based on your measurements and the universe interacts with you accordingly.

There is no absolute index in bitcoin network, both loyal and unfaithful nodes are just observers they experience a hashrate and a stall rate and they affect the same network they experience, there is no absolute network, one should connect to it to do anything good or bad to it.

My 0.02% index is the rate of stalls the way blockchain.info has experienced it in last 12 months. I appreciate your survey but I think it needs a little tweak:
Instead of cardinality of the union of the sets of orphans logged by each node, it is better to check the maximum cardinality of those sets and  their mean. The latter being the most important index, imo.

EDIT:
I understand it is not common sense and we are used to analyse the blockchain like gods using absolute coordinate system and scales but it is simply wrong.
Security is not about network defending against hypothetical misbehaviours but practical threats that should be carried on through an active interaction with the network, from a relative position.