Blockchain every 10 min?

[Jason Brendon]

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

Okay.Thank you for your answers. So, if i understand you right, what you mean is that there will be collisions and the collisions will be more than two. But even there will be collisions, it is not very likely to happen.

Yes, i am sure it is not likely to happen. But with quantum computers in place... i don't know if i shall worry. Sure it is not happening right now, but technology is rapidly improving..

[1714771625]

1714771625

[1714771625]

1714771625

[1714771625]

1714771625

[1714771625]

1714771625

[1714771625]

1714771625

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

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.

I knew you're nuts, but you're supposed to be trying to rebut me or something? Go ahead and spend what little Bitcoin you have in leverage and lose it.

[o_e_l_e_o]

So, if i understand you right, what you mean is that there will be collisions and the collisions will be more than two. But even there will be collisions, it is not very likely to happen.

Essentially, yes. In the same way that there are many different private keys which will all lead to the same address and therefore be able to spend the same bitcoin, there are many different inputs to SHA256 which will all give the same output. However, the chances of ever finding such a collision are so small as to be negligible to the average user. It is exponentially more likely that someone would guess all your credit card information by just punching in random numbers than they would find a collision with one of your private keys.

But with quantum computers in place... i don't know if i shall worry.

Quantum computers are not some magical device that can solve any and every problem. Quantum computers will be relatively ineffective against hash functions, and it is highly unlikely anyone would use them to try to find a hash collision in order to steal someone's bitcoins. Rather, their main threat against bitcoin would be solving the ECDLP, which would allow the reversal of a known public key in to its paired private key.

[franky1]

Yes, i am sure it is not likely to happen. But with quantum computers in place... i don't know if i shall worry. Sure it is not happening right now, but technology is rapidly improving..

dont worry about quantum so much
(note i am purposefully translating quantum logic into very dumbed down human understanding scenario just for demo purpose)

the binary algo has to follow binary rules. and as such quantum would need to show an input and a result that is acceptable to a binary system

imagine it like a sat nav
imagine one sat nav can only direct traffic in 2 directions (forward(0) and right(1))
01001001

> >> v
^       v
         v
         <

if quantum(4logic gates) had 0forward 1right 2 left 3back
it could get to destination in
33200
11020
and many other paths.. but here is the thing..binary will not understand all of these lefts2 and backs3 and wont accept it

so quantum would then need to translate the 2's and 3's into results that result in the same destination but only using 0's and 1's which is an extra task

so quantum cant use all of its capability to find all possible routes in its quantum state. it has to instead use the route method of binary where by it potentially can try multiple binary paths at once.
which is just a efficiency of 2x factor (using 4gate to perform 2 functions of binary(2gate) logic)

EG
instead of
01001001 it can get to destination in
100101 (this fails because algo would add 00 to the end to get the required acceptable bitlength, thus alters the route)
1010 (this fails because algo would add 0000 to the end to get the required acceptable bitlength, thus alters the route)

where the only other option it might find that fits the rule may be instead of
01001001  it finds 10001010

> > > v
^        v                > > > > v
          v                             v
         <                         < <

so its not so simple for quantum to just brute binary as you may think

[nullius]

Uh-oh:  Someone asked nullius a question about random numbers.

* nullius loves random numbers.

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

In haste to reply, I slightly misspoke.  A private key is simply a 256-bit number—slightly restricted in its range, because not all 256-bit numbers correspond to valid points on the secp256k1 curve.  A 256-bit number picked randomly from the uniform distribution has a negligible (about 2^-128) probability of being an invalid key.

A securely created private key effectively has slightly less than 256 bits of entropy.

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

Your question consists of two distinct parts:  The part about private keys, and the part about SHA256.

SHA256 is irrelevant to creating a Bitcoin private key, unless you yourself are choosing to feed something into SHA256 to create the key.  I strongly advise that you should not devise your own scheme for creating private keys—not when dealing with real money—not unless or until you study cryptography.

