Blockchain every 10 min?

[Jason Brendon]

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!

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.

[1713856316]

1713856316

[1713856316]

1713856316

[1713856316]

1713856316

[1713856316]

1713856316

[nullius]

[...]

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

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!  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:

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.

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

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

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.

Re: Bitmain announces plan to create altcoin if BIP148 succeeds

I have already stated that the ASIC monopoly and mining cartel are much more dangerous than any kind of scaling issues. Just so that we are clear, all these idiots in altcoins parading "we are the best, we will win next" will get crushed. This is the time to be watching and learning from Bitcoin, i.e. how Bitcoin combats and resists malicious actors such as Bitmain.

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.

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. ¯\_(ツ)_/¯

[BlackHatCoiner]

A huge delay.

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 overtime. Initially, the miners would be more vulnerable to have their blocks rejected, unless they altered the timestamp to an arbitrary valid value.

[o_e_l_e_o]

We know that the block's timestamp has to be less than the median time of the last 11 blocks plus 2 hours.

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.

If the 99% of the hash rate disappeared, the difficulty would drop by 25%

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

[BlackHatCoiner]

[...]

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

"Network-adjusted time" is the median of the timestamps returned by all nodes connected to you. As a result block timestamps are not exactly accurate, and they do not need to be. Block times are accurate only to within an hour or two.

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?

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

Right. That sounds more reasonable.

[o_e_l_e_o]

Bitcoin Wiki clears it up:

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:

Code: (https://github.com/bitcoin/bitcoin/blob/0043ec4e1310e860150e5789064789377e5a6273/src/timedata.cpp#L35-L38)

int64_t GetAdjustedTime()
{
    return GetTime() + GetTimeOffset();
}

As for the median timestamp of previous 11 blocks, isn't it the timestamp of the 6th from the last 11 blocks?

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