BIP-110 sounds good on paper — a temporary soft fork to reclaim block space from Ordinals and inscriptions — but it fundamentally misunderstands the problem it's trying to solve. The proposal introduces seven consensus-level restrictions targeting data embedding vectors, yet Peter Todd demonstrated its fatal flaw by encoding the entire text of BIP-110 itself into a single compliant transaction. If the rules can't even stop someone from embedding the proposal's own text, they won't stop determined data embedders — they'll just make the process slightly more expensive and fragmented. That's not a solution; it's an inconvenience.
The deeper issue is what BIP-110 represents for Bitcoin's future. Bitcoin's consensus rules have historically been objective and content-neutral — a valid transaction is valid regardless of what its data "means." The moment we start restricting transactions based on subjective judgments about "legitimate" versus "illegitimate" use of block space, we set a precedent that could be turned against any disfavored use case tomorrow. And with only ~7% of nodes running the activation client and zero miner signaling, a forced UASF activation risks a chain split that would burn the community's coordination capital — making it harder to rally support for consensus changes we actually need.
If blockchain bloat is the concern, there are better paths forward. BIP-54 (Great Consensus Cleanup) addresses overlapping security concerns like worst-case block validation time through targeted bug fixes without making content-based judgments, and it has far broader developer support. Bitcoin's censorship resistance isn't just a feature — it's the foundation. We should be solving the spam problem with better economics and smarter protocol design, not by giving anyone the power to decide which transactions deserve to exist.
BIP-110 sounds good on paper — a temporary soft fork to reclaim block space from Ordinals and inscriptions — but it fundamentally misunderstands the problem it's trying to solve. The proposal introduces seven consensus-level restrictions targeting data embedding vectors, yet Peter Todd demonstrated its fatal flaw by encoding the entire text of BIP-110 itself into a single compliant transaction. If the rules can't even stop someone from embedding the proposal's own text, they won't stop determined data embedders — they'll just make the process slightly more expensive and fragmented. That's not a solution; it's an inconvenience.
The deeper issue is what BIP-110 represents for Bitcoin's future. Bitcoin's consensus rules have historically been objective and content-neutral — a valid transaction is valid regardless of what its data "means." The moment we start restricting transactions based on subjective judgments about "legitimate" versus "illegitimate" use of block space, we set a precedent that could be turned against any disfavored use case tomorrow. And with only ~7% of nodes running the activation client and zero miner signaling, a forced UASF activation risks a chain split that would burn the community's coordination capital — making it harder to rally support for consensus changes we actually need.
If blockchain bloat is the concern, there are better paths forward. BIP-54 (Great Consensus Cleanup) addresses overlapping security concerns like worst-case block validation time through targeted bug fixes without making content-based judgments, and it has far broader developer support. Bitcoin's censorship resistance isn't just a feature — it's the foundation. We should be solving the spam problem with better economics and smarter protocol design, not by giving anyone the power to decide which transactions deserve to exist.