• PSA: Coders making ad hoc “random” schemes are like kids playing with matches.
• Common coin-flip fallacies
• (This and other posts in the same thread.)

Most user keys from competently written Bitcoin wallets are created according to the BIP 32 HD (Hierarchical Deterministic) wallet standard.  If you are writing your own wallet software, you should use that (and I recommend using a library that provides the appropriate functions—unless/until you learn more about the underlying primitives, and why BIP 32 puts them together the way it does).

If you feed some arbitrary input into SHA256, and use the output as a key, then you are using SHA256 as an entropy extractor.  To design such a system properly, you should understand the concept of min-entropy (as distinct from Shannon entropy).  I know that I am tossing out unfamiliar jargon thick and fast, but there is a reason for that:  These are advanced concepts that must be understood if you want to do this securely, without shooting yourself in the foot; and there is no way to summarize such a deep technical subject in a few paragraphs of a casual forum post.  I therefore provide the terms that you can look up in an appropriate reference work.

The approximate security level that many people attain when they try to roll their own private keys:

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

No, it is not a stupid question.  SHA256 is a surjection.  It accepts vastly more possible inputs (preimages) than the possible outputs (images) it can produce.  By the Pigeonhole Principle, there are many possible preimages for each hash image.

If you can find two different preimages that produce the same SHA256 image (without specifying what the image is), that is called a collision attack.  One of the security requirements for a cryptographically secure hash function is that finding a collision must be computationally infeasible, to the expected security level.  SHA256 is secure against collision attacks.  (Other previously popular hash functions, MD5 and SHA1, have been broken with collision attacks, and even chosen-prefix collisions.)

(o_e_l_e_o correctly explained this more briefly but with additional details (thank you), as I was writing and gathering links/images.)

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

I knew you're nuts, but you're supposed to be trying to rebut me or something? Go ahead and spend what little Bitcoin you have in leverage and lose it.

No, I was helpfully informing you that you are wrong, and you have no idea what you are talking about.  Now, I am also informing you that you are rude, stupid, and pitiably foolish to be arguing with me from a state of gross ignorance.

[coinerer]

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.

Yup you are definitely right. for every transcation miners need to solve a mathematical problem and everyday million of transcation had been done. that's why need a long time for complete a transcation block. it take more then 10 minutes

[mocacinno]

--snip--
Yup you are definitely right. for every transcation miners need to solve a mathematical problem and everyday million of transcation had been done. that's why need a long time for complete a transcation block. it take more then 10 minutes

It has been said in this very thread: the time between 2 blocks is NOT related to the amount of transactions in the mempool, nor the amount of transactions in the (valid) blocks (well, maybe it'll take a couple milliseconds more to relay a "full" valid block vs an "empty" one, but this isn't significant imho).
If all miners would go on strike, and start mining empty blocks (only the coinbase tx), it would still take an average of ~10 minutes between two blocks... If the average time between 2 empty blocks was > 10 minutes, the difficulty would go down on the next difficulty adjustment (and vice versa).

The average time between 2 blocks is only significantly influenced by the difficulty and the sum of the hashrate. When the hashrate changes, during the next retarget, the difficulty will be adjusted aswell (and vice versa).

[franky1]

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.

Yup you are definitely right. for every transcation miners need to solve a mathematical problem and everyday million of transcation had been done. that's why need a long time for complete a transcation block. it take more then 10 minutes

hossienmr93 had the better explanation. coinerer got it wrong on multiple parts

transactions are collated into blocks(batches of data) it doesnt matter if the block contains 1 or 2500 transactions. there is only ONE mathematical problem that is solved per block

on average a block contains about average 1700tx and there is about 144 blocks a day thus there are not millions of transactions a day.

the time of a mathematical problem solve of a block(your terminology of mining) does not correlate or causate to the amount of transactions involved in the block

[nullius]

Aside, another pet peeve of mine:  There is no such thing as “the mempool”.  There are mempools, plural.  Each independent P2P full node has its own mempool.  The purpose of the blockchain is globally to synchronize the substantive content of mempools, and to set the order of transactions in mempools authoritatively without a trusted central authority.

