Blockchain every 10 min?

[Jason Brendon]

Hi bitcoiners,
I've been into BTC fundamentals since 2018 but it's actually silly to ask such a noobie question like this.
So from my personal BTC explorer, i realized that sometimes a blockchain isn't really 10 minutes or anything close. I often experienced blockchains in-betweens taking way longer than 10 minutes say 30 minutes or 25 minutes.
Why was that? Isn't every blockchain supposed to be 10minutes(even when there is no transction at all).
Thank you.

[1715500081]

1715500081

[1715500081]

1715500081

[1715500081]

1715500081

[1715500081]

1715500081

[dansus021]

i am also curios about this one.
but

Isn't every blockchain supposed to be 10minutes(even when there is no transction at all).

as long as i know the miner will keep finding block even tho there is no transaction in it. but nowadays btc block always filled by the transaction

[mocacinno]

Mining is going trough a series of block headers really, really fast while changing small bits of data inside these headers each time.
The header gets hashes with the sha256d algorithm.

If the miner finds a sha256d hash of his header that is under the current target, he has "solved" a block.

The difficulty is adjusted every 2016 blocks to make sure the AVERAGE time between 2 blocks is 10 minutes. So, in reality, every ~2 ish weeks, the netwerk changes the difficulty to make sure the average stays close to 10 minutes (a rising difficulty decreases the target, making it harder to solve a block, increasing the average time... and vice versa).

So, basically, there is no rule to make sure the time between 2 blocks is 10 minutes. The network just looks at the last 2 weeks (every 2 weeks) and changes how hard it is to solve a block, so that the average time between two blocks is 10 minutes... It does not care if at one point it took 2 hours to solve a block, as long as the average time is 10 minutes the diff doesn't change.
Do realise that by this mechanism, in times of months and months of ever increasing hashrate, the average time between 2 blocks will probably be a little less than 10 minutes (since the diff is only adjusted once every 2016 blocks), and in times of ever decreasing hashrate, the average time between 2 blocks will probably a little more than 10 minutes over those months.

[Jason Brendon]

Hey thanks for the reply.
So, what to explain a block after its prior 10-min block is a 38-minute block? Is it a sudden increase of difficulty?

I thought this was so obvious until i googled it and found nothing.

[hosseinimr93]

So, what to explain a block after its prior 10-min block is a 38-minute block? Is it a sudden increase of difficulty?

No.
For mining a block, miners need to solve a mathematical problem which is called proof-of work problem.
This problem is solved through brute-force method. This means that the problem is solved by checking all possible answers. It's possible that the problem is solved in a few seconds. It's also possible that it takes more than an hour until a miner finds the solution.

[Jason Brendon]

beautiful answer. Thank you. Now I understand it.
But brute force, how much entropy are miners brute forcing into?
with such powerful hash rate, will it be used to brute force against our private keys? I guess the answer is no. but since the power of hashrate increases, all private keys will be brute forced. I certainly don't mean now or anything close. But one day.. with quantum computer..

[hosseinimr93]

But brute force, how much entropy are miners brute forcing into?

There is no exact number.
As already mentioned, difficulty changes every 2016 blocks, so the average block time stay close to 10 minutes.
If the average block time is more than 10 minutes, the problem becomes easier and if the average block is less than 10 minutes, the problem becomes more difficult.  

with such powerful hash rate, will it be used to brute force against our private keys? I guess the answer is no.

That's not possible.
Each private key provides 128 bits of entropy.  

[un_rank]

So, what to explain a block after its prior 10-min block is a 38-minute block? Is it a sudden increase of difficulty?

Reading the reply of mocacinno, the probability of when a miner finds the next block depends on luck and the strength of their computers. They keep going through the block headers until they find the correct hash. Could take 10 mins or 30. The difficulty of these task is then adjusted every 2016 blocks.

with such powerful hash rate, will it be used to brute force against our private keys? I guess the answer is no. but since the power of hashrate increases, all private keys will be brute forced. I certainly don't mean now or anything close. But one day.. with quantum computer..

