An N block reorg on Bitcoin with more proof-of-work appears out of nowhere with a double spend. How big does N have to be before you choose not to accept the reorg?
-
-
or b/ a malicious entity has taken over majority hash rate- you can confirm this by checking with other miners. Once confirmed, coordinating on a hard fork is a temporary solution, with the caveat that if the HF still uses the same hash algo, solution might not be sustainable.
-
... since whoever capable of taking over majority hash rate & caused a deep reorg like that can easily overwhelm your minority chain if they need to. You can also change the hash algo with the HF, which'd brick all mining hardware- might not be a safe position to be in either.

-
Although it would also depend on how much hash rate is behind the reorg
If it’s a clear majority, e.g. 90% chain A vs. 10% chain B, hardforking away while reusing the same hash algo is not a long term solution. But if its 55% vs 45%, better shot at survivability.
End of conversation
New conversation -
-
-
Scenario (a) also implies the existence of malicious miner(s) with enormous hash rate, right? Because all those blocks you saw before you saw the new heavier chain were real and required the work that corresponds to their difficulty. Not disputing your analysis just confirming.
-
No, a partitioning attack (or accident) can happen without having any hash rate at all.
-
Cool. Mind expanding on that, or suggesting a place for me to look?
-
Let’s say Neha’s scenario happens tomorrow, and it’s because you’re in scenario (a). What to make of the blocks that your node has been receiving over the past days/weeks/months? Their mere existence implies the expenditure of hashpower corresponding to their difficulty, right?
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
