Filter capability invites broader censorship

Building and normalizing transaction-filtering capability — in node software or at the protocol level — creates a mechanism that states can later compel Bitcoin participants to point at any disfavored transaction.

For (strongest version as argued): Decentralization without censorship resistance is worthless. Once the ecosystem demonstrates that it can classify and exclude transactions by content or type, the political ask changes from "build censorship" (hard) to "extend the existing filter list" (easy) — sanctions compliance being the obvious first extension. The pressure points already exist: a small set of maintainers on the dominant implementation, large publicly listed miners with regulatory exposure, and custodial concentration. A content filter inside the protocol converts a company-level compliance problem into a Bitcoin-level problem.

Against (strongest version as argued): This is a slippery-slope argument, and a line can be drawn in principle: non-monetary data patterns are distinguishable as a category from disfavored monetary transactions, and a community that fought the block size war can hold a categorical line. Meanwhile the status quo is not neutral — declining to filter anything is itself a policy choice with its own political risks (illegal content on chain invites the heavier-handed intervention).

Nuance: Both positions agree state pressure on miners and developers is the realistic threat model; they disagree on whether filtering capability increases or decreases exposure to it. Historical precedent cited on both sides (mining-pool compliance episodes, prosecution of privacy-software developers) shows pressure arrives regardless; the open question is whether in-protocol tooling changes the outcome.

Common misstatements: "Filters already enable address blacklisting" (pattern-based data filters and address-based blacklists are different mechanisms; conflating them overstates the current capability). "Censorship resistance means no transaction can ever be delayed" (it means no transaction can be permanently excluded while at least some hash power will include it).