Why was the target block time chosen to be 10 minutes?

Question

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?

Answer 1

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.

Answer 2

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.

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

Answer 4

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 5

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.