Topic: Why 10 min block mining? (Read 394 times)

The code has a parameter of recalculating the difficulty every 2016 blocks, however, the bitcoin whitepaper specifically references blocks being found once every 10 minutes.

The significance of a 2016 block period is, in my opinion, similar to my explanation as to why the 10 minute target for blocks is 10 minutes -- I think it is likely to be a combination of engineering optimization, and to allow for bitcoin to be easily explained to a non-technical user ("bitcoin's difficulty changes approximately once every two weeks" as being a dumbed down explanation as to how frequently the difficulty is recalculated).

That's a very good example.

Two weeks and ten minutes is simply easiest to remember.

If you have 30 days, then you have a constantly mismatch with the changing day of the month due to 28/29/30/31 all being possible days in the month. 30 days is a weird combination of regularity.. and not. It's better to set it at two weeks than 30 days because then you have something both easy to remember, regular, but also doesn't automatically confuse people with a changing day of the month. It's better to force people to have to think about the date if there's no possible regular day because culture and solar calendars don't divide easily together (365.25 days in a year, 7 days in a week..)

Ten versus fifteen minutes is probably similar thinking, with ten being slightly easier to remember, but both dividing from an hour easily. Five minutes is the only other possibility that fits within these logics of network usability and memory friendliness, but five minutes feels too short.

Your example shows that it is partly arbitrary though.

In the prenet, it was coded in this way:
That means, it was 15 minutes block time and retarget per 30 days. And we currently have this: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L81-L82
As you can see, only those first numbers changed. I guess Satoshi wanted one integer for timespan and one integer for spacing, where timespan was measured in days (M * 24 * 60 * 60) and spacing was measured in minutes (N * 60). Also I guess that he wanted to pick something to reach intervals without remainder. So, he switched from some obvious solution (M=30;N=15) to some less obvious, but still valid solution (M=14;N=10). It is less obvious, because 30/15=2 and has zero remainder, but 14/10=1 has non-zero remainder 4.

If you want to figure out why Satoshi chose the parameters this way and if you are asking about "why 10 minutes" then you are already asking the wrong question because "10 minute" is not an existing parameter. The parameter that exists and should be investigated is "2016 blocks in 2 weeks". So the question should be what was the significance of 2016?

He may well have performed some tests on various target block times, and chose 10 minutes because it was near the ideal target block time and is easy to remember.

I think it is unlikely that a 10 minute block target time is the optimal time from purely an engineering perspective. I think it is most likely that the 10 minute target time is a compromise between being able to easily explain how bitcoin works, and the optimal target block time. I would imagine that explaining that blocks are found on average, once every 9.45 minutes would probably hinder the long-term adoption of bitcoin

Satoshi discussed this here:


He highlights latency of one minute being a main issue with a large network size. He also highlights being concerned about the total block size.

Bitcoin has a longer latency than possible because of how nodes request information, as he discussed in the mailing list on 17-11-2008,


Also related, in a letter to Mike Hearn, 12 Apr 2009, Satoshi wrote while discussing fast micropayments:

Or maybe Satoshi already had set his mind for 10 minute blocks and he was trying to defend that decision for himself, against himself through the whitepaper? Hahaha.

OP, faster intervals between blocks don't matter once security assurances are truly considered. One confirmation in security assurance in Bitcoin would be worth more confirmations of a shitcoin.

Yes, that's what i wanted to mention since the change doesn't happen on Bitcoin on-chain layer and IMO it's different from what OP asked.


It's plausible explanation, but difference between best case (block header with no TX) and average storage/RAM in 2008 is too wide.

Partly that, but in the whitepaper, Satoshi did mention it as a measurement for calculation of RAM/disk space requirements. It can be that as arbitrary as "10 minute block time "is believed to be, it might really be based on the current hardware available of that time when he wrote the whitepaper.