Breaking the entropy of a private key is a very difficult thing to do now, that it is almost impossible as the creation is completely random with high entropy. If quantum computers can break that encryption, then bitcoin would be one of many systems affected, since it is currently more secure than others.
Maybe there would be a security update when that situation is at hand.

[nullius]

Mr. Brendon, you asked a smart question.

The saying that a Bitcoin block happens “every 10 minutes” or “about every 10 minutes” is misinformation.  It is a form of classic Gambler’s Fallacy.  It is endlessly repeated by people who should know better—even after they have been corrected.  I know of only two or three other people who have actively tried to correct this fallacy in the Bitcoin community—and all of them have sometimes been accused of being my alts (including Lauda, lolz).  Thus, I must thank you for inquiring based on your own empirical observations, instead of mindlessly believing and repeating what everyone else says.  (Cf. the Asch conformity experiment.)

So from my personal BTC explorer, i realized that sometimes a blockchain isn't really 10 minutes or anything close.

Indeed not!  To understand this will require some maths.  For an initial explanation, I will not try to delve deeply into that.

The Bitcoin mining process, already described above by mocacinno, is modelled as a Poisson process.  This statistical process is memoryless:  The expected time to the next block does not start from the last block, but from any particular moment in time.  The expected arrival time of the next block follows the exponential distribution, with λ = 0.1 if you are working in units of minutes.

Accordingly, the average time to the next block is 10 minutes; and about 63.2% of blocks actually arrive within 10 minutes.  However, the exponential distribution has a curve which defies human intuition:  It is frontloaded with a high density of fast arrival times, followed by a long tail of slow arrival times.  That long tail includes those slow-seeming blocks which you observed; those drag the average up to 10 minutes.

More useful to practical everyday life are median and the quartiles.

The median expected time to the next block is about 6 minutes and 56 seconds.  An equivalent statement:  At any particular moment—at the moment when you read these words—you can expect a block within 6:56 with 50% probability.  Of course, that means a 50% chance that the next block will take longer than 6:56 to arrive.

The next block has a 25% chance of arriving within 2:53, and a 25% chance of taking longer than 13:52 (the long tail).

Incidentally, many games of chance, including classic Bitcoin dice games, can be usefully modelled according to the same process and the same probability distribution for the arrival of wins.  (Pedants may argue that that’s a discrete process, whereas the exponential distribution is continuous; but for the purpose of this discussion, that is not relevant.)  Studying the mathematics of Bitcoin block arrival times can help give an understanding of why you can’t beat the house—and on the flipside, studying the mathematics of gambling will give a firm theoretical grasp of why Bitcoin block arrivals have the behaviour that you observe empirically.

Gambler’s Fallacy is ever popular—as is social conformity in the repetition of obviously wrong statements.  Thus, I am pessimistic about my prospect for fighting off the misinformation that “Bitcoin blocks take about 10 minutes”.

[Charles-Tim]

So from my personal BTC explorer, i realized that sometimes a blockchain isn't really 10 minutes or anything close. I often experienced blockchains in-betweens taking way longer than 10 minutes say 30 minutes or 25 minutes.

That has been well explained above, and maybe you have not be noticing much about the time the transactions you are broadcasting take before they are confirmed, or maybe you can try to make use of the explorers or sites like https://mempool.space to check when each block are mined for long time to see the difference in time transactions are confirmed.

Transaction can take just less than 2 minutes before it is confirmed, it can be confirmed any minutes the transaction is broadcasted, it can even take 30 minutes.

That is why mining difficulty is adjusted every 2016 blocks. It is like that because if more miners join the network, the mining hashrate increases, and this will lead to transactions getting confirmed more below 10 minutes. But if miners stop their miners from working and are not mining, the hashrate will reduce and transactions will be getting confirmed more above 10 minutes.

