the logic is simple. all bip-110 compliant blocks are compliant to also core spamchain blocks. all spammy blocks are noncompliant with 20% of the network already, and the transactions also are dropped by the same nodes. propagation delays will increase. any time two miners with bip-110 versus spammy happen within a few seconds of each other, the bip-110 block propagates faster - it is probably smaller, and 100% of nodes propagate it. even if coretards try to partition themselves against nodes that filter tx's and blocks with spam, they only make their problem worse by partitioning. by doing so they isolate themselves even more. if it comes down to 100% chance of holding a winning block at the chain tip, versus 20% chance of another miner hitting a block solution within seconds of it, the spam-supporting miner is down 150k$ worth of revenue. and then there is the custodians spam transactions can get reorged off the chain in the above scenario. spam transactions become more risky spam bursts will cause increased backlog of transactions on the spammy side, which will potentially make stuck channel opens and closes for lightning, and break systems that require 3 or 6 transactions where it can now end up costing more than 6 blocks or even indefinite to get them settled on spamchain, where as if they use a bip-110 node, it gets cleared faster because there is no spam-driven bloat of the mempool