While Michael Saylor warns that “ambitious opportunists” pushing protocol changes pose Bitcoin’s greatest risk, the ongoing Core vs Knots debate about blockchain spam reveals a more nuanced reality. BIP 110’s proposed data size restrictions offer a perfect lens for understanding Bitcoin’s delicate balance between necessary evolution and prudent ossification.
What BIP 110 Actually Proposes
BIP 110 aims to “temporarily limit the size of data fields at the consensus level, in order to correct distorted incentives caused by standardizing support for arbitrary data, and to refocus priorities on improving Bitcoin as money.”
The proposal introduces four specific technical constraints designed to curb what critics consider blockchain bloat. First, output size limits restrict new transaction outputs to just 34 bytes, think of this as limiting how much information you can attach to each payment destination. The exception is OP_RETURN outputs, which can contain up to 83 bytes for necessary data storage like timestamps or small messages.
Second, data push limits cap individual data pushes and witness elements at 256 bytes maximum. In human terms, this prevents users from stuffing large chunks of arbitrary data, like images or documents, into transaction scripts. It’s like imposing a strict word limit on transaction “memos” to keep them focused on payment functionality rather than file storage.
4 restrictions in data output
The third restriction involves witness version limitations, allowing only well-defined witness versions (v0 and Taproot) to be spent during deployment. This prevents developers from exploiting undefined witness versions as workarounds for storing large data. Finally, Taproot restrictions temporarily limit Taproot annexes, large control blocks, and certain opcodes. Limiting Taproot control blocks significantly complicate advanced smart contracts like BitVM.
These technical constraints address the growing concern about Bitcoin transactions being used for purposes beyond monetary exchange, storing NFT data, arbitrary files, or other information that inflates block sizes without contributing to Bitcoin’s core money function. The proposal reflects tensions between Bitcoin’s openness and its efficiency as a payment system as spammers will always be able to spread their data over multiple fields, no matter how strict data limits become.
“
The fees are the filter, any filter be that in the mempool or in actual output data limits like BIP110 suggest, they can ALWAYS be bypassed, as is inherently to an open uncensorable network.
— Rob Segers, Bitsaga founder
This insight reveals BIP 110’s fundamental challenge: any consensus-level data restrictions can theoretically be circumvented by determined actors willing to pay higher fees or find creative workarounds. The Core vs Knots debate highlights this tension: Bitcoin Knots implements stricter spam filtering policies while Core maintains more permissive defaults, yet both acknowledge that truly open networks resist perfect content control.
BIP 110’s approach represents a middle path, not eliminating arbitrary data usage entirely, but raising its cost and complexity to discourage casual blockchain bloat. The proposal acknowledges that determined actors will find workarounds while hoping to redirect casual users toward Bitcoin’s monetary use cases. This reflects the protocol’s broader evolution challenge: maintaining openness while preserving efficiency.
The ongoing ossification versus evolution debate encompasses proposals like BIP 110 precisely because they involve deep technical tradeoffs with long-term implications. Saylor’s warnings about protocol modifications gain nuance when viewed through this lens, the question isn’t whether Bitcoin should never change, but how to distinguish between changes that strengthen its monetary properties versus those that compromise them. BIP 110’s data restrictions attempt this distinction, though their ultimate effectiveness remains constrained by Bitcoin’s fundamental openness.
