What is the downside of having a default setting in which nodes will invalidate blocks that comprise a surprise reorg?

Question

Suppose that suddenly, out of nowhere, a longest-chain appears that reorgs the last 15 blocks. Such an attack could be accomplished from time-to-time even by a minority attacker who is either lucky or pays heavily for extra temporary hashrate. Depending on how clever the attacker is, this can be quite lucrative. It's feasible, especially if Coinbase or Binance was victimized, that an unofficial edict could go out use invalidateblock. After a short period of moderate confusion, nodes would have agreed to reject this fork, temporarily suspending Nakamoto Consensus, and Bitcoin would proceed as before, and the attacker, who spent perhaps millions of dollars executing this attack, would be chastised and impoverished, chilling the ambitions of other attackers who would attempt a similar caper.

My questions: why would we think that such a community reorg wouldn't happen? Second, why not just have this coded into the software? If a node suddenly sees a new block appear at height 10 below the latest height the node has seen, this gets automatically invalidated. What goes wrong?

Answer 1

What you describe is basically a rolling checkpoints system. While it reduces the risk of a hostile deep reorg, it introduces a new attack where an attacker can cause consensus splits.

If we assume that an attacker is able to perform a 15 block reorg, then that attacker can secretly mine a 15 block fork and time the broadcast of it such that some nodes switch to using the attacker's chain, and some nodes use the original chain. There is no way for any automatic reconciliation to occur. If the attacker can maintain their hashrate, then they can effectively DoS the entire network by constantly forking nodes and forcing node operators to intervene.

Additionally, such a rule opens up the possibility for long range attacks against nodes that are still syncing. Instead of mining on the main chain, the attacker could choose to mine earlier in the blockchain (where the difficulty is lower) and feed his blocks to nodes that are still syncing. This could force newly syncing nodes onto the attacker's chain which has less work than the main chain without any way for the node to switch to the real chain without operator intervention.

---

Rolling checkpoint rules have been implemented in alternative cryptocurrencies before, notably BCH. BitMex published an analysis discussing the pros and cons of that.

Answer 2

So, the attacker has X% of the hashrate. The attacker is trying to mine 16 blocks in the time that the honest miners mine at most 15 blocks, because e.g. the victim waits for 15 confirmations on transactions of the attacker's deposit amount. If the honest miners get fewer than fifteen blocks, the attacker still wins at the 16th, they can just wait for the fifteenth block (or even help mine it, to add to their alibi).

Kindly, Satoshi Nakamoto left us a formula that addresses exactly this scenario in the whitepaper on page seven:

^{Source: Bitcoin Whitepaper}

Even with a hashrate of 30%, the chance of success for such reorganization lengths is pretty low. Satoshi calculated further:

q=0.3
z=0 P=1.0000000
z=5 P=0.1773523
z=10 P=0.0416605
z=15 P=0.0101008
z=20 P=0.0024804

Which gives one percent chance of success with thirty percent hashrate to displace 15 blocks.

Obviously, the chance would be higher if the attacker could leverage more than 30%, but even 30% seem fairly unlikely, given that this would require at least two, more likely three of the largest hashrate providers to make themselves available for such an attack, or even more of the smaller ones.

^{via miningpoolstats.stream/bitcoin}

Further, general computing power is useless, since Bitcoin uses specialized hardware, and there is hardly any SHA-256 hashrate rentable. Crypto51, a website dedicated to tracking the cost of a majority attack for various networks, estimates that a majority attack on Bitcoin would cost about $1.2 M per hour at the going rate for hashpower, but the rentable SHA-256 hashrate via Nicehash only amounts 34% of BCH's hashrate, which itself is a fraction of 1% of Bitcoin's hashrate.

^{via crypto51.app}

So, unless the attacker manages to take control of multiple existing mining pools for multiple hours, this doesn't really seem particularly feasible.