Relay filters cannot stop determined data embedding

Mempool relay filters (node policy) cannot prevent a determined party from getting arbitrary data into the blockchain.

For (strongest version as argued): Policy is local, not consensus: a filtered transaction is still valid in a block, so anyone with a path to a miner — direct submission, an accelerator service, or a minority of unfiltered relay nodes — bypasses every filter on the network. Data has been embedded in Bitcoin using only pre-SegWit primitives, so no single feature rollback closes the channel; encoding can hide in signatures, public keys, and fake output hashes that are indistinguishable from ordinary payments. This is why restriction proponents themselves escalated from filters to a soft-fork proposal.

Against (strongest version as argued): Perfection is the wrong bar. Filters raise friction and cost, deter casual and commercial embedding, and express node-operator preferences; the goal is deterrence at the margin, not impossibility. An actively maintained filter set that responds each time embedders change technique keeps the cheap, standardized channels closed even if exotic ones remain.

Nuance: The narrow technical claim — that policy filters cannot guarantee exclusion of data from blocks — is essentially conceded by all sides; the live disagreement is whether friction-without-guarantee is worth its costs (maintenance burden, mempool divergence, weakened fee estimation, and pressure toward direct miner submission, which itself has centralizing effects).

Common misstatements: "Filters censor the blockchain" (relay policy affects propagation, not block validity). "Removing filters changed the protocol" (Bitcoin Core v30's OP_RETURN change was policy-only; consensus rules were untouched). "Filters do nothing" (they demonstrably shape default behavior and cost for non-adversarial users).