Why 10 min block mining?

[thirdprize]

What was the logic behind taking 10 mins to mine a block?  Was it by design or accident?  Anything that wants to be used as money needs at least sub minute, preferably sub second blocks.  Unless it was intended for batch processing over night. Can't we just make it quicker and reduce the rewards appropriately?

[1714653821]

1714653821

[1714653821]

1714653821

[BlackHatCoiner]

Reducing the 10 minutes block interval, which rewards with 6.25 BTC to, say, 1 minute block interval, which rewards with 0.625 BTC isn't the same security-wise. The reason is that the network works asynchronously. Propagation takes some time, and if two miners solve the same block, we call one of those a "stale block".

Therefore, the less the interval the more the chances to have stale blocks. Quoting this excellent post which describes it better:

But we still have stale blocks with a frequency of somewhere around 0.1% with a block time of 10 minutes. Decreasing that to 1 minute would increase the number of stale blocks exponentially.

The probability of finding a block in time x is given by the equation 1 - e^(-x/y), where y is the expected block time. If we take x = 10 and y = 600, then the chances of finding a block with 10 seconds currently is around 1.65%. If you drop the block time to a minute and make y = 60, then that chance increases to 15.35%. That's a huge increase in stale blocks and a huge increase in wasted hash power.

[bill gator]

This has been a discussion in the community ever since the idea of mass-adoption was brought up. This has been the cause of forks, fights and frustration throughout the years and I don't think there will ever be a perfect solution.

Quicker blocks is less stability, slower blocks is less convenient  - one can only hope there was purpose behind 10-minute blocks, 21,000,000 bitcoins, the year 2140 and all of the other numerology that surrounds our cult.

[BlackHatCoiner]

Quicker blocks is less stability, slower blocks is less convenient  - one can only hope there was purpose behind 10-minute blocks, 21,000,000 bitcoins, the year 2140 and all of the other numerology that surrounds our cult.

There's nothing odd with the 10 minutes interval. It's the best trade-off in efficiency, security and simplicity. The 21,000,000 was rather probably the only arbitrary choice. I like thinking there's a correlation with this:

42 is the Answer to Life, the Universe, and Everything.

That's also a spooky coincidence:

January 9th, 1988:
The Economist publishes "Get ready for a world currency".

January 9th, 2009:
#Bitcoin block 1 is mined.

21 years later, to the exact day

Which is, by the way, another Britain weekly newspaper.

[garlonicon]

Can't we just make it quicker and reduce the rewards appropriately?

You can, P2Pool did just that, they reduced it 20 times, reaching 30 seconds per block.

[kaggie]

That's also a spooky coincidence:

January 9th, 1988:
The Economist publishes ..

Which is, by the way, another Britain weekly newspaper.

Cool.

Imagine if we ever have a solar currency, then we will have to increase the block time and a bitcoin based currency will be the only one available.

It takes 12 - 22 minutes for light to reach Mars from Earth. It takes light from the sun about 10 minutes to reach Earth.

10 minutes is probably just a 'good time'. Most things take ten minutes long. "Just ten more minutes!" is a common expression. It's an appropriate amount of time to see what's going on and to respond as a normal human person, but not too long that you have to wait for much longer. It's a good amount of time for being able to debug, simulate, or have a presentation with the important facts.

and all of the other numerology that surrounds our cult.

There are so many ridiculous numbers. People will find patterns in anything. Some of those patterns may mean something, and others may mean nothing.

[PrimeNumber7]

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.

[garlonicon]

Imagine if we ever have a solar currency, then we will have to increase the block time and a bitcoin based currency will be the only one available.

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

[pooya87]

Anything that wants to be used as money needs at least sub minute, preferably sub second blocks.

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.

[BlackHatCoiner]

Bitcoin settlements when the payment becomes irreversible is ridiculously fast compared to any other monetary system that takes 10 minutes on average.

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.

[o_e_l_e_o]

Anything that wants to be used as money needs at least sub minute, preferably sub second blocks.

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.

[n0nce]

Can't we just make it quicker and reduce the rewards appropriately?

You can, P2Pool did just that, they reduced it 20 times, reaching 30 seconds per block.

Do you mean P2Pool the decentralized mininig pool? If so, i'm sure it refer to how often the "share" is updated.

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.

[kaggie]

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.

Was it by design or accident?

Arbitrary choice, it's unlikely satoshi performed research about effect block propagation on different block time.

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.

[garlonicon]

Do you mean P2Pool the decentralized mininig pool?

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.

This doesn't mean that a valid extension of the actual blockchain is found much more quickly, it just means that n'*20=n.

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

[mikeywith]

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.

[garlonicon]

Another issue you could potentially create by reducing block time intervals would be more empty blocks

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.

[o_e_l_e_o]

Also, the basic block reward is going to be zero, then empty blocks will be worthless and we will have different issues.

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.

[Wind_FURY]

Was it by design or accident?

Arbitrary choice, it's unlikely satoshi performed research about effect block propagation on different block time.

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.

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. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.

https://bitcoin.org/bitcoin.pdf

[ABCbits]

Do you mean P2Pool the decentralized mininig pool? If so, i'm sure it refer to how often the "share" is updated.

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.

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.

Arbitrary choice, it's unlikely satoshi performed research about effect block propagation on different block time.

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.

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

[Wind_FURY]

Arbitrary choice, it's unlikely satoshi performed research about effect block propagation on different block time.

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.

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

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.