<p>I found that part of the wiki frustrating too, and I just edited it. I'd appreciate corrections. Here's what I wrote:</p>

<blockquote>
  <p>Ten minutes was specifically chosen by Satoshi as a tradeoff between first confirmation time and the amount of work wasted due to chain splits. After a block is mined, it takes time for other miners to find out about it, and until then they are actually competing against the new block instead of adding to it. If someone mines another new block based on the old block chain, the network can only accept one of the two, and all the work that went into the other block gets wasted. For example, if it takes miners 1 minute on average to learn about new blocks, and new blocks come every 10 minutes, then the overall network is wasting about 10% of its work. Lengthening the time between blocks reduces this waste.</p>
  
  <p>As a thought experiment, what if the Bitcoin network grew to include Mars? From the farthest points in their orbits, it takes about 20 minutes for a signal to travel from Earth to Mars. With only 10 minutes between new blocks, miners on Mars would always be 2 blocks behind the miners on Earth. It would be almost impossible for them to contribute to the block chain. If we wanted collaborate with those kinds of delays, we would need at least a few hours between new blocks.</p>
</blockquote>

CC BY-SA 3.0
2015-06-25T22:43:39.853Z
Also see: http://bitcoin.stackexchange.com/questions/30001/how-do-you-create-a-planet-specific-cryptocurrency-that-will-ignore-longer-block
Murch
CC BY-SA 3.0
2013-06-27T11:18:11.420Z
2013-06-27T11:18:11.420Z
Jack O'Connor
<p>As Bitcoins are the first cryptocurrency to use block generation and so forth, one can assume 10 minutes was a arbitrarily chosen. Any value that was big enough to propagate the new block through the network before another miner would be probable to generate a new block would be good. On the other end blocks shouldn't be too scarce, as it would take too long to get confirmations. <a href="https://bitcoin.stackexchange.com/questions/1170/why-is-6-the-number-of-confirms-that-is-considered-secure">An hour of computation</a> is considered safe from being tampered with, so dividing that time into neat parts can give you 10 minutes.</p>

<p>There probably isn't any discussion available on this topic, as the first Bitcoin version was created by Satoshi alone, so until he reveals his true identity or comes back to the community, the exact reasons can't be figured out for sure.</p>

CC BY-SA 3.0
2011-11-03T14:47:12.383Z
The analysis in Satoshi's paper doesn't at all relate to the amount of time one should wait - that depends solely on the practicality of maintaining a high hashrate for a long time. He discussed the amount of blocks to wait - he showed, for example, that if the recipient waits for 6 blocks and the attacker has 10% of the network's hashrate, a double-spend attempt only has <0.025% chance to succeed. At 1 minute per block this is 6 minutes, etc.
Meni Rosenfeld
CC BY-SA 3.0
2011-11-03T12:45:20.860Z
2011-11-03T12:45:20.860Z
2017-04-13T12:47:33.283Z
ThePiachu
<p>Block time was determined by Satoshi Nakamoto as a tradeoff between 2 factors</p>
<p>1.Network latency:<br />
After a block is mined, it takes some time for other miners to find out about that node and during that time, actually other miners are still competing (which means mining) against that block instead of adding that block to the chain. This leads to the waste of mining resources which is caused because several miners are still mining their blocks but the network can add only one. Plus this is a fact that it will take some time for any new mined block to show up to all the nodes since network lag is a thing.</p>
<p>2.Confirmation time:<br />
We can be sure about the confirmation of a block being added to the chain/network only after some blocks are added to that chain. And to make confirmation more reliable about 5-6 blocks are needed to be added to the chain after our block. This will surely take some time. But we need to make this process fast.</p>
<p>Now, the network lag factor needs the block time to be longer whereas the confirmation time factor needs it to be shorter. Hence a trade off was chosen which is 10 minutes. This time length was surely chosen after some calculations. But theoretical reason behind the block time is same as described in this answer.</p>

CC BY-SA 4.0
2021-05-27T09:19:42.583Z
2021-05-28T14:21:42.933Z
2021-05-28T14:21:42.933Z
Twinkle Kumari
<p>AFAICS, the only possible benefit to the longer block time is the reduction of bandwidth overhead due to less probability of block chain splits.</p>

