Author: Zhou, ChainCatcher
Recently, BIP-110 has pulled the Bitcoin community back into a debate that feels both familiar and unfamiliar.
What's familiar is that the controversy still revolves around arbitrary on-chain data, inscriptions, Runes, OP_RETURN, and the nodes themselves. What's unfamiliar is that this time, it's no longer just developers and node operators who are weighing in.
Michael Saylor, founder of Strategy; Adam Back, co-founder of Blockstream; mining pools Foundry and Ocean; the Bitcoin Knots node camp; and participants in the Ordinals ecosystem have all entered the debate from different angles.
On July 18, Michael Saylor listed 110 reasons opposing BIP-110 in his lengthy article "110 Reasons BIP-110 Is a Bad Idea." He argues that this proposal would escalate the fight over spam data into a change of consensus rules, rendering some currently valid transactions—that are willing to pay fees—invalid.
This makes BIP-110 more than just a technical proposal. It begins to force the Bitcoin community to confront a more fundamental question: who has the right to decide what Bitcoin should be.
What is BIP-110: Pushing Anti-Spam from Relay Policy to the Consensus Layer
BIP-110, short for "Reduced Data Temporary Softfork," was previously known as BIP-444. The current BIP-0110 document is authored by Dathon Ohm.
Image Source: FARSIDE
It proposes to introduce seven new restrictions via consensus rules over approximately one year, including limiting most new output scripts to within 34 bytes, restoring the OP_RETURN limit to 83 bytes, restricting data pushes exceeding 256 bytes and certain witness items, and temporarily banning some undefined witness versions and Taproot extension paths.
The proposal is set to automatically expire after one year, with coins existing before activation protected by a grandfather clause.
Source: GitHub
Regarding the deployment mechanism, according to the original bip-0110 text, the proposal uses bit 4 miner signaling with a threshold of 1109/2016, or 55%. The mandatory signaling period is set from block 961,632 to 963,647, with locking at the latest by block 963,648 and activation entering at block 965,664.
Supporters argue that non-monetary data like inscriptions and Runes occupy block space, increasing the long-term burden on full nodes and diverting developer attention from Bitcoin's core mission as a monetary network.
What truly sparks controversy is BIP-110 pushing this matter to the consensus layer. In the past, nodes could choose not to relay certain transactions, and miners could choose not to mine them. BIP-110 aims to make some currently valid transactions directly invalid at the protocol level.
This step changes the nature of the problem.
v30 and Node Relay Policy: Why Supporters Say Default Governance Has Failed
One backdrop to BIP-110 is Bitcoin Core v30's adjustment to the default policy for OP_RETURN.
According to the Bitcoin Core 30.0 release notes, the default value for datacarriersize was increased to 100,000, effectively lifting the default limit for OP_RETURN data carriers. Users can still revert to the old limit by manually setting datacarriersize back to 83. Multiple OP_RETURN outputs in the same transaction are also allowed for relaying and mining, with the limit now calculated based on the aggregate size of all relevant scriptPubKeys.
It's important to distinguish three layers here. Relay policy decides what nodes relay by default, mining policy decides what miners mine by default, and consensus rules determine whether a block is valid. v30 adjusted the first two layers. The controversy with BIP-110 lies in its attempt to push the policy debate from the first two layers into the third.
The Core side's rationale is that this change pertains to relay and mining policy, not consensus rules. Since users can already write data via other script paths, private relay channels, or direct submission to miners, maintaining a default limit that's easy to bypass only creates a false sense of security. Default node software should more closely reflect the transactions that miners and the market are likely to accept, within consensus rules.
BIP-110 supporters do not accept this explanation.
According to early Bitcoin participant @secsovereign, as disclosed in the response to Saylor's article "Response to Michael Saylor's 110 Reasons," the situation today is driven by the development of infrastructure like direct submission APIs, alternative relay networks, and private pool connections. These allow transactions to bypass default filtering by public nodes and go directly into miners' block templates. Inscriptions themselves didn't break the balance; they merely exposed that it had already been lost.
According to this narrative, node relay policy has long lacked enforcement power. The disclosure indicates that Core v30's relaxation of the default OP_RETURN limit is seen by supporters as formalizing this breach. Since the policy layer can't hold, the boundary must be moved to the consensus layer.
This section touches not on OP_RETURN itself, but on the power of default software. Bitcoin Core doesn't change consensus rules but can influence the actual behavior of many nodes and miners through default policies.
Supporters argue that the action of changing the v30 default policy had no signaling window, no threshold, and was completed by a few individuals with code merge permissions. In contrast, BIP-110's use of 55% miner signaling actually has a higher threshold than the change it seeks to correct.
Opponents argue that policy layer failure doesn't automatically prove that consensus layer restrictions are a justifiable, effective, and low-risk solution.
Adam Back's Rebuttal: Technical Consensus is Bitcoin's Immune System
The most complete first-principles argument against BIP-110 comes from Blockstream co-founder and hashcash designer Adam Back.
According to a post by Adam Back, he personally dislikes spam data, and designing hashcash was originally related to anti-spam. However, he believes that the foundation of Bitcoin as permissionless money is that no one can impose their own value judgments on others.
In his formulation, users can modify their own software but cannot modify others' software. A side effect of decentralization is that there are no police in the network, nor an authority that can decide legitimate uses for everyone.
Back also describes Bitcoin's technical consensus process as a form of protective resistance. Any protocol change must pass the scrutiny of numerous developers and protocol observers. This technical consensus, similar to IETF's process, though slow, prevents unproven modifications from eroding the system's foundational properties.
Therefore, his opposition to BIP-110 lies at the governance level. According to his disclosure, if supporters cannot accept the status quo, they can fork together, but Bitcoin will not join.
An Ironic Blow: Even If Activated, BIP-110 May Not Block Arbitrary Data
BIP-110 faces a more practical problem. Even if activated, it may not truly block arbitrary data.
According to disclosure by RustBitcoin maintainer Martin Habovštiak in March, he wrote a 66KB TIFF image into a single transaction without using OP_RETURN, Taproot, or OP_IF. It can be publicly verified on-chain and decoded into a complete file.
This shows that as long as Bitcoin still allows sufficiently complex state transitions, data can be split, encoded, or disguised to enter the chain.
Workarounds are also taking shape. Leonidas, co-founder of Runestone, pointed out that he is launching an open-source client called DOG Mode, specifically designed to relax BIP-110's restrictions on non-financial data. It doesn't change consensus rules, doesn't require a vote, only changes the relay policy of a single node. If enough nodes and miners accept it, related transactions may be propagated and confirmed.
@secsovereign pointed out that BIP-110 mainly blocks large continuous data channels and cannot completely block distributed data stuffing, so a separate minimum output value proposal is still needed to handle issues arising from dispersed outputs.
This puts BIP-110 in an awkward position. It bears the risk of a consensus change but may not fully achieve its cleanup goal. It can raise the cost of embedding data, but it's unlikely to end the data war.
Miners and Nodes: PoW Constitution, Knots Sovereignty, Foundry's Hashpower Vote
BIP-110's activation mechanism brings an old tension between miners and nodes back to the surface.
F2Pool co-founder Wang Chun posted, stating that PoW is Bitcoin's constitution, and nodes should respect miners. This represents a core view among the miner faction: soft forks without miner support, especially UASF with a mandatory signaling period, lack legitimacy at the execution level. He previously stated opposition to BIP-110, arguing that protocol upgrades should not mimic the bundled bills of US politicians.
The Knots node faction gives a completely different answer. @MarcanoFilms argues that the over fifteen thousand nodes currently running RDTS rules are sovereign operators putting up real capital, not products of Sybil attacks. Each node equally enforces consensus rules; the protocol layer doesn't grant more validation power to a node just because it belongs to a large exchange.
Mining pools themselves are also taking action, and in opposite directions. In March this year, the first block supporting the BIP-110 proposal appeared on the Bitcoin network, mined by the Ocean pool. Ocean recently stated it will upgrade its backend to independently follow multiple chains in case BIP-110 causes a chain fork, effectively operating as two separate pools from the fork point.
The leading pool, Foundry, is handing the decision to its clients, letting pool accounts vote weighted by average hashpower. It will only switch to signaling support for BIP-110 if votes in favor exceed 51% of the voting hashpower.
Miners, nodes, and pools are all answering the same question in their own way. Does the legitimacy of a Bitcoin upgrade come from PoW, from node enforcement, or from the balance between the two? The faction holding the real signaling power is not even unified internally.
BlockSlop: When Forking Moves from Talk to Upgrade Path, Engineering Risks Emerge
It's in this context that a technical tail risk has been publicly disclosed.
According to a lengthy article titled "BlockSlop: BIP 110 Consensus Bug Public Disclosure" published by researcher Dathon Pwn (Note: The discloser Dathon Pwn and proposal author Dathon Ohm are two different people; "Pwn" is hacker slang for "compromise"), a consensus vulnerability exists in the late-upgrade path for BIP-110 activation clients.
The issue is not that the new BIP-110 rules cannot check new blocks, but that a node might first accept a certain block under the old rules, then continue trusting its existing database after enabling BIP-110, without re-validating that historical segment under the new rules.
In other words, a late-upgrading node retains a historical block that was valid under the old rules but should be rejected under BIP-110. A fresh BIP-110 node validating from genesis rejects the same block. Both claim to have BIP-110 enabled but give different answers for the same piece of history.
Dathon Pwn also emphasized that this does not mean the mainnet has already split, nor does installing the software automatically trigger the problem. The trigger condition is that there actually exists on-chain a block that is valid under old rules but invalid under new rules, and a node has already accepted and saved it before enabling BIP-110.
The weight of this discovery lies in its timing. It emerged just as Foundry is consulting its miners on whether to signal, placing a precondition-dependent but fixable upgrade path defect before all participants who might mine, settle, or build upon this chain. For miners, exchanges, wallets, and custodial institutions, hidden divergence is often harder to handle than an open fork.
Corporate Treasuries Weigh In: A New Variable in Protocol Politics
Returning to Saylor, his involvement adds a new weight to this debate.
In his article "110 Reasons BIP-110 Is a Bad Idea," he opposes BIP-110's use of a 55% miner signaling threshold, arguing it is significantly lower than the BIP-9 standard of 95%, and that it removes the usual timeout and failure states, potentially increasing coordination errors, chain splits, and market uncertainty.
He also argues that block space fees, node relay policy, miner policy, pruning, and Layer2 tools can address related issues without changing consensus.
According to his disclosure, even if the rules are only temporary, the governance precedent they establish could persist, making the proposed governance scheme more dangerous than the problem it seeks to solve.
Saylor's particular significance lies in representing BTC holders at the public company level. According to the latest disclosure, Strategy holds 843,775 BTC.
It is not a mining pool, not a Core maintainer team, nor an ordinary node community, but its balance sheet can influence the market's judgment of which chain is BTC.
What he possesses is narrative power and capital market influence. He can influence how markets and media interpret this debate, provide legitimacy backing for one side, and have his preferences amplified by capital markets.
In the previous rounds of Bitcoin governance debates, the stage was usually occupied by developers, miners, node operators, and even exchanges. This time, a public company's balance sheet has also stepped onto the stage of protocol politics. This may be the most significant change left by BIP-110.
Conclusion
Putting these five forces together, what BIP-110 truly exposes becomes clear. Bitcoin lacks a universally acknowledged arbiter.
Miners hold hashpower but are divided internally. Node operators advocate for equal validation, rejecting weighting by economic scale. A few developers hold code merge permissions, can practically change the network default, but lack an accountability mechanism towards node operators who bear the permanent costs.
Treasury holders wield narrative and capital but have no on-chain vote. And the technical consensus process represented by Adam Back treats the resistance to change itself as a source of legitimacy.
Each faction invokes a different basis of power, and each is contending for the interpretation of neutrality and conservatism.
BIP-110 may ultimately fail to activate, but it has already conducted a stress test on governance.
When the imperative to defend monetary boundaries and the imperative to maintain protocol neutrality collide head-on, each side will claim to be the one defending Bitcoin. The true core of this controversy is who has the right to decide what Bitcoin is.
