You admit BIP-110 does more than restore `datacarrier` - exactly. Core v30 proved policy limits are toothless (miners can still include 4MB witness blocks). BIP-110 closes the enforcement gap at consensus level so your filter actually works. "Don't run v30" is cope. Stay on v29 and miss CVE patches? That's not a choice - that's forced obsolescence. Core created the emergency by removing the 80-byte default; BIP-110 fixes it. Chain split panic is projection. BIP-110 is opt-in soft fork - if hashrate doesn't hit 55%, nothing changes. No split. Compare to UASF SegWit (30% hashrate, no threshold, still succeeded). 55% is higher bar than historical precedent. "Poorly planned"? PR #238 has been open for months with extensive review. Core v30 merged in 52 days against 424 downvotes - that's poor planning. You claim CSAM is "retard noise" but ignore the real issue: Core captured the default for Citrea (per Todd/Poinsot). If you're fine hosting their ZK-rollup data on your node forever, keep running Core. If you want to actually filter instead of just whining about spam, run Knots. Clean fork? We tried - Knots is 22% and growing. Core could add the config option back and end this tomorrow. They won't. That tells you who wants the split. Run Knots. Enforce the limit. Or keep crying about "retard noises" while your node syncs monkey JPEGs.