This is no mere quibble.  A misunderstanding of the nature and plurality of mempools causes numerous half-baked newbie ideas for “improving” Bitcoin, or “to make mining more efficient”, essentially by replacing the blockchain with an insecure global mempool (singular).  Usually, such schemes are not even fault-tolerant—let alone Byzantine fault-tolerant.

The block time has nothing to do what's going on in the mempool.

There is no direct correlation between the transactions in the mempool and the average block time.

--snip--
Yup you are definitely right. for every transcation miners need to solve a mathematical problem and everyday million of transcation had been done. that's why need a long time for complete a transcation block. it take more then 10 minutes

It has been said in this very thread: the time between 2 blocks is NOT related to the amount of transactions in the mempool, nor the amount of transactions in the (valid) blocks (well, maybe it'll take a couple milliseconds more to relay a "full" valid block vs an "empty" one, but this isn't significant imho).

Sigh.  Thanks for correcting that for the nth time.

Besides the usual problems with noisy misinformation, what concerns me most is that, as I mentioned in my prior post, POS propaganda is actively spreading the incorrect notion that more transactions = more work in POW, or that scaling the TPS rate would require more energy.

It was already a popular mistake.  It is now being amplified.

As a general observation, I think that the development forum has usually had less of this sort of nonsense because there are several regulars there with high technical competence, very abrasive personalities, and no patience for stupidity.

If all miners would go on strike, and start mining empty blocks (only the coinbase tx), it would still take an average of ~10 minutes between two blocks...

Just to elaborate:  Frequently mining empty blocks in a way that seemed intentional has been done before, probably as an attack on Bitcoin.  That was an accusation frequently leveled at Bitmain and their pools, a few years ago.  IIUC, empty blocks have sometimes been mined due to poorly-designed equipment; but I can’t speak to the veracity of that claim, as I do not have experience mining.

If the average time between 2 empty blocks was > 10 minutes, the difficulty would go down on the next difficulty adjustment (and vice versa).

The average time between 2 blocks is only significantly influenced by the difficulty and the sum of the hashrate. When the hashrate changes, during the next retarget, the difficulty will be adjusted aswell (and vice versa).

The only way we have to measure the global hashrate is to estimate it from divergence of the average block time from the expected average.  I think that many newbies imagine that there is some hashrate meter that directly measures the hashrate.  Of course, that is impossible in a decentralized system where miners can be anonymous, and the only way to know that they even exist is when blocks show up in P2P network gossip.

[Poker Player]

No, I was helpfully informing you that you are wrong, and you have no idea what you are talking about.  Now, I am also informing you that you are rude, stupid, and pitiably foolish to be arguing with me from a state of gross ignorance.

Of course, of course. I'll explain it to you so someone who thinks he's God like you can understand.

We have an OP who says he "has been into bitcoin fundamentals since 2018" and it turns out he hasn't understood something as simple as the difference between the average between blocks mined and the effective time between blocks mined.

You can make the explanation as technically complex as you want, but if he doesn't understand such a basic thing, it's best to start with the simple explanation, which is not false no matter how hard your narcissism tries.

[seoincorporation]

Great topic and great answers. As you mentioned guys, the 10 minutes isn't a constant, and sometimes we only see 2 blocks in 1 hour, but other times we see 8 blocks or more in 1 hour. So, in the long run it's 10 min.

I have a question about this topic, so, better post it here than start a new topic.

If we turn off all the miners and only leave 1 pc with cpuminer running will the 10 minutes block stay, or since the complexity is a lot bigger than the mining power the blocks will have a huge delay?

[Jason Brendon]

Yes, i am sure it is not likely to happen. But with quantum computers in place... i don't know if i shall worry. Sure it is not happening right now, but technology is rapidly improving..

dont worry about quantum so much
(note i am purposefully translating quantum logic into very dumbed down human understanding scenario just for demo purpose)