Which means that transaction confirmation can take less than 10 minutes or more than 10 minutes, but will be almost 10 minutes on average if the average of the total transactions are calculated.

[Jason Brendon]

Mr. Brendon, you asked a smart question.

The saying that a Bitcoin block happens “every 10 minutes” or “about every 10 minutes” is misinformation.  It is a form of classic Gambler’s Fallacy.  It is endlessly repeated by people who should know better—even after they have been corrected.  I know of only two or three other people who have actively tried to correct this fallacy in the Bitcoin community—and all of them have sometimes been accused of being my alts (including Lauda, lolz).  Thus, I must thank you for inquiring based on your own empirical observations, instead of mindlessly believing and repeating what everyone else says.  (Cf. the Asch conformity experiment.)

So from my personal BTC explorer, i realized that sometimes a blockchain isn't really 10 minutes or anything close.

Indeed not!  To understand this will require some maths.  For an initial explanation, I will not try to delve deeply into that.

The Bitcoin mining process, already described above by mocacinno, is modelled as a Poisson process.  This statistical process is memoryless:  The expected time to the next block does not start from the last block, but from any particular moment in time.  The expected arrival time of the next block follows the exponential distribution, with λ = 0.1 if you are working in units of minutes.

Accordingly, the average time to the next block is 10 minutes; and about 63.2% of blocks actually arrive within 10 minutes.  However, the exponential distribution has a curve which defies human intuition:  It is frontloaded with a high density of fast arrival times, followed by a long tail of slow arrival times.  That long tail includes those slow-seeming blocks which you observed; those drag the average up to 10 minutes.

More useful to practical everyday life are median and the quartiles.

The median expected time to the next block is about 6 minutes and 56 seconds.  An equivalent statement:  At any particular moment—at the moment when you read these words—you can expect a block within 6:56 with 50% probability.  Of course, that means a 50% chance that the next block will take longer than 6:56 to arrive.

The next block has a 25% chance of arriving within 2:53, and a 25% chance of taking longer than 13:52 (the long tail).

Incidentally, many games of chance, including classic Bitcoin dice games, can be usefully modelled according to the same process and the same probability distribution for the arrival of wins.  (Pedants may argue that that’s a discrete process, whereas the exponential distribution is continuous; but for the purpose of this discussion, that is not relevant.)  Studying the mathematics of Bitcoin block arrival times can help give an understanding of why you can’t beat the house—and on the flipside, studying the mathematics of gambling will give a firm theoretical grasp of why Bitcoin block arrivals have the behaviour that you observe empirically.

Gambler’s Fallacy is ever popular—as is social conformity in the repetition of obviously wrong statements.  Thus, I am pessimistic about my prospect for fighting off the misinformation that “Bitcoin blocks take about 10 minutes”.

Thank you sir for the details. That's very well explained in-depth. Yes, we must go into details so that we are not blindly following the stream. So, anothrr point crossed off my list.

[OcTradism]

Average bock time is 10 minutes but it can be longer or shorter depends on hashrate, waiting transaction in mempool and fee rate of waiting transactions.

https://bitinfocharts.com/comparison/bitcoin-confirmationtime.html

You can see the average line in the chart should be around 10 minutes. On 27 June 2021, it jumped to about 25 minutes but on average, block time still is 10 minutes.

[hosseinimr93]

Average bock time is 10 minutes but it can be longer or shorter depends on hashrate, waiting transaction in mempool and fee rate of waiting transactions.

The block time has nothing to do what's going on in the mempool.
Miners solve the proof of work problem to mine a block and the time the problem takes to be solved doesn't depend on the number of transactions in the mempool and the fee paid for them.

[nullius]

with such powerful hash rate, will it be used to brute force against our private keys? I guess the answer is no. but since the power of hashrate increases, all private keys will be brute forced. I certainly don't mean now or anything close.

There are two reasons why not:

