On the new deep reorg protection

I woke up today to see two threads flooded with discussion about ABCs new deep reorg protection. As I feel partially responsible for this, since I've suggested such a mechanism in a past thread, I'd like to make a comprehensive thread on the topic.

Terminology

Full Node: A full node (which is what miners, businesses, SVP wallets and full node wallets rely on) has a complete copy of the blockchain. The full node is also connected to its peers to receive and relay new blocks that are found.

Blockchain: Blocks always reference the block they are built on, hence forming a chain of blocks.

Consensus: A set of rules agreed upon by all network participants what constitutes block permissible to be included on the chain and which have to be orphaned because they are invalid as per consensus.

Orphan: If a miner receives a block but does not build on it for whatever reason (consensus violation or other metrics)

Fork: When two blocks appear that are referencing the same parent block

longer/shorter chain: Nodes select which is the canonical chain based on which valid chain (of several alternative forks that conform to consensus) has the most accumulated proof of work (for simplicities sake abreviated as "longer chain"). The shorter chain would be any with less accumulated proof of work.

Reorg: If there are several alternative chains and one that was previously behind overtakes the other, then a reorg happens where all transactions in the now shorter chain get invalidated by the now longer chain.

Deep reorg: If there is a reorg that goes unusually far back. For instance in the nearly 10 year history of the BCH chain, it only happened 2 in extraordinary circumstances that a 10 block deep reorg appeared (and both times in extraordinary circumstances that required manual intervention regardless).

Network partition: If there is an event which causes nodes on the network to mutually reject each others chain choices and side with one or the other side of a fork.

What is deep reorg protection?

This is a new rule introduced by the ABC implementation for full nodes, that will cause them to orphan a block if it builds on a chain whose fork origin lies back further than 10 blocks.

Why do we need it?

BCH being a relatively small chain it faces some issues with an attack where the attacker amasses enough hashing power to secretly build a longer chain than the chain everybody knows about. When the attacker broadcasts the blocks of this chain, they cause a reorg that goes back however long the attacker secretly mined (could be hours, days, weeks, months or years). CSW has threatened to do that.

The usual rule for when to accept a transaction as irreversible is 6 transactions (which is used by most exchanges and the like). Not only can the attacker with his reorg cause this to blow up (by not including those transactions), but he can also specially craft transactions to go into one block and say send coins to an exchange, but in the reorg exclude those transactions and include another transaction that he spends to his own wallet, and therefore execute a successful and damaging double spend (CSW has threatened to do that too).

Is this not a unilateral consensus change by ABC making BCH not Bitcoin?

No. This isn't a consensus change per se. Consensus is what can possibly constitute a valid chain as agreed upon by all network participants. It rules the visible history, the one that gets persisted forever. Miners can and do use a variety of "soft" rules to orphan blocks that technically conform to consensus (such as when they're to large, too expensive to validate, etc.)

Was it proper for ABC to introduce this change out of the blue?

I'm not terribly happy it got introduced as it was. I would've hoped there to be a robust debate and analysis of the measure by people way smarter than me, and I haven't seen any of that. That doesn't mean it's automatically a bad idea or change, but it may need some refinement, refinement that I hope every implementation, miner and full-node operator can get behind.

Will this not disrupt the usual functioning of the network?

No. 10-block deep reorgs only happened twice in the nearly 10 year history of the BCH chain and both times in extraordinary circumstances that required manual intervention regardless.

What if a 10-block deep reorg is not an attack?

This may happen in circumstances where the internet for a whole country (let's say China) is cut for a couple of hours. In that case there will be a more than 10-block deep fork of miners on either side of the internet (those within china and those outside). If this happens, a manual intervention will be required regardless if the deep reorg protection exists or not. Miners in China do not want to reorg the chain that users/businesses/exchanges outside of China accept as canonical. It is most likely that businesses/exchanges within China would suspend withdraw/deposit and wait for the network to be restored to pick up the chain when the network is restored.

Does this introduce a new attack vector?

I think it does create a new attack surface.

1. Create a 10-block deep fork
2. Broadcast 9 of the blocks (you may fake them arriving at organic intervals)
3. Wait for the 10th block to be found on the other side of the fork and immediately broadcast your 10th block
4. Let block propagation and node selection partition the network into two parts that mutually reject each others canonical chain as a 10-block deep reorg

Due to a concern-troll describing this attack in hundreds of replies on other posts I shall call this the zhell attack.

How can the zhell attack be mitigated?

I don't know. I think there may be mitigation strategies, but these will need a robust discussion and analysis to be developed, and I hope all developers/implementations/businesses will be part of that debate.