Once the block subsidy falls to near zero (let's say in ~2084, when it falls to below 10,000 sats), then sure, mining empty blocks will probably be pointless. But for many decades yet, miners will still be incentivized to run their ASICs before fully verifying the previous block and removing all the transaction from their mempools. No point having all their machines sitting idle for ~10 seconds every time a block is found while there is still a significant block subsidy - that's just a waste of their money.

Eventually mining empty blocks will be pointless (unless there are other reasons for mining the block, such as including data for some other protocol), but that won't have any effect on the points I made above about a much shorter block not helping point-of-sale transactions.

It is not a problem in case of merged mining, because if someone will produce a block with transactions A, B and C, another miner can still make a block with transactions B, C, and D, if that previous block does not meet the mainchain difficulty. Also, the basic block reward is going to be zero, then empty blocks will be worthless and we will have different issues.

Reducing the block time to make BTC good for buying a cup of coffee won't work, the way the blockchain works makes it pretty crippled in that aspect, of course, this is just a trade-off for the decentralization and security, so bitcoin "as is" is simply not fit for this, it doesn't matter how much you reduce the block time, mining is an exponential distribution process and as o_e_l_e_o explained above nearly 37% of blocks will need more than the meantime.

Another issue you could potentially create by reducing block time intervals would be more empty blocks  -- if the network would find a block every 5 seconds on average every pool will just start mining on top of the previous block without verifying its transactions, dealing with its mempool to remove transactions which were included in the last block will impose a great risk to the pool, so nobody in their right mind would waste time dealing with transactions, just mine the next block, heck, even today, many pools send empty work templates to the miners after they sense a new block, and then sometime later they would send a new block template with the transactions, so if the block intervals were just a few seconds every pool would probably just mine empty blocks.

So this means, you are kind of forced to have minutes long intervals, and in that case, 10 mins or 5 mins doesn't really make a difference for buying coffe.

Yes, the main idea is just that no consensus changes are needed to use that. You can even reduce it to one second and have 600 blocks per 10 minutes, because why not, you can do that and find out, why this is a bad idea. If it is mined in a merged-mining way and if some blocks are also pushed on Bitcoin mainnet, then your chain is still a part of the network. If you want to accept one or more confirmations of your "sharechain" instead of waiting for one confirmation on the mainchain, you still can. And it is compatible, because those who stick with 10 minutes per block are not affected by your changes.

Yes, the speed of the chain depends on connected miners and their computing power. It works just like any other merged-mining: you produce exactly the same blocks in exactly the same way, but some of them are valid only in your network (because of easier difficulty) and some of them are valid in both networks, and that blocks contain a commitment that pushes your chain forward and enforces all your rules on mainnet.

In general, the difficulty is not a problem. I thought about decentralized mining, where you have some full node with N connections, and per each of them, you adjust some difficulty and distribute rewards based on shares received from nodes. Then, each miner could produce one share every 10 minutes (or every sometimes, it could be configurable), and then it does not really matter if you have thousand or million of miners, because you only handle your connections (or your lightning channels, if those rewards would be distributed in LN).

You can make it faster, but you'd have to get rid of the independent peer to peer aspects. Distributed can be much, much faster but requires control by a single head.


It's not completely arbitrary.

There is a maximum defined by human usability: You as an individual generally don't want to wait for 24 hours to confirm that you've paid an individual unless you are dealing with an insanely large sum of money and checks. Even an hour feels long but would be tolerable for larger transfers.

There is a minimum:
The minimum is defined by the need time for your node to get information, to process information, and send information.
Global network latency averages about 200 ms. Satellite latency can be longer at 800 ms.
This limits you to say 500 ms receive, block verification time, block mining time, 500 ms send, so you can't have sub-second transactions easily without double spends and that's before you have to do any proof of work AND verification of transactions.

Since we now require a limit above a second, then what's a few more seconds?

Considering you want the method to be peer to peer, you need time to propagate between peers and peers in different networks and continents. The speed that you think the data can propagate between all peers now defines the next step: if you think you need to (synchronously) spread to 100 peers in order to reach thousands with the successful block, then you now are limited to a minute or two. So, a minute or two to just send/spread, and then a minute or two to receive. The delay because it's caused by the peer to peer action. All before solving verifying other proof of work and solving the next proof of work.

Proof of work then becomes inconsequential. So, why not just double the time because ten minutes sounds good? The auto-adjustment every two weeks is arbitrary, so ten minutes is partially arbitrary because it has to work with normal behavior and try to account for changes in technology and interest.

Obviously there are faster ways to do things, but this was never just about speed. And those imagined network connections aren't completely real in practice.

There are other considerations, like with ten minutes you can do replace-by-transaction if you really feel you messed up and notice soon enough, but you also can't reverse it after that reasonable length of time.

There's a tolerance. The randomness causes it to fall roughly between these bounds.

But the next block is for the people who pay the highest fees for premium service, so those minimum of seconds or minutes begin to be pushed out to longer quite quickly.

So yes, it was partially arbitrary, but not completely.

I'm a bit confused about that as well. If it chooses a 30s 'block time', that's just the speed of the share chain. It obviously needs to have a difficulty that is much lower than the actual blockchain diff so that miners can regularly submit valid shares.
This doesn't mean that a valid extension of the actual blockchain is found much more quickly, it just means that n'*20=n. Stale blocks aren't a big problem in such a share chain.

Ahh damn. And here's me using bitcoin as a currency for over 5 years, not realizing that it can't be used a currency.

To expand on the quote of mine that BHC has given in the first reply: One minute, or even sub-minute blocks, do not solve the problem you are proposing them as a solution for. You can use the following equation to calculate the probability of not finding a block within a given time frame, with x being equal to how many blocks you would expect to find within that time frame:

P = e^-x

Let's say, for example, we drop the block time to 1 minute. e^-1 gives a ~37% of not finding a block in a minute. e^-3 gives a ~5% chance of not finding a block within 3 minutes. So for 1 in 20 sales, you will still be waiting at least 3 minutes (and perhaps much longer) for your first confirmation. This is unacceptable for most point-of-sale transactions, where there are a queue of people waiting to pay.

Further, you now have to consider chain reorgs. As explained above, competing blocks at the same height, stale blocks, and reorgs of >1 block all become exponentially more frequent with a shorter block time. And the security of each of those 1 minute confirmations is only one tenth of the security of a current confirmation. You would need to wait for 10 confirmations to reach the same level of security. So even although 1 minute confirmations are already too slow, merchants decide they want to wait for 3 or more to be sure their confirmed transaction isn't suddenly reversed. So now you are waiting even longer.

The solution to this is either for the merchant to accept zero confirmation transactions for smaller amounts, or to use Lightning. Reducing the block time doesn't solve the problem.

Not to mention that is much easier to reverse such payment. You can just give a call and have it reversed. On the other hand, in Bitcoin, transaction confirmation isn't down to you nor to a financial institution. You'll have to bribe some of the mining pools and you'll still have a great percentage of uncertainty.

Who says that?! You can not even find a single payment system that has fast settlement. Take credit cards for example, it takes at least 6 months for the payment to be settled or become irreversible. Bank transfers, online payment processors, ... are all the same and take extremely long time to be settled that could be from days to months. Not to mention that these are all reversible.
Bitcoin settlements when the payment becomes irreversible is ridiculously fast compared to any other monetary system that takes 10 minutes on average.

It could be possible on Layer Zero. I thought about one block per two weeks or something like that, then the difficulty for one "superblock" could be better compressed. It seems to be enough to have some data to compress and simplify, and also seems to be good for signalling and stuff like that. But such ideas are still in progress, because it is too inefficient for decentralized mining, where every node has to check all blocks produced by all miners (and checking the whole block is needed to handle cases, where basic block reward is zero and miners are rewarded only in fees, then validating all transactions is needed to validate the coinbase amount).

There are layer 2 solutions that work on top of the bitcoin blockchain that allows for ~instant settlements, such as LN.

If the average block time were to be reduced, there would be an increase in the number of stale blocks, and a larger increase in a chain of stale blocks. This will reduce the reliability of waiting 10 minutes after transactions have been sent.