9/ Attached: “Bitcoin OP_RETURN Policy Debate Analysis” whiteboard diagram. 🧵 End. Follow @BitcoinKernel for real-time Bitcoin dev updates

8/ Final takeaways Policy cannot stop inscriptions (requires ≥90% enforcement → impossible) Consensus changes can stop specific methods but they • take years • require broad agreement • are still circumventable via new encodings Ordinals can always route around

7/ The deeper truth: Bitcoin’s script flexibility → infinite data channels Murch again (paraphrased): — As long as Bitcoin has a flexible scripting system — There will always be ways to embed arbitrary data — Blocking all methods would require “throwing out the — baby with

6/ The first real talk of compromise Luke de Wolf — initially critical — later acknowledged: — Both sides are closer to agreement than expected BIP444 is too aggressive in current form — Realistic compromise may involve: • A consensus-level OP_RETURN limit (e.g., 256 bytes)

5/ “If something can be bypassed, it’s not real censorship.” — Adam Back Adam summarized the engineering reality: – Most people would block spam if there were a “button” – But policy changes won’t even slow it： • Only consensus changes (soft forks) can enforce

4/ Why OP_RETURN limits no longer work (and even backfire) Murch again: – OP_RETURN was originally limited to raise the fixed cost of data embedding – Today inscriptions can embed 400kB as standard transactions – Witness discount makes them 4× cheaper per byte than OP_RETURN –

3/ “Policy enforcement collapses unless ≥90% of the network upgrades.” — Murch Murch provided the empirical missing piece: • Mempool policy only works when 90%+ nodes enforce it • 23% of listening nodes are still on 27.x or older • Therefore no restrictive policy can have

2/ “Policy cannot stop JPEGs.” — CbSpears + Casey CbSpears explained that any policy-level anti-spam filter is doomed: — There are infinite ways to encode data — Ordinals can release new versions weekly — Workarounds are trivial — Forking Bitcoin to stop them is economically

1/ Several core contributors and ecosystem leaders just laid out the clearest explanation to date of why anti-spam efforts cannot work at the policy layer, why Ordinals can always route around restrictions, and why consensus-level proposals are the only effective — but extremely

📜 Thread: Why the Anti-Spam Strategy Failed — Policy vs Consensus in Bitcoin (based on statements/posts from @cbspears, @rodarmor, @adam3us, @murchandamus, @lukedewolf · Nov 2025) 👇

Here’s the part most people missed about Bitcoin Core v30: The OP_RETURN change wasn’t about Ordinals — it was about BitVM. Clementine needed ~144 bytes of anchor data and had to create unspendable Taproot outputs, permanently polluting the UTXO set. Core developers chose a

11/ The core message from Antoine: “If people are going to do it anyway, give them the least harmful, pruneable path instead of pushing them toward UTXO pollution.” 🧵 End. Follow @BitcoinKernel for real-time Bitcoin dev updates

10/ Summary: Consensus unchanged Inscriptions unaffected L2 gets a cleaner, safer data channel UTXO bloat decreases Filters can’t block economic use Node sovereignty preserved

9/ This is not “giving in” or being “captured.” It’s a straightforward engineering tradeoff: Provide a safe, minimal-harm path for real protocol needs instead of forcing them to use worse methods that hurt the network.

8/ “Your node, your rules.” Don’t like it? Don’t upgrade. Or apply your own patch and keep the old limit. Bitcoin remains opt-in.

7/ Relaxing the limit reduces long-term damage. Better to move data into pruneable OP_RETURN than continue stuffing it into UTXO-bloating fake pubkeys. Cleaner for nodes, better for long-term health.

6/ Filters are not firewalls. If someone wants something mined and pays high fees, miners will include it. Policy rules mostly inconvenience everyday users but can’t block determined use cases

5/ History shows policy filters don’t stop economically driven usage. 2014: OP_RETURN restricted → people used multisig hacks 2023–24: inscriptions restricted → they used witness + private relays (Slipstream) Filters only push traffic from the public network to private bridge

4/ The real beneficiaries are Layer 2 protocols. Lightning and other state channels occasionally need to publish small pieces of proof data (tens to hundreds of bytes). Because OP_RETURN was too small, they had to use “fake pubkeys,” which permanently bloat the UTXO set.

3/ This has almost nothing to do with inscriptions or JPEGs. ~99% of inscriptions store data inside witness, not OP_RETURN. Relaxing OP_RETURN limits does not make inscriptions cheaper or easier.