Bitcoin Forum

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.

i am also curios about this one.
but 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

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.

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

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.

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

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.  


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

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

Mr. Brendon, you asked a smart question. (http://www.catb.org/esr/faqs/smart-questions.html)

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 (https://bitcointalk.org/index.php?topic=5235962.msg54166117#msg54166117), 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.)


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

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.

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.

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.

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.

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.

---

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, (https://bitcointalk.org/index.php?topic=5244940.0) not bruteforce.  Bitcoin’s public-key security level is 128 bits, (https://bitcointalk.org/index.php?topic=2859033.0) even though the private keys themselves are 256-bit numbers (slightly restricted within that range).  No attacker would use brute force. (https://bitcointalk.org/index.php?topic=178336.msg60666035#msg60666035)

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

---

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

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

---

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?”

---

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.

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.

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.

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.

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

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://bitcointalk.org/index.php?topic=293382.0)
https://mempool.space/address/35Snmmy3uhaer2gTboc81ayCip4m9DT4ko

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

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

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.

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.

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.

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

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

https://assets.amuniversal.com/321a39e06d6401301d80001dd8b71c47 (https://dilbert.com/strip/2001-10-25)

/me loves random numbers.


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 (https://en.bitcoin.it/wiki/Secp256k1).  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.


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. (https://bitcointalk.org/index.php?topic=5326468.0)
• Common coin-flip fallacies (https://bitcointalk.org/index.php?topic=5280670.msg55400498#msg55400498)
• (This and other posts in the same thread.) (https://bitcointalk.org/index.php?topic=2850720.msg29274125#msg29274125)

Most user keys from competently written Bitcoin wallets are created according to the BIP 32 HD (Hierarchical Deterministic) wallet standard (https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki).  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:
https://imgs.xkcd.com/comics/random_number.png (https://xkcd.com/221/)


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 (https://bitcointalk.org/index.php?topic=2534968.msg25860229#msg25860229), 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 (https://www.win.tue.nl/hashclash/rogue-ca/) and SHA1 (https://shattered.io/), 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.)

---

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.

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

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 (https://www.blockchain.com/charts/n-transactions-per-block) 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

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.


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.


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.


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.

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.

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?

Thanks man. That's very helpful.

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.

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

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

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.

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

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

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

The question at hand:


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

I already said all this above:

---

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!

Yes, you said well. I guess I'll want to input entropy from difference sources to mitigate the risks.
for example, I let open-sourced wallet generate entropy and on top of that i'll input some of my genreated entropy here and there.
Together, i make a combination of entropy to mitigate a single point of failure.

You’re welcome.  Everyone starts somewhere; what matters is intelligence and a desire to learn, either alone being necessary but insufficient.  Knowing the limits of one’s own knowledge is key—for instance, I got into crypto via PGP, AC2, etc. (Cypherpunk stuff) in the 90s, and I know that I am still not a Real Cryptographer(TM).  I do know enough not to shoot myself in the foot when using applied cryptography, and when doing programming that uses cryptographic primitives designed and implemented by cryptographers.

Unfortunately, your approach to “entropy” is more or less a collection of many popular flavours of fallacious thinking on that topic.  You seem to be the type who earnestly wants to learn; and it is a subject about which I have been wanting to write more, to gather resources for those who have these types of questions.

I have spent thus far over two hours drafting a reply, and gathering links/useful quotes; I am out of time for that now.  It is diverging quite far from your original topic here; so whenever I finish that, I may move my response to another thread, and link to it from here.

Till later...

(Meanwhile:  What o_e_l_e_o said! (https://bitcointalk.org/index.php?topic=5408292.msg60673404#msg60673404)  He replied as I was writing a long response, then moving it to a new file and prepending this note.  His advice on this topic is sound, and it will save you from shooting yourself in the foot.)

---

I have been intending to write more about the following, due to my involvement with an altcoin that has already effectively burnt its miners’ businesses with a plan to switch to POS.  As a Bitcoiner, I am horrified by that.  And I am keenly interested in this discussion; let’s compare notes and observations:


In the Fork Wars, as I recall, the Bcashers threatened that they would use this to kill Bitcoin’s mainnet, and force everyone to switch from BTC to BCH.  They called it “the flippening”.  On 12 November 2017, they actually tried it.

Pump the difficulty up, then suddenly withdraw hashrate (to Jihan’s pet chain), and wait for remaining miners to give up struggling towards the next retarget as users abandoned unusable BTC.  That was the openly stated, publicly proclaimed attack plan of “the flippening”.

What they actually achieved:  Bitcoin suffered some moderately degraded performance for about a day or so.  Then, everything went back to normal.

Insofar as I could see, their attack failed because:

• The malicious miners did not control a sufficient proportion of the global hashrate to pull it off.  Loyal miners continued to mine Bitcoin, no matter what; and even fence-sitters mined Bitcoin, because they wanted to be paid in BTC, not BCH.  Which brings me to...
• BTC economics.  The market fluctuated wildly.  IIRC, BCH value spiked against BTC for about a day or so; I believe that was probably caused by intentional market manipulation.  Then, the market reconverged on BTC.  At that point, even the malicious miners must have needed to start mining at least some BTC, if they wanted to pay their electricity bills.  My such inference is consistent with all observable facts that I saw at the time.  It should be possible to reconstruct these historical events from remaining evidence; that would be an interesting project.

Now, the whole attack could have been stopped with a hardfork change to Bitcoin—not even a difficulty adjustment change as mocacinno suggests in the context of a different hypothetical, but something much beyond that.  I think that the malicious miners were seeking deliberately to exploit Segwit supporters’ aversion to a hardfork.  That was a stupid plan, when on the Segwit/UASF side, there was also some serious talk about the “nuclear option” of changing the POW algorithm:  Instantly destroy the operational value of Jihan’s ASICs, with a simple code change!  Of course, that is also a hardfork change—and it would unavoidably hurt honest miners who were 1000% pro-Bitcoin.  “Nuclear option.”

Many newer Bitcoiners nowadays, and almost all altcoiners, do not understand the social contract that Bitcoin has with miners.  As a non-mining user, I will defend the legitimate interests of honest miners—and I strive to avoid seeking anything that wrecks them, unless there is an overriding imperative to push the big red button on a “nuclear option”.  And Bitcoin proved in practice that it resists centralized control by a plutocratic cartel—unlike POS, which is plutocracy per se.

---

First, you backpedalled from a false explanation to insisting that intelligent questions from adults should be answered, “Child, you ask why the sky is blue?  It just is.”  (Translation:  “I don’t know.”)  Now, you demonstrate that you are as ignorant of psychology as you are of mathematics, how Bitcoin works, and due courtesy in addressing your betters.

Amusing though this may be, I cannot help you:  I neither could fix a conceited, willful stupidity, nor would wish to. ¯\_(ツ)_/¯

In this doomsday scenario, the network would probably stop working properly a few blocks afterwards, until a coordinated fork.

We know that the block's timestamp has to be less than the median time of the last 11 blocks plus 2 hours. If the 99% of the hash rate disappeared, the difficulty would drop by 25%, but this wouldn't be enough to retain the 10 minutes rule, but neither the process of the BIP113 soft fork (https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki) overtime. Initially, the miners would be more vulnerable to have their blocks rejected, unless they altered the timestamp to an arbitrary valid value.

That's not quite right. A block's timestamp has to fall within a range bounded by the median timestamp of the last 11 blocks (plus one second) in the past, to up to 2 hours in the future based on adjusted network time. If the future limit was median time of the last 11 blocks plus 2 hours, as you stated, then we would frequently run in to the problem of miners having fake timestamps, since on average any time it took more than an hour to find a block we would be outside of that window. Because the future limit is based only on the current time, we will never be in a situation where miners have to "back date" their blocks to ensure they are valid.

It would drop to 25%. It would drop by 75%.

I had confused what's network-adjusted time. Bitcoin Wiki clears it up:

So even if a miner tried to alter it, the full nodes that would relay it, would reject it. As for the median timestamp of previous 11 blocks, isn't it the timestamp of the 6th from the last 11 blocks?

Right (https://github.com/bitcoin/bitcoin/blob/0043ec4e1310e860150e5789064789377e5a6273/src/pow.cpp#L55-L59). That sounds more reasonable.

That's not quite right either. The median of the timestamps from all your peers is used to adjust your local time. Here's the code:


Not necessarily, because block timestamps do not need to be in order and can vary within the limits I gave above. The 6th last block might have a timestamp later than the 5th last block, meaning the 5th last block would be the median (if all the other block timestamps were in order).