• The astronomically huge amount of computation required to break a private key is still many orders of magnitude above the amount of computation that the Bitcoin network can perform.  (See below for a brief description of how much computation would actually be required in various scenarios.)
• “ASIC” stands for ‘Application-Specific Integrated Circuit’.  “Application-Specific” means just that:  The ASICs used for Bitcoin mining have the mining algorithm baked into the hardware.  They cannot be repurposed for anything else.

with such powerful hash rate, will it be used to brute force against our private keys? I guess the answer is no.

That's not possible.
Each private key provides 128 bits of entropy.

That is flatly incorrect.  A secp256k1 private key has slightly less than 256 bits of entropy.  But that is irrelevant:

• Most public keys needed to spend funds are not publicly revealed.  For P2PKH and P2WPKH addresses that have not been reused, all that is publicly known is a 160-bit hash of the public key—not the public key itself.  Thus, for those, the search space for bruteforce is 2¹⁶⁰.
• When a public key is known, an attacker would use an ECDLP solver, not bruteforce.  Bitcoin’s public-key security level is 128 bits, even though the private keys themselves are 256-bit numbers (slightly restricted within that range).  No attacker would use brute force.

Asking questions is good; giving bad answers is bad.  People need to stop tossing out nonsense that is like the blind leading the blind.

But one day.. with quantum computer..

If quantum computers can break that encryption, then bitcoin would be one of many systems affected, since it is currently more secure than others.
Maybe there would be a security update when that situation is at hand.

A quantum computer could solve the ECDLP using Shor’s Algorithm.

Bitcoin’s public keys are used for digital signatures, not encryption.

That is why mining difficulty is adjusted every 2016 blocks. It is like that because if more miners join the network, the mining hashrate increases, and this will lead to transactions getting confirmed more below 10 minutes. But if miners stop their miners from working and are not mining, the hashrate will reduce and transactions will be getting confirmed more above 10 minutes.

Hashrate variance usually has much less effect on what users observe than the variance that is statistically expected on the exponential distribution.

I suggest that you reread my post immediately prior to yours, and stop fixating on the 10-minute number.  The 10-minute number is relevant to difficulty retargeting, over an average of 2016 blocks.  It is not a useful predictor of what users actually want to know:  “When will my transaction confirm?”

Average bock time is 10 minutes but it can be longer or shorter depends on hashrate, waiting transaction in mempool and fee rate of waiting transactions.

The block time has nothing to do what's going on in the mempool.
Miners solve the proof of work problem to mine a block and the time the problem takes to be solved doesn't depend on the number of transactions in the mempool and the fee paid for them.

Thanks for correcting that.  (See what I meant about nonsense?)

It is especially important for people to understand this, because anti-POW “switch to POS” propaganda often depends on misinformation about the effect of transaction demand on the mining process.  You are absolutely correct here:  It has no effect.

[Poker Player]

Average bock time is 10 minutes but it can be longer or shorter depends on hashrate...

I believe this is the easiest true explanation to understand that can be given. Just because something happens on average every 10 minutes does not mean that it has to happen every 10 minutes. I think it is not difficult to understand this.

[nullius]

Average bock time is 10 minutes but it can be longer or shorter depends on hashrate...

I believe this is the easiest true explanation to understand that can be given. Just because something happens on average every 10 minutes does not mean that it has to happen every 10 minutes. I think it is not difficult to understand this.

It is not a matter of what you “believe”; and it is not the true explanation.  I provided the factually correct explanation above.

Just because something happens on average every 10 minutes in an exponential distribution does not mean that it will happen every 10 minutes:  To the contrary, the majority of times between blocks are significantly different than 10 minutes.  Indeed, less than 8% of blocks take between 9 minutes and 11 minutes.  This is mathematically expected, and you may confirm it empirically.

[o_e_l_e_o]

It is like that because if more miners join the network, the mining hashrate increases, and this will lead to transactions getting confirmed more below 10 minutes. But if miners stop their miners from working and are not mining, the hashrate will reduce and transactions will be getting confirmed more above 10 minutes.

