Why Bitcoin Developers Are Divided Over BIP-110’s New Restrictions

A dispute over BIP-110, a proposed temporary change to Bitcoin’s transaction rules, is moving toward a scheduled enforcement test in August. The debate now includes prominent developers, infrastructure operators, security specialists and corporate Bitcoin advocates on both sides.

Michael Saylor and Adam Back first publicly opposed the proposal on July 11. Saylor later expanded his position in a July 18 essay titled “110 Reasons BIP-110 Is a Bad Idea,” but his intervention was part of an already active technical and governance dispute. It wasn’t its starting point.

The Bitcoin BIP-110 proposal would restrict several methods of placing large amounts of non-payment data inside transactions. Supporters argue that the limits would protect node operators and preserve block space for monetary activity. Opponents say the rules could break legitimate transaction structures and establish a precedent for judging transactions according to their purpose.

BIP-110 has not received network-wide acceptance or taken effect. Its “Complete” status means its technical specification has been finalized, not that the Bitcoin network has approved the change.

BIP-110 would impose seven temporary restrictions

Formally titled the Reduced Data Temporary Soft fork, BIP-110 would add rules that make some previously valid transactions or blocks invalid for nodes enforcing the proposal.

The proposal contains seven restrictions. They include an 83-byte limit for OP_RETURN outputs, one of several transaction fields used to attach data, as well as 256-byte caps on other data fields and tighter rules for certain Taproot scripts. Taproot is part of Bitcoin’s system for supporting more advanced transaction and contract structures.

The proposal itself acknowledges that its Taproot limits could complicate projects such as BitVM, which aims to support more complex applications using Bitcoin. Its authors also identify unusual Taproot and pre-signed transaction structures that could encounter spending problems, although they describe those cases as unlikely.

Supporters describe the targeted activity as arbitrary data storage that imposes costs on full-node operators. Every full node must download and process the blockchain. Node operators bear the verification cost, while miners receive the transaction fees.

The restrictions would apply for about one year. They would cover only UTXOs created after the activation height. A UTXO is an individual piece of bitcoin that has not yet been spent. Those confirmed before activation would remain exempt.

Dashjr and Ocean argue the restrictions are necessary

Luke Dashjr is one of the proposal’s most prominent public supporters. The Bitcoin Core developer, Ocean mining pool co-founder and technical director is credited with advising on BIP-110’s original draft.

Dashjr has presented the proposal as a defensive measure against transaction activity that he believes threatens Bitcoin’s long-term function. He has stated: “If BIP110 fails, Bitcoin fails with it.”

Ocean was the first mining pool to signal support and remains nearly the only pool doing so. Miner signalling means miners indicate support through the blocks they produce. Ocean’s position gives the proposal a named institutional advocate, although current signalling remains far below the threshold required for early lock-in.

Supporters argue that transaction fees alone do not account for every cost imposed on the network. Their case is that consensus restrictions may be justified when certain transaction structures create persistent storage and processing burdens for thousands of independent nodes.

Back and Saylor challenge purpose-based restrictions

Adam Back and Michael Saylor have emerged as the two most prominent public critics.

Back is Blockstream’s co-founder and chief executive and the inventor of Hashcash, the proof-of-work system cited directly in the Bitcoin whitepaper. He has described BIP-110 as a “literal downgrade,” arguing that it could break existing Miniscript and UTXO edge cases while creating a precedent for filtering transactions based on their perceived purpose. In practical terms, his concern is that the proposal could disrupt some advanced transaction structures that are valid under Bitcoin’s current rules.

Saylor’s July 18 essay develops a similar governance argument. He maintains that Bitcoin cannot reliably determine whether transaction data represents an image, contract, proof or future financial application. In his view, fee-paying transactions should compete for block space without consensus rules deciding whether their purpose is acceptable.

Node operators and miners can already choose which transactions they relay or include. Critics argue that converting those individual policy choices into network-wide consensus rules is a materially different step.

This is the central divide surrounding the Bitcoin BIP-110 proposal. Supporters see a temporary response to unwanted data storage. Opponents see a shift from verifying transaction validity toward regulating transaction intent.

Lopp, Todd and other critics raise broader concerns

Jameson Lopp, Casa’s chief security officer, has framed Bitcoin’s value as a “dependable anchor.” He warns that purpose-based restrictions could create a “slippery slope to centralization and control.”

Developer Peter Todd has offered a practical demonstration of another criticism: bypassability. Todd embedded the full BIP-110 text inside a transaction that complied with BIP-110’s own restrictions, illustrating that determined users may still store substantial data by restructuring how it is encoded.

Gregory Maxwell, a former Bitcoin Core developer and Blockstream co-founder, has raised technical criticisms of the proposal and has also alleged that Ocean Mining authored BIP-110. Its pseudonymous author, Dathon Ohm, denies that claim.

The August process could separate enforcing nodes

Miners began signalling support in December 2025. BIP-110 uses a 55% early lock-in threshold across a 2,016-block difficulty period. A difficulty period is a standard Bitcoin cycle covering 2,016 blocks, while early lock-in means the proposal has gained enough miner support to advance before the mandatory stage.

Signalling remained below 1% as of the weekend of July 18–19, leaving support far short of early lock-in. Miner signalling is a live figure that updates frequently and may have changed by publication.

The more contentious stage is expected around August 7, near block 961,632. Nodes running BIP-110 rules would then reject blocks that do not signal support. For that software, the specification forces lock-in by block 963,648. Activation follows near block 965,664, expected around September 1.

Those rules apply only to participating software. Nodes that do not enforce BIP-110 would continue accepting otherwise valid Bitcoin blocks. If enforcing nodes reject most blocks followed by the wider network, they could separate onto a smaller chain.

A lasting split is not certain. The outcome depends on miners, node operators, exchanges, custodians and other economically important participants. Miner signalling does not capture every form of network support.

>>> Read more: Noah Doe Bitcoin Wallet Lawsuit Faces New Legal Challenges

Complete status does not represent approval

BIP editor Mark “Murch” Erhardt, who assigned BIP-110 its number, has called it “a misguided and unusually careless soft fork proposal.” He published it because it met the repository’s process criteria. But documenting a proposal and endorsing it aren’t the same thing.

BIP-110-compatible software is already available through Bitcoin Knots and several node platforms. Publishing a specification or releasing software does not equal consensus across Bitcoin.

The next meaningful evidence will come from miner signalling and adoption among exchanges, custodians and node operators. Until then, the Bitcoin BIP-110 proposal remains just that: a proposal, not an accepted upgrade for the entire network, even as its technical specification is complete and its enforcement schedule approaches.