Quote from: o_e_l_e_o on Today at 08:57:23 AM

I already said all this above:

Quote from: o_e_l_e_o on August 01, 2022, 03:32:14 PM

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.

Quote from: Jason Brendon on Today at 01:09:57 AM

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!

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.