It irks me a lot of a certain public figure keeps spouting nonsense, so I need to clarify in plain English for people why the idea where "miners can orphan blocks if they see a doublespend in mempool, this will deter other miners from trying" will never work and will never get adopted by any sane miner. Consider the following scenario:

Alice and Bob are both mining nodes, relayed by Charlie (Charlie might or might not be mining, it's irrelevant to the problem). Even for the most devout believer of small-world connectivity, having one hop between two mining nodes seem reasonable - having no hops is an assumption that is neither robust nor sustainable. Normally they relay blocks and transaction to each other, and in case of doublespend, tyranny of hashrate dictates that whichever transaction gets included first in a block is the truth - regardless of mempool. All is fine.

We then introduce a rule that says to both Alice and Bob: if you see a block incoming that contains a tx, but you have already seen tx2 - its doublespend - in your mempool, reject the block. Sounds fine right? Zero-conf is now bulletproof!

Well, let me introduce you to Daniel, a guy up to no good who just wants to wreak havoc on the BCH network. Daniel knows where Alice and Bob's nodes are, and establishes direct connection to them both. He then spends a hundred dollars in tx fee every day spamming transactions to Bob at random intervals. It doesn't do anything, really. What's the meaning you ask?

Well, once in a while Daniel's transaction will get included *immediately* after he sends it to Bob, *before* it gets to Charlie the relay, and Daniel will know this because Bob broadcasts his block immediately like the good profit minding-miner he is. What does Daniel do with this information?

Before Charlie can react, he sends a conflicting tx2 to Alice. As long as Alice gets tx2 even 100ms before he gets the relayed block from Bob, she will have to reject the block under our new rule! Well, now Bob is upset because he has lost revenue (if Alice has more hashpower) or fractured the network (if Alice has less hash). Daniel can keep on the charade for a cheap cost until he provokes mass panic among miners. What is Bob to do, knowing there can be lots of Daniels lurking out there? He can:

Delay transaction inclusion. He can maybe delay transactions from getting included as long as reasonable, and meanwhile attempt to broadcast new transactions. The problem with this approach is, of course, that there is no way to prove a tx2 does *not* reside in Alice's mempool; what if Alice has a connection problem? What if there's a Sybil attempt, making your latency much longer? What if Alice's RAM is actually lower than what you thought and it's stuffed at the moment? What if Alice just doesn't *like* that tx - perhaps she and Charlie both follow first seen and exclusion of doublespend - which she is free to do so and you have no way to enforce against? How long do we need to delay? It makes the mining scene a lot less robust, the game-theoretical possibilities are endless. Bitcoin (Cash) is robust against all these. We don't just make it fragile to collect a few cents in risky fees. Talk to Alice through some supra-protocol channel and agree between them to accept the block. Well, you just broke trustlessness, made miners collude and reinvented XRP! Congratulations! Just mine empty blocks, the fees are tiny anyway and not worth the risk. Any rational Bob will do this. No tx, no risk of attack, claim block reward and be happy.





What then happens in a decentralized system where miners don't trust each other outside the protocol is easily seen: You get empty blocks all day, every day, and the network is toast.

This is a scenario fresh off the top of my head. Switch the number and roles of actors around, play with latency and timing and adversarial efforts of various costs, I'm sure an enterprising reader can think of hundreds of other attack scenarios that all make the network less robust.