<p>I even doubt that tradeoff, because if the transaction data is the bulk then there is the counter-balancing effect that shorter block times mean less data to transmit.</p>

<p>I am highly skeptical that there must be more work wasted with shorter block time, if the difficulty is calibrated w.r.t. the time to arrive at a consensus. Mathematically the miners earn a percentage of the newly created blocks proportioned roughly by their percentage of the system hash power, regardless the relative split in proportion of their luck between work difficulty and (the random) orphaned chains.</p>

<p>Unless there is a proof, I doubt the claim that shorter block times create longer times to arrive at consensus (i.e. re-org splits), because for example if there are 4 times more splits with 1/4 the block time, there are roughly 7 more iterations to arrive at consensus within the same duration.</p>

<p>G̶i̶v̶e̶n̶ ̶t̶h̶a̶t̶ ̶i̶r̶r̶e̶v̶e̶r̶s̶i̶b̶i̶l̶i̶t̶y̶ ̶i̶s̶ ̶a̶ ̶f̶u̶n̶c̶t̶i̶o̶n̶ ̶o̶f̶ ̶n̶u̶m̶b̶e̶r̶ ̶o̶f̶ ̶b̶l̶o̶c̶k̶s̶&amp;̶m̶d̶a̶s̶h̶;̶ ̶n̶o̶t̶ ̶o̶f̶ ̶t̶i̶m̶e̶— ̶a̶n̶d̶ ̶t̶h̶e̶ ̶d̶i̶s̶a̶d̶v̶a̶n̶t̶a̶g̶e̶ ̶o̶f̶ ̶d̶e̶l̶a̶y̶s̶ ̶i̶n̶ ̶t̶r̶a̶n̶s̶a̶c̶t̶i̶o̶n̶s̶,̶ ̶i̶t̶ ̶s̶e̶e̶m̶s̶ ̶a̶ ̶s̶h̶o̶r̶t̶e̶r̶ ̶b̶l̶o̶c̶k̶ ̶t̶i̶m̶e̶ ̶i̶s̶ ̶c̶o̶m̶p̶e̶l̶l̶i̶n̶g̶.̶</p>

<p>I would appreciate if downvoters would at least try to defend their logic with a comment below my answer. That gives me an opportunity to debate them and show them why I think they are wrong (or to admit my mistake). The point is to make sure we collectively have the correct logic.</p>

CC BY-SA 3.0
2017-01-12T15:39:25.427Z
This answer is disregarding the time cost incurred by block transmission and block verification. Since that time is a roughly fixed amount for a full block, it is a larger relative portion of a shorter block interval than a longer block interval.
Murch
CC BY-SA 3.0
2017-09-24T04:31:18.207Z
@Murch, I wrote that answer a few days or weeks after initiating my study of blockchains, cryptography, and Bitcoin. My views have changed considerably hence. However, presuming the transaction volume per block is reduced given a higher block frequency, your claim of constant propagation & verification time isn’t correct. Craig Wright has claimed the Bitcoin network propagates to 99% _of the hashrate_ within roughly a second.
Shelby Moore III
CC BY-SA 3.0
2017-09-24T04:53:25.537Z
Since practically all miners are connected to Fibre and published data suggest that it's just slightly slower than speed of light, <1 second is not a difficult claim to make… However, the most significant impact this year was probably that miners upgraded to a recent version of Bitcoin Core to signal for the segwit activation. Earlier this year, we were still seeing multiple orphaned blocks per week. A blocktime of e.g. 60 seconds would have regressed us back to multiple orphaned blocks per day. Since the data is there to look at, it's puzzling that you seem to deny the effect.
Murch
CC BY-SA 4.0
2019-09-27T17:22:38.443Z
@Murch, did SegWit reduce the average block size by a factor of 10? If not, then presumably the data you’re citing isn’t addressing my point. I do understand now (not that I did in 2016 when I wrote that answer) that shorter block times also increase asymmetric advantages for coalitions of hashrate such as pools which see their winning blocks instantly (no propagation delay). So excessive orphans could be selfish mining in action. Note Ethereum’s variant of GHOST is a partial solution to some of that.
Shelby Moore III
CC BY-SA 3.0
2013-03-20T12:16:08.920Z
2017-09-24T04:35:26.103Z
2017-09-24T04:35:26.103Z
Shelby Moore III
<p>10 minute blocks is simply a compromise.</p>

