I assume you are showing old data and or knots data, not recent bip110 data in this image because recent bip110 data has 0.004% reduction in runes opteturns which make up more than half of tx

If it doesn't fix 99.99% of the current spam, what's the point?

BIP-110 does next to nothing to stop Runes, 99.99% of Rune activity would remain unaffected. Over the last 30 days (May 7 – June 5, 2026) there were ~18.94 million total transactions. Of these, 10.88 million were valid Runes (≤ 83-byte OP_RETURN), while only 456 exceeded the limit in BIP110.

Inscriptions are being used a negligible amount. Runes on the other hand account for most bitcoin transactions (57.5% this month by my count) and BIP110 does nothing to stop them. Is BIP110 facilitating these shitcoins?

Everything they did, they could have done (and until recently did do) without any changes to policy from core, so I don't understand why you feel core is in any way responsible. Realistically it would not have been possible for core to stop this, even BIP110 doesn't stop this.

Thanks that's interesting, ironically by trying to concede to core devs request to use a less 'damaging' data storage method there will no doubt be many who view this as proof that they were indeed the masterminds behind changing policy defaults.

FWIW ottosch just pointed out that on Apr 29th citrea did start using bigger op_return output instead of 80‒byte + 2 fake pubkeys many months after they became standard. https://x.com/ottosch_/status/2062895674916581480 https://github.com/chainwayxyz/clementine/pull/1241

When I attended a Bitcoin++ event last year I asked a member of the Citrea team who was presenting whether they planned to switch to using the larger and he explicitly said that they weren't switching. I can't see any evidence that they switched. Can you provide any evidence?

There was no change to bitcoin core which benefited Citrea, IIUC they haven't even implemented the change to use larger OP_RETURNs instead of fake pubkeys.

I keep hearing BIP110 proponents describe their fork as being the safe option even with a minority of hashrate due to the "asymmetry" that the BIP110 chain can wipe out the legacy chain, but the legacy chain cannot wipe out the BIP110 chain. This asymmetry is real for ANY soft fork, but it doesn't make a minority hashrate soft fork safe. Softfork nodes reject legacy blocks, so they'll never reorg onto the legacy chain Legacy nodes accept softfork blocks so they will reorg onto the softfork chain if it has more cumulative work. Once again, If it has more cumulative work. Nodes (including miner nodes) follow the most-work (valid) chain. A minority hashrate softfork chain accumulates work slower than the legacy chain. With a minority of hashrate the BIP110 chain will not persist as the most-work chain, it will fall further and further behind over time. The BIP110 chain could get lucky and get ahead temporarily, but over time the luck will run out and once it falls sufficiently far behind it won't ever catch up to the chain tip.