This statement is misleading. There is no direct correlation between the transactions in the mempool and the average block time. It would be entirely possible for the average block time to be 12 minutes with an empty mempool resulting in every transaction getting in to the next block and getting fairly rapidly confirmed, and equally it would be entirely possible for the average block time to be 8 minutes with a packed mempool and the majority of transactions waiting several hours to be confirmed.

Which means that transaction confirmation can take less than 10 minutes or more than 10 minutes, but will be almost 10 minutes on average if the average of the total transactions are calculated.

This is not accurate either. If the mempool is full, then the average transaction time absolutely won't be 10 minutes. The average block time might be 10 minutes, but if ~2,000 transactions from a pool of 100,000 are included in each block, then the average confirmation time will be much longer than 10 minutes.

[Jason Brendon]

That is flatly incorrect.  A secp256k1 private key has slightly less than 256 bits of entropy.  But that is irrelevant:

If quantum computers can break that encryption, then bitcoin would be one of many systems affected, since it is currently more secure than others.
Maybe there would be a security update when that situation is at hand.

Hi sir, since this post is about blockchain, asking something related to entropy might be off-topic. Nevertheless..
So, the private key in BTC has a maximum of 256 bits of entropy. No matter how complex the entropy I am putting in in the first place, it will end up producing me a root key with 256 bits(even if I was initially putting in HEX in 1000-bit entropy or 10000 bit). Because in the end, after SHA256, it becomes 256bits..

So, my question is:
Will there be two different input producing the same hash result? (hypothetically, a 200-bit input entropy produces the same hash result of 20000bit...)

Maybe that's a stupid question to ask..

[o_e_l_e_o]

Will there be two different input producing the same hash result? (hypothetically, a 200-bit input entropy produces the same hash result of 20000bit...)

If you are generating private keys by using SHA256 on different inputs, then yes. Indeed, there will be many more than two inputs which will result in the same output.

For SHA256, you must append to the end of your input the length of that input expressed as a 64 bit number. This places an upper bound on the length of the input, which will be 2⁶⁴ - 1 bits. For reference, this means that any data up to approximately 2 exabytes (2 million terabytes) in size could be used as in input to SHA256, if you had the hardware capable of processing it. Given this, and given that we know that SHA256 will always produce a 256 bit output, then it is easy to see that there will be many billions of inputs which must map to the same output.

There are no known collisions for SHA256, however. If you manage to find two different inputs which hash to the same output, then there is a 0.27634251 BTC bounty you can claim as a reward:
REWARD offered for hash collisions for SHA1, SHA256, RIPEMD160 and other
https://mempool.space/address/35Snmmy3uhaer2gTboc81ayCip4m9DT4ko

[franky1]

for the private->public key question:
though public key results in a 256bit number that then hash to a 160bit address
yes there can be collisions where 2 different 256bit public keys can result in the same 160bit address. though the odds are massively unlikely because there are more possible public keys than humanly able to count even with fast computers and thousands of years to do it by passing the project down to your descendants

as for the entropy at the private key side, the private key has actually alot less entropy, where most people are limited to this lower range due to the feature they chose as their method of storing/creating/having a private key.

take most wallets that use the 12 word 'seed'
that word seed translates to a binary length of under 132bit into a public key
meaning all users of seeds generate a private key of entropy that is not 256bit input but a number within a 132bit range

to explain in more detail
each word represents 11bits. 12 words= 128bits
a calculation of that total seed then adds on a checksum of 4bits to get to 132bit
however the 4bit checksum is not random, its a result of the 128bit.
meaning if 2 people chose the same 128bit of words they all would get the same 4 bit result. thus the 4bits do not add any extra 'entropy'
meaning actual entropy of seeds of users that use seeds is 128bit
(340,282,366,920,938,000,000,000,000,000,000,000,000) possible different keypairs within a much larger set of possible keypairs

though this number is still huge to be deemed collision safe