<p><strong>Shorter block time:</strong></p>

<ul>
<li>PRO - Faster 1 confirmation time (to protect from 0-confirm double spend)</li>
<li>PRO - Less payout variance for miners (less reliance on large pools)</li>
<li>CON - Requires increased bandwidth (inter node communication)</li>
<li>CON - More forks, longer forks, and longer re-org time</li>
<li>CON - A greater portion of the raw hashpower is wasted, resulting in lower effective security.</li>
</ul>

<p>With a longer block interval target of longer than 10 minutes, the pros and cons would be reversed.</p>

<p><strong>The major benefit of a shorter block time is the reduced 1 confirm time.</strong>  While a quicker block's 1 confirm transaction has less strength than a longer block's 1 confirm transaction it is still better than any block's 0 confirm transaction.  </p>

<p>The speed of 1st confirm may seem to be a huge benefit but in reality for most low value and time sensitive transactions such as the buying a cup of coffee, paying for a taxi, or using a vending machine, the risk of double spends is very low. Keep in mind that accepting credit cards is not without risk however merchants have long accepted they will face some losses however if those losses are minimal then it can just be seen as a cost of doing business.  So many merchants could simply accept 0-confirm transactions without exposing themselves to more risk than they do from credit card fraud.</p>

<p>The other factor that diminishes the real world potential of shorter target block intervals is that for many merchants, even  "faster" confirmation times still isn't fast enough. For a Point of Sale transaction, an average confirmation time of 2 minutes is still significantly longer than what most merchants would consider to be workable. The average credit card transaction takes about 20 seconds (including delays by customer).  The entire industry has spent significant resources to shave even a few seconds off.  Changes like enabling customer to swipe card, swiping before all items have been rung up, and not requiring signatures on low value are all about shaving a couple seconds off an already quick process and the cost of those changes is considered acceptable in order to slightly improve the efficiency of a checkout.</p>

<p>The other factor is that reducing the target interval only reduces the average confirmation time but half of them will be longer and the tail can be very long. Due to the random nature of blocks solutions about 15% of blocks will take longer than 2x the target, 3% longer than 3x the target and >7.5 minutes and about 0.5% will take longer than 4x the target.  That uncertainty makes it difficult for a time sensitive business to as a matter of policy wait for confirmations.  Having most transactions confirm in 30 seconds but some take minutes is going to lead to customer frustration at the point of sale.</p>

<p>If the BTC economy grows large enough we could see expanded use of "green addresses" to fill the need for instant acceptance without confirmations.  Such services could be provided by major corporations, and backed by insurance against fraud (for a small per transaction fee).  This would be a more viable 0-confirm solution than a simple reduction of the block interval.</p>

<p>That being said the 10 minute target was probably overly conservative and there are some advantages to a shorter block time.</p>

CC BY-SA 3.0
2015-06-26T13:59:00.627Z
Very nice update, I wish I could upvote again. ;)
Murch
CC BY-SA 3.0
2016-02-09T11:01:27.447Z
Further: shorter blocks means more storage for pruned and SPV nodes.
Pieter Wuille
CC BY-SA 3.0
2011-11-03T14:20:05.537Z
Your mistake is that you think "double spend attack" means "51% attack". You can try to double spend with less but you're not guaranteed success. The more blocks waited, the smaller your chance. >50% is the point where you're guaranteed eventual success no matter how many blocks are waited.
The probability of success with a <50% attack depends on the number of blocks and not the amount of time. This is an advantage of shorter blocks.
Meni Rosenfeld
CC BY-SA 3.0
2011-11-03T14:23:17.110Z
Shorter block time has another pro - less variance for miners. Also, the extra storage space for short blocks is negligible since the bulk of data is the transactions, not the block headers.
Meni Rosenfeld
CC BY-SA 3.0
2011-11-03T14:24:19.447Z
You have some typos: The first 2 entries for "Longer block time" should be "CON" and "PRO" rather than "PRO" and "RRO".
Meni Rosenfeld
CC BY-SA 3.0
2011-11-03T14:54:32.280Z
@MeniRosenfeld Thanks for the corrections and I added variance differences and removed the storage differences as you are correc the differences will be rather small.  I also removed the time based aspect because while I have heard it requires more confirmations I don't have definitive knowledge.  There are enough other known differences.
DeathAndTaxes
CC BY-SA 3.0
2011-11-03T12:45:16.617Z
2015-06-26T15:14:28.950Z
2015-06-26T15:14:28.950Z
DeathAndTaxes
<p>According to the <a href="https://en.bitcoin.it/wiki/FAQ#Why_do_I_have_to_wait_10_minutes_before_I_can_spend_money_I_received.3F" rel="noreferrer">wiki</a>, 10 minutes was chosen as a 'tradeoff'.</p>
<blockquote>
<p>Why ten minutes specifically? It is a tradeoff chosen by Satoshi between propagation time of new blocks in large networks and the amount of work wasted due to chain splits.</p>
</blockquote>
<p>However in the <a href="https://bitcoin.org/bitcoin.pdf" rel="noreferrer">original Satoshi paper</a>, 10 minutes is merely assumed for the purposes of calculating disk space requirements.</p>
<blockquote>
<p>A block header with no transactions would be about 80 bytes. If we suppose blocks are
generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year.</p>
</blockquote>
<p>Is there a discussion elsewhere that explains how the 10 minute block time was arrived at?</p>

CC BY-SA 3.0
2016-02-08T17:48:14.510Z
Mike Hearn explained to me once that Satoshi estimated block propagation time to be 1 minute, and chose 10-minute block intervals because "wasting" 10% of mining work was a fair amount. Currently block propagation time is much, much faster though.
pinhead
CC BY-SA 4.0
2019-12-11T17:48:53.603Z
@pinhead What exactly do you mean by wasting 10% of mining work?
Five Points
CC BY-SA 4.0
2019-12-11T19:35:44.227Z
@FivePoints in this context, we mean that 10% of blocks mined will "lose the race" against another block mined at nearly the same time and become stale, meaning the subsidy payout to the miner will never be spendable and the energy consumed by the miner to produce that block will be wasted.
pinhead
CC BY-SA 4.0
2019-12-11T20:36:20.220Z
@pinhead makes sense but how was that 10% calculated? Is it simply (latency / block time)?
Five Points
CC BY-SA 4.0
2019-12-11T21:35:37.863Z
@FivePoints exactly. That was apparently Satoshi's thinking according to Mike Hearn
pinhead
CC BY-SA 4.0
2019-12-11T21:41:44.673Z
@FivePoints source, for what its worth: https://www.reddit.com/r/Bitcoin/comments/30lxo4/replace_by_fee_a_counter_argument_by_mike_hearn/cptwk21
pinhead
CC BY-SA 4.0
2021-06-17T23:43:09.147Z
@pinhead It appears that your accounting of waste fails to include all the waste of the machines that did not finish in 10 minutes.
H2ONaCl
CC BY-SA 3.0
2011-11-03T12:28:11.170Z
I think that if the 10 minute block requirement proves problematic for some reason, and most miners & users agree, this can be lowered in the future.
ripper234
<security><mining-theory><block-interval>
Why was the target block time chosen to be 10 minutes?
z7sg Ѫ
# Why was the target block time chosen to be 10 minutes?

(Asked by: username_0 on 2011-11-03)

According to the [wiki](https://en.bitcoin.it/wiki/FAQ#Why_do_I_have_to_wait_10_minutes_before_I_can_spend_money_I_received.3F), 10 minutes was chosen as a 'tradeoff'.

> Why ten minutes specifically? It is a tradeoff chosen by Satoshi between propagation time of new blocks in large networks and the amount of work wasted due to chain splits.

However in the [original Satoshi paper](https://bitcoin.org/bitcoin.pdf), 10 minutes is merely assumed for the purposes of calculating disk space requirements.

> A block header with no transactions would be about 80 bytes. If we suppose blocks are
> generated every 10 minutes, 80 bytes \* 6 \* 24 \* 365 = 4.2MB per year.

Is there a discussion elsewhere that explains how the 10 minute block time was arrived at?

**Tags:** security, mining-theory, block-interval

> **Comments:**
> **username_4**: I think that if the 10 minute block requirement proves problematic for some reason, and most miners & users agree, this can be lowered in the future.  
> **username_1**: Mike Hearn explained to me once that Satoshi estimated block propagation time to be 1 minute, and chose 10-minute block intervals because "wasting" 10% of mining work was a fair amount. Currently block propagation time is much, much faster though.  
> **username_2**: @username_1 What exactly do you mean by wasting 10% of mining work?  
> **username_1**: @username_2 in this context, we mean that 10% of blocks mined will "lose the race" against another block mined at nearly the same time and become stale, meaning the subsidy payout to the miner will never be spendable and the energy consumed by the miner to produce that block will be wasted.  
> **username_2**: @username_1 makes sense but how was that 10% calculated? Is it simply (latency / block time)?  
> **username_1**: @username_2 exactly. That was apparently Satoshi's thinking according to Mike Hearn  
> **username_1**: @username_2 source, for what its worth: https://www.reddit.com/r/Bitcoin/comments/30lxo4/replace_by_fee_a_counter_argument_by_mike_hearn/cptwk21  
> **username_3**: @username_1 It appears that your accounting of waste fails to include all the waste of the machines that did not finish in 10 minutes.  

---

## 5 answers

### Answer by username_11 on 2011-11-03. Score: 41 | Accepted answer

10 minute blocks is simply a compromise.

**Shorter block time:**

* PRO - Faster 1 confirmation time (to protect from 0-confirm double spend)
* PRO - Less payout variance for miners (less reliance on large pools)
* CON - Requires increased bandwidth (inter node communication)
* CON - More forks, longer forks, and longer re-org time
* CON - A greater portion of the raw hashpower is wasted, resulting in lower effective security.

With a longer block interval target of longer than 10 minutes, the pros and cons would be reversed.

**The major benefit of a shorter block time is the reduced 1 confirm time.** While a quicker block's 1 confirm transaction has less strength than a longer block's 1 confirm transaction it is still better than any block's 0 confirm transaction.

The speed of 1st confirm may seem to be a huge benefit but in reality for most low value and time sensitive transactions such as the buying a cup of coffee, paying for a taxi, or using a vending machine, the risk of double spends is very low. Keep in mind that accepting credit cards is not without risk however merchants have long accepted they will face some losses however if those losses are minimal then it can just be seen as a cost of doing business. So many merchants could simply accept 0-confirm transactions without exposing themselves to more risk than they do from credit card fraud.

The other factor that diminishes the real world potential of shorter target block intervals is that for many merchants, even "faster" confirmation times still isn't fast enough. For a Point of Sale transaction, an average confirmation time of 2 minutes is still significantly longer than what most merchants would consider to be workable. The average credit card transaction takes about 20 seconds (including delays by customer). The entire industry has spent significant resources to shave even a few seconds off. Changes like enabling customer to swipe card, swiping before all items have been rung up, and not requiring signatures on low value are all about shaving a couple seconds off an already quick process and the cost of those changes is considered acceptable in order to slightly improve the efficiency of a checkout.

The other factor is that reducing the target interval only reduces the average confirmation time but half of them will be longer and the tail can be very long. Due to the random nature of blocks solutions about 15% of blocks will take longer than 2x the target, 3% longer than 3x the target and >7.5 minutes and about 0.5% will take longer than 4x the target. That uncertainty makes it difficult for a time sensitive business to as a matter of policy wait for confirmations. Having most transactions confirm in 30 seconds but some take minutes is going to lead to customer frustration at the point of sale.

If the BTC economy grows large enough we could see expanded use of "green addresses" to fill the need for instant acceptance without confirmations. Such services could be provided by major corporations, and backed by insurance against fraud (for a small per transaction fee). This would be a more viable 0-confirm solution than a simple reduction of the block interval.

That being said the 10 minute target was probably overly conservative and there are some advantages to a shorter block time.

> **Comments:**
> **username_8**: Your mistake is that you think "double spend attack" means "51% attack". You can try to double spend with less but you're not guaranteed success. The more blocks waited, the smaller your chance. >50% is the point where you're guaranteed eventual success no matter how many blocks are waited. The probability of success with a <50% attack depends on the number of blocks and not the amount of time. This is an advantage of shorter blocks.  
> **username_8**: Shorter block time has another pro - less variance for miners. Also, the extra storage space for short blocks is negligible since the bulk of data is the transactions, not the block headers.  
> **username_8**: You have some typos: The first 2 entries for "Longer block time" should be "CON" and "PRO" rather than "PRO" and "RRO".  
> **username_11**: @username_8 Thanks for the corrections and I added variance differences and removed the storage differences as you are correc the differences will be rather small.  I also removed the time based aspect because while I have heard it requires more confirmations I don't have definitive knowledge.  There are enough other known differences.  
> **username_6**: Very nice update, I wish I could upvote again. ;)  
> **username_12**: Further: shorter blocks means more storage for pruned and SPV nodes.  

---

### Answer by username_5 on 2013-06-27. Score: 9

I found that part of the wiki frustrating too, and I just edited it. I'd appreciate corrections. Here's what I wrote:

> Ten minutes was specifically chosen by Satoshi as a tradeoff between first confirmation time and the amount of work wasted due to chain splits. After a block is mined, it takes time for other miners to find out about it, and until then they are actually competing against the new block instead of adding to it. If someone mines another new block based on the old block chain, the network can only accept one of the two, and all the work that went into the other block gets wasted. For example, if it takes miners 1 minute on average to learn about new blocks, and new blocks come every 10 minutes, then the overall network is wasting about 10% of its work. Lengthening the time between blocks reduces this waste.
>
> As a thought experiment, what if the Bitcoin network grew to include Mars? From the farthest username_2 in their orbits, it takes about 20 minutes for a signal to travel from Earth to Mars. With only 10 minutes between new blocks, miners on Mars would always be 2 blocks behind the miners on Earth. It would be almost impossible for them to contribute to the block chain. If we wanted collaborate with those kinds of delays, we would need at least a few hours between new blocks.

> **Comments:**
> **username_6**: Also see: http://bitcoin.stackexchange.com/questions/30001/how-do-you-create-a-planet-specific-cryptocurrency-that-will-ignore-longer-block  

---

### Answer by username_7 on 2011-11-03. Score: 3

As Bitcoins are the first cryptocurrency to use block generation and so forth, one can assume 10 minutes was a arbitrarily chosen. Any value that was big enough to propagate the new block through the network before another miner would be probable to generate a new block would be good. On the other end blocks shouldn't be too scarce, as it would take too long to get confirmations. [An hour of computation](https://bitcoin.stackexchange.com/questions/1170/why-is-6-the-number-of-confirms-that-is-considered-secure) is considered safe from being tampered with, so dividing that time into neat parts can give you 10 minutes.

There probably isn't any discussion available on this topic, as the first Bitcoin version was created by Satoshi alone, so until he reveals his true identity or comes back to the community, the exact reasons can't be figured out for sure.

> **Comments:**
> **username_8**: The analysis in Satoshi's paper doesn't at all relate to the amount of time one should wait - that depends solely on the practicality of maintaining a high hashrate for a long time. He discussed the amount of blocks to wait - he showed, for example, that if the recipient waits for 6 blocks and the attacker has 10% of the network's hashrate, a double-spend attempt only has <0.025% chance to succeed. At 1 minute per block this is 6 minutes, etc.  

---

### Answer by username_9 on 2021-05-27. Score: 0

Block time was determined by Satoshi Nakamoto as a tradeoff between 2 factors

1.Network latency:  
After a block is mined, it takes some time for other miners to find out about that node and during that time, actually other miners are still competing (which means mining) against that block instead of adding that block to the chain. This leads to the waste of mining resources which is caused because several miners are still mining their blocks but the network can add only one. Plus this is a fact that it will take some time for any new mined block to show up to all the nodes since network lag is a thing.

2.Confirmation time:  
We can be sure about the confirmation of a block being added to the chain/network only after some blocks are added to that chain. And to make confirmation more reliable about 5-6 blocks are needed to be added to the chain after our block. This will surely take some time. But we need to make this process fast.

Now, the network lag factor needs the block time to be longer whereas the confirmation time factor needs it to be shorter. Hence a trade off was chosen which is 10 minutes. This time length was surely chosen after some calculations. But theoretical reason behind the block time is same as described in this answer.


---

### Answer by username_10 on 2013-03-20. Score: -3

AFAICS, the only possible benefit to the longer block time is the reduction of bandwidth overhead due to less probability of block chain splits.

I even doubt that tradeoff, because if the transaction data is the bulk then there is the counter-balancing effect that shorter block times mean less data to transmit.

I am highly skeptical that there must be more work wasted with shorter block time, if the difficulty is calibrated w.r.t. the time to arrive at a consensus. Mathematically the miners earn a percentage of the newly created blocks proportioned roughly by their percentage of the system hash power, regardless the relative split in proportion of their luck between work difficulty and (the random) orphaned chains.

Unless there is a proof, I doubt the claim that shorter block times create longer times to arrive at consensus (i.e. re-org splits), because for example if there are 4 times more splits with 1/4 the block time, there are roughly 7 more iterations to arrive at consensus within the same duration.

G̶i̶v̶e̶n̶ ̶t̶h̶a̶t̶ ̶i̶r̶r̶e̶v̶e̶r̶s̶i̶b̶i̶l̶i̶t̶y̶ ̶i̶s̶ ̶a̶ ̶f̶u̶n̶c̶t̶i̶o̶n̶ ̶o̶f̶ ̶n̶u̶m̶b̶e̶r̶ ̶o̶f̶ ̶b̶l̶o̶c̶k̶s̶&̶m̶d̶a̶s̶h̶;̶ ̶n̶o̶t̶ ̶o̶f̶ ̶t̶i̶m̶e̶— ̶a̶n̶d̶ ̶t̶h̶e̶ ̶d̶i̶s̶a̶d̶v̶a̶n̶t̶a̶g̶e̶ ̶o̶f̶ ̶d̶e̶l̶a̶y̶s̶ ̶i̶n̶ ̶t̶r̶a̶n̶s̶a̶c̶t̶i̶o̶n̶s̶,̶ ̶i̶t̶ ̶s̶e̶e̶m̶s̶ ̶a̶ ̶s̶h̶o̶r̶t̶e̶r̶ ̶b̶l̶o̶c̶k̶ ̶t̶i̶m̶e̶ ̶i̶s̶ ̶c̶o̶m̶p̶e̶l̶l̶i̶n̶g̶.̶

I would appreciate if downvoters would at least try to defend their logic with a comment below my answer. That gives me an opportunity to debate them and show them why I think they are wrong (or to admit my mistake). The point is to make sure we collectively have the correct logic.

> **Comments:**
> **username_6**: This answer is disregarding the time cost incurred by block transmission and block verification. Since that time is a roughly fixed amount for a full block, it is a larger relative portion of a shorter block interval than a longer block interval.  
> **username_10**: @username_6, I wrote that answer a few days or weeks after initiating my study of blockchains, cryptography, and Bitcoin. My views have changed considerably hence. However, presuming the transaction volume per block is reduced given a higher block frequency, your claim of constant propagation & verification time isn’t correct. Craig Wright has claimed the Bitcoin network propagates to 99% _of the hashrate_ within roughly a second.  
> **username_6**: Since practically all miners are connected to Fibre and published data suggest that it's just slightly slower than speed of light, <1 second is not a difficult claim to make… However, the most significant impact this year was probably that miners upgraded to a recent version of Bitcoin Core to signal for the segwit activation. Earlier this year, we were still seeing multiple orphaned blocks per week. A blocktime of e.g. 60 seconds would have regressed us back to multiple orphaned blocks per day. Since the data is there to look at, it's puzzling that you seem to deny the effect.  
> **username_10**: @username_6, did SegWit reduce the average block size by a factor of 10? If not, then presumably the data you’re citing isn’t addressing my point. I do understand now (not that I did in 2016 when I wrote that answer) that shorter block times also increase asymmetric advantages for coalitions of hashrate such as pools which see their winning blocks instantly (no propagation delay). So excessive orphans could be selfish mining in action. Note Ethereum’s variant of GHOST is a partial solution to some of that.  

---