the binary algo has to follow binary rules. and as such quantum would need to show an input and a result that is acceptable to a binary system

imagine it like a sat nav
imagine one sat nav can only direct traffic in 2 directions (forward(0) and right(1))
01001001

> >> v
^       v
         v
         <

if quantum(4logic gates) had 0forward 1right 2 left 3back
it could get to destination in
33200
11020
and many other paths.. but here is the thing..binary will not understand all of these lefts2 and backs3 and wont accept it

so quantum would then need to translate the 2's and 3's into results that result in the same destination but only using 0's and 1's which is an extra task

so quantum cant use all of its capability to find all possible routes in its quantum state. it has to instead use the route method of binary where by it potentially can try multiple binary paths at once.
which is just a efficiency of 2x factor (using 4gate to perform 2 functions of binary(2gate) logic)

EG
instead of
01001001 it can get to destination in
100101 (this fails because algo would add 00 to the end to get the required acceptable bitlength, thus alters the route)
1010 (this fails because algo would add 0000 to the end to get the required acceptable bitlength, thus alters the route)

where the only other option it might find that fits the rule may be instead of
01001001  it finds 10001010

> > > v
^        v                > > > > v
          v                             v
         <                         < <

so its not so simple for quantum to just brute binary as you may think

Thanks man. That's very helpful.

[o_e_l_e_o]

If we turn off all the miners and only leave 1 pc with cpuminer running will the 10 minutes block stay, or since the complexity is a lot bigger than the mining power the blocks will have a huge delay?

A huge delay.

Keeping the average block time close to 10 minutes when the hashrate is constantly changing is done so by changing the target number. The miners must find a solution which is below the current target. The target is recalculated every 2016 blocks, and so the target we are working to at the moment is based on the current hashrate of approximately 200 EH/s.

So, if we suddenly lose 99% of the hashrate, for example, then the 1% which remains will be stuck with the current target until the next recalculation, which will be at most 2016 blocks away. Since the target will be based on 200 EH/s, and we would only be mining with 2 EH/s, then blocks will take significantly longer. Once we do recalculate, then the target would drop by a factor of four (which is the limit of how much the target can change at once), meaning the next 2016 blocks would be faster, but still nowhere near a 10 minute average. This would repeat until things balanced out again.

In your example of leaving only a single CPU miner running, then the discrepancy between hashrate and target would be so ridiculously large that either nothing would happen until other miners came back online, or bitcoin would need to fork to readjust the target or mining algorithm.

[cr1776]

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.

Random luck or lack thereof.  The more hashes that are being checked, the higher the chance you will "solve" a block.  Think about if it was just you mining on a CPU, you might find a block in 1 second or in 1 hour.  It just depends on dumb luck.  The same goes when you scale it up so that there are many people all mining simultaneously.  As above, roughly every two weeks, the difficulty is adjusted so that the 10 minute average is expected for the next two week period (as measured in blocks).

[mocacinno]

--snip--
I have a question about this topic, so, better post it here than start a new topic.

If we turn off all the miners and only leave 1 pc with cpuminer running will the 10 minutes block stay, or since the complexity is a lot bigger than the mining power the blocks will have a huge delay?

if you'd do this, the difficulty would still be sky-high, and the cpu miner would probably take hundreds of years (if not more) to solve a single block... Since a diff retarget only happens every 2016 blocks (and if i'm remembering correctly, the diff retarget is also limited), it would take thousands of years untill the time between 2 blocks would be 10 minutes again.

I'm pretty sure that if this would ever happen, the dev's would probably change the code and a hard fork would occur... since no blocks = no confirmations = risk of double spending...

[hosseinimr93]

(and if i'm remembering correctly, the diff retarget is also limited),

You do remember correctly.
The difficulty we will have after the adjustment can't be lower than 25% of the the difficulty we had before the adjustment.

[Jason Brendon]

Uh-oh:  Someone asked nullius a question about random numbers.

* nullius loves random numbers.

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

In haste to reply, I slightly misspoke.  A private key is simply a 256-bit number—slightly restricted in its range, because not all 256-bit numbers correspond to valid points on the secp256k1 curve.  A 256-bit number picked randomly from the uniform distribution has a negligible (about 2^-128) probability of being an invalid key.

A securely created private key effectively has slightly less than 256 bits of entropy.

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

Your question consists of two distinct parts:  The part about private keys, and the part about SHA256.

SHA256 is irrelevant to creating a Bitcoin private key, unless you yourself are choosing to feed something into SHA256 to create the key.  I strongly advise that you should not devise your own scheme for creating private keys—not when dealing with real money—not unless or until you study cryptography.

• PSA: Coders making ad hoc “random” schemes are like kids playing with matches.
• Common coin-flip fallacies
• (This and other posts in the same thread.)

Most user keys from competently written Bitcoin wallets are created according to the BIP 32 HD (Hierarchical Deterministic) wallet standard.  If you are writing your own wallet software, you should use that (and I recommend using a library that provides the appropriate functions—unless/until you learn more about the underlying primitives, and why BIP 32 puts them together the way it does).

If you feed some arbitrary input into SHA256, and use the output as a key, then you are using SHA256 as an entropy extractor.  To design such a system properly, you should understand the concept of min-entropy (as distinct from Shannon entropy).  I know that I am tossing out unfamiliar jargon thick and fast, but there is a reason for that:  These are advanced concepts that must be understood if you want to do this securely, without shooting yourself in the foot; and there is no way to summarize such a deep technical subject in a few paragraphs of a casual forum post.  I therefore provide the terms that you can look up in an appropriate reference work.

The approximate security level that many people attain when they try to roll their own private keys:

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

No, it is not a stupid question.  SHA256 is a surjection.  It accepts vastly more possible inputs (preimages) than the possible outputs (images) it can produce.  By the Pigeonhole Principle, there are many possible preimages for each hash image.

If you can find two different preimages that produce the same SHA256 image (without specifying what the image is), that is called a collision attack.  One of the security requirements for a cryptographically secure hash function is that finding a collision must be computationally infeasible, to the expected security level.  SHA256 is secure against collision attacks.  (Other previously popular hash functions, MD5 and SHA1, have been broken with collision attacks, and even chosen-prefix collisions.)

(o_e_l_e_o correctly explained this more briefly but with additional details (thank you), as I was writing and gathering links/images.)

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

I knew you're nuts, but you're supposed to be trying to rebut me or something? Go ahead and spend what little Bitcoin you have in leverage and lose it.

No, I was helpfully informing you that you are wrong, and you have no idea what you are talking about.  Now, I am also informing you that you are rude, stupid, and pitiably foolish to be arguing with me from a state of gross ignorance.

Thank you so much for the constant long-form replies. I think because of you guys, more people are starting to understand bitcoin and especially cryptography.

Yes, I am quite into this kind of topic, especially how one can generate entropy, how the whole BIP32 thing, and more.
I also did my little research so I don't shoot noobie questions.(at least not that noobie).

So, basically, I don't trust any software/hardware wallet that generates keys for me. At least, i have to look into their codes but at the end of the day, I still do not feel comfortable with them. So the way I do it is I take iancole HTML page, and I feed it with my entropy(not arbitrary entropy).  meanwhile, I have the bip32 /bip39 python code alongside so that i can cross-check. When the xprvs turn out to be the same, i can be relief, I can go ahead funding it at least nothing can go too wrong from there.

The initial entropy comes from:
1. dice rolls (99 rolls make 256bits, I roll more than just 99, I do 200 rolls let's say, it is still going to be SHA256ed into 256 bits, so here i am wondering if doing more rolls helps? )
2. flip coins (256times, people say flipping coins is not secure as dice rolls? )
3. buy hexadecimal 16-face dice and roll it .
4. Use a password manager like keepass to generate HEX, then feed it to ian39 html for my seed.
5. take images and convert into entropy(any risks there? my gut feeling tells me there are unseen risks there, maybe i am wrong.)

[franky1]

I have a question about this topic, so, better post it here than start a new topic.

If we turn off all the miners and only leave 1 pc with cpuminer running will the 10 minutes block stay, or since the complexity is a lot bigger than the mining power the blocks will have a huge delay?

asics perform the task of mining currently. they can do the current bitcoin hashing mechanism faster then CPU . if bitcoin hash mechanism stayed the same. but it was just a boycott of asics. then there would still logically be someone with an asic that ignores the boycott. so based on there being just 1 asic running

1 asic is about between 110terrahash and near on 300terrahash, where there are about 1.5m asics to get to
current network hash which is about 220 exa

(im purposefully using the easy human understandable hashrate number for easy math display, rather then the actual difficulty formulae number, purely for easy demo of timescales.)

so going from 220E starting point... in 1 fortnight can only drop 75% max difficulty change
so
fortnight 0   220,000,000 T
fortnight 1   55,000,000 T
fortnight 2   13,750,000 T
fortnight 3   3,437,500 T
fortnight 4   859,375 T
fortnight 5   214,844 T
fortnight 6   53,711 T
fortnight 7   13,428 T
fortnight 8   3,357 T
fortnight 9   839 T
fortnight 10   210 T

so ~20 weeks or 5 months to get down to reasonable level of "normality" with a single miner.
(this not necessarily mean no blocks for 5 months as that solo miner might get lucky and make a couple inbetween)
(this not necessarily mean no blocks for 5 months as reality is not all miners switch off at the exact same block/minute so extra blocks will be made in between)

but that said. unless the code is broke where only one miner can run.. the time can be ALOT longer.. like never adjust down..
however is some miners can work you will find as the difficulty drops, it then makes more opportunity for competitors to jump back in so as said unless the protocol code is broke. others would join back in before it got down to 1 miner

as for CPU mining which is about 20mhash which is like 10m to get to 210thash
fortnight 10   210,000,000 M
fortnight 11   52,452,087 M
fortnight 12   13,113,022 M
fortnight 13   3,278,255 M
fortnight 14   819,564 M
fortnight 15   204,891 M
fortnight 16   51,223 M
fortnight 17   12,806 M
fortnight 18   3,201 M
fortnight 19   800 M
fortnight 20   200 M
fortnight 21   50 M
fortnight 22   13 M

so from starting point down to CPU solo mining. would take 44 weeks or ~10 months.
but again. as the difficulty drops competitors would jump in before that bottom line. thus it wont reach that stage

[mocacinno]

It's morning in my country... So i'm looking at seoincorporation's question with a fresh pair of eyes...

The question at hand:

--snip--

If we turn off all the miners and only leave 1 pc with cpuminer running will the 10 minutes block stay, or since the complexity is a lot bigger than the mining power the blocks will have a huge delay?

So, let's look at the formula from the bitcoin wiki... How many seconds does it take (on AVERAGE) to find a block at a certain diff with a certain amount of hashrate..

How soon might I expect to generate a block?
(The eternal question.)

The average time to find a block can be approximated by calculating:

time = difficulty * 2**32 / hashrate

source: https://en.bitcoin.it/wiki/Difficulty

hosseinimr93 was correct (and so was my memory)
https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L56

So the max diff retarget is *4 or /4

Now, let's assume this only cpu miner is having great hardware:
https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison#CPUs.2FAPUs
The "best" i could find is cpu's running @ 115 Mh/s.

Now, for the sake of argument, let's just assume we're currently only one block away from a retarget (2015 blocks mined @ the moment all asic's turn off).

The current difficulty is 27.693T (https://www.blockchain.com/charts/difficulty)

In order to reach the next retarget, only one block is necessary... How many seconds would it take?
seconds = 27.693.000.000.000 * 2**32 / 115.000.000 = 1.034.265.472.418.504 seconds
1.034.265.472.418.504 seconds = 32.796.342 years (on average).... Yup, that number is correct, 32 million years

After this point, the diff would "drop" to 6,9T
seconds = 6,923.250.000.000 * 2**32 / 115.000.000 = 258.566.368.104.626 seconds (1/4th of the previous calculation)
258.566.368.104.626 seconds = 8.199.085 years (on average)
BUT, you'd need 2016 blocks before reaching the next retarget, so on average it would take 16.529.356.865 years before reaching the second retarget... Once again... Number is correct, 16.5 Billion years

So... Given the fact that the cpu miner had "good" hardware, and was only one block away from the next retarget.. How long would it take for blocks to have an average time between 2 blocks of ~10 minutes?
First retarget : 32 million years
Second retarget: 16 billion years
Thirth retarget: 4 billion years
Fourth retarget: 1 billion years
Fifth retarget: 258 million years
Sixth retarget: 64 million years
Seventh retarget: 16 million years
eight retarget: 4 million years
ninth retarget: 1 million years
tenth retarget: 252 thousand years
eleventh retarget: 63 thousand years
twelfth retarget: 15 thousand years
thirthteenth retarget: 4 thousand years
fourtheenth retarget: 985 years
fifteenth retarget: 246 years
sixteent retarget: 61 years
seventeenth retarget: 15 years
eighteenth retarget: 3 years
ninteenth retarget: 1 year
twentyth retarget: 3 months
twentyfirst retarget: 22 days
twentysecond retarget: 5 days
twentythirth retarget: 82 hours
twentyfourth retarget: 20 hours
twentyfifth retarget: 5 hours
twetysixth retarget: 77 minutes
twentyseventh retarget: 19 minutes
twentyeight retarget: 10 minutes

Well... The answer is > 21 billion years (on average, if people wouldn't cheat nor create a hard fork to a different algo or changing how retargets work or something)...
But like i said: if this would happen, bitcoin would be dead... on average 32 million years before the first block is found...
So, people could probably edit the sourcecode and hardcode a diff reset @ the next block height or something, that way everything would "normalise", but it would create a hard fork...

[o_e_l_e_o]

I already said all this above:

Once we do recalculate, then the target would drop by a factor of four (which is the limit of how much the target can change at once)
...
either nothing would happen until other miners came back online, or bitcoin would need to fork to readjust the target or mining algorithm.

The initial entropy comes from:
1. dice rolls (99 rolls make 256bits, I roll more than just 99, I do 200 rolls let's say, it is still going to be SHA256ed into 256 bits, so here i am wondering if doing more rolls helps? )
2. flip coins (256times, people say flipping coins is not secure as dice rolls? )
3. buy hexadecimal 16-face dice and roll it .
4. Use a password manager like keepass to generate HEX, then feed it to ian39 html for my seed.
5. take images and convert into entropy(any risks there? my gut feeling tells me there are unseen risks there, maybe i am wrong.)

The only one of those five options I would ever use is number 2 - flipping a fair coin 256 times. You should either run statistical tests to ensure your coin is fair first, or you should use something like Von Neumann's debiasing algorithm to remove any bias in the coin.

For 1 and 3 - When you roll dice, the chance for bias is much larger, and the methods for reliably detecting that bias are much more complicated and take much longer. You also have the problem of extracting the necessary randomness from your list of dice rolls, as nullius alluded to above, which is neither a trivial nor a straightforward process and not something that you should just "have a go at" or feed your list of rolls in to SHA256 and assume the output is adequate.

For 4 - If you don't trust an auditable and verifiable open source wallet which is generating your entropy in a cryptographically secure way by using /dev/urandom, then why would you trust a password manager to do any better?

For 5 - Same randomness extraction risk as 1 and 3, with the added flaw being you are starting with entirely non-random data in the form of an image.

I also note you mentioned using Ian Coleman's site to turn entropy in to private keys. I hope you are doing this on a permanently airgapped computer!