According to the wiki, 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, 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?

  • 2
    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
    Commented Nov 3, 2011 at 12:28
  • 4
    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
    Commented Feb 8, 2016 at 17:48
  • @pinhead What exactly do you mean by wasting 10% of mining work? Commented Dec 11, 2019 at 17:48
  • @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
    Commented Dec 11, 2019 at 19:35
  • @pinhead makes sense but how was that 10% calculated? Is it simply (latency / block time)? Commented Dec 11, 2019 at 20:36

5 Answers 5


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.

  • 4
    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. Commented Nov 3, 2011 at 14:20
  • 3
    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. Commented Nov 3, 2011 at 14:23
  • You have some typos: The first 2 entries for "Longer block time" should be "CON" and "PRO" rather than "PRO" and "RRO". Commented Nov 3, 2011 at 14:24
  • @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. Commented Nov 3, 2011 at 14:54
  • Very nice update, I wish I could upvote again. ;)
    – Murch
    Commented Jun 26, 2015 at 13:59

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


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

  • 1
    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. Commented Nov 3, 2011 at 14:47

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.


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.

  • 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
    Commented Jan 12, 2017 at 15:39
  • @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. Commented Sep 24, 2017 at 4:31
  • 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
    Commented Sep 24, 2017 at 4:53
  • @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. Commented Sep 27, 2019 at 17:22

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.