Author: Zhou, ChainCatcher
Recently, BIP-110 has dragged the Bitcoin community back into a familiar yet strange debate.
What's familiar is that the controversy still revolves around arbitrary on-chain data, inscriptions, Runes, OP_RETURN, and the nodes themselves. What's strange is that this time, the participants are no longer just developers and node operators.
Strategy founder Michael Saylor, Blockstream co-founder Adam Back, mining pools Foundry and Ocean, the Bitcoin Knots node faction, and Ordinals ecosystem participants have all intervened in this debate from different angles.
On July 18, Michael Saylor, in his long article "110 Reasons BIP-110 Is a Bad Idea," listed 110 reasons to oppose BIP-110. He believes this proposal would escalate the garbage data dispute into a consensus rule change, potentially invalidating some currently valid transactions that are willing to pay fees.
This transforms BIP-110 from a mere technical proposal. It now forces 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 Relaying Policy to Consensus Layer
BIP-110, full name Reduced Data Temporary Softfork, is formerly known as BIP-444. The current BIP-0110 original author is Dathon Ohm.
Image Source: FARSIDE
It plans to introduce seven new restrictions via consensus rules over approximately one year. These include limiting most new output scripts to 34 bytes, restoring the OP_RETURN cap 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 automatically expires after one year, with coins existing before activation protected by a grandfather clause.
Source: GitHub
Regarding deployment, according to the bip-0110 text, the proposal uses bit 4 for miner signaling, with a threshold of 1109/2016, i.e., 55%. The forced signaling period is set between block 961,632 and 963,647, locking in at the latest by block 963,648, and activating at block 965,664.
Supporters argue that non-monetary data like inscriptions and Runes occupies 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 include certain transactions. BIP-110 aims to directly render some currently valid transactions invalid at the protocol layer.
This step changes the nature of the problem.
v30 and Node Relaying Policy: Why Supporters Say Default Governance Has Failed
One backdrop to BIP-110 is Bitcoin Core v30's adjustment to the default OP_RETURN policy.
According to Bitcoin Core 30.0 release notes, the default value for `datacarriersize` was increased to 100,000, effectively lifting the default cap on OP_RETURN data carriers. Users can still restore 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 related scriptPubKeys.
Three layers need distinction here. Relaying policy determines what nodes relay by default, mining policy determines what miners include by default, and consensus rules determine whether a block is valid. v30 adjusted the first two layers. The controversy over BIP-110 lies in its attempt to push the policy dispute from the first two layers to the third.
The Core side's rationale is that this change belongs to relaying and mining policy, not consensus rules. Since users can write data via other script paths, private relay channels, or direct submission to miners, maintaining an easily bypassed default limit only creates a false sense of security. Default node software should more closely reflect transactions that miners and the market are likely to accept and that comply with consensus rules.
BIP-110 supporters do not accept this explanation.
According to early Bitcoin participant @secsovereign's disclosure in their response "Response to Michael Saylor's 110 Reasons," what brought the situation to this point is the development of infrastructure like direct submission APIs, alternative relay networks, and private mining pool connections. These allow transactions to bypass default filtering by public nodes and reach miners' block templates directly. Inscriptions themselves did not break the balance; they merely exposed that it was already lost.
Under this narrative, node relaying policy long ago lost its enforcement power. According to their disclosure, Core v30's relaxation of the default OP_RETURN limit is seen by supporters as formalizing this loss. Since the policy layer cannot hold, the boundary must be moved to the consensus layer.
This section truly touches not on OP_RETURN itself, but on the power of default software. Bitcoin Core does not change consensus rules, yet it can influence the actual behavior of many nodes and miners through default policies.
Supporters argue that the move to change v30's default policy had no signaling window, no threshold, and was carried out by a few individuals with code merge permissions. In contrast, BIP-110 uses a 55% miner signaling threshold, which is higher than the change it seeks to correct.
Opponents argue that the failure of the policy layer does not automatically prove that consensus-layer restrictions are a justified, effective, and low-risk solution.
Adam Back's Rebuttal: Technical Consensus is Bitcoin's Immune System
Among BIP-110 opponents, the most complete first-principles argument comes from Blockstream co-founder and hashcash designer Adam Back.
According to Adam Back's posts, he personally dislikes spam data; his design of hashcash was 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 view, users can modify their own software but cannot modify others' software. The side effect of decentralization is that there is no police in the network, nor any authority that can determine legitimate uses for everyone.
Back also describes Bitcoin's technical consensus process as a form of protective resistance. Any protocol change must undergo scrutiny by many developers and protocol observers. This slow, IETF-like technical consensus can prevent unverified changes 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 unite to fork, but Bitcoin will not join them.
An Ironic Blow: Even if Activated, BIP-110 May Not Truly Block Arbitrary Data
BIP-110 also faces a more practical issue. Even if it activates, it may not truly block arbitrary data.
According to RustBitcoin maintainer Martin Habovštiak's disclosure in March, he managed to write a 66KB TIFF image into a single transaction without using OP_RETURN, Taproot, or OP_IF, and it can be publicly verified on-chain and decoded into a complete file.
This indicates that as long as Bitcoin allows sufficiently complex state transitions, data can be split, encoded, or disguised before entering the chain.
Workarounds are also taking shape. Runestone co-founder Leonidas 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 does not change consensus rules, does not require voting, only changes a single node's relaying rules. If enough nodes and miners accept it, related transactions could be propagated and confirmed.
@secsovereign notes that BIP-110 mainly blocks large, contiguous data channels and cannot completely prevent distributed data stuffing. Therefore, a separate minimum output value proposal is also needed to address issues caused by dispersed outputs.
This places 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 data embedding, but it likely cannot end the data war.
Miners and Nodes: PoW Constitution, Knots Sovereignty, Foundry's Hash Power Vote
BIP-110's activation mechanism brings to the surface the old tension between miners and nodes.
F2Pool co-founder Chun Wang posted that PoW is Bitcoin's constitution, and nodes should respect miners. This represents a core view of the miner faction: a soft fork without miner support, especially a UASF with a forced signaling period, lacks legitimacy at the execution level. He previously also opposed BIP-110, arguing that protocol upgrades should not imitate the bundled bills of US politicians.
The Knots node faction offers a completely different answer. @MarcanoFilms argues that the over fifteen thousand nodes currently running RDTS rules are sovereign operators investing real money, not products of a Sybil attack. Each node equally enforces consensus rules; the protocol layer does not grant more validation power to a node simply because it belongs to a large exchange.
Mining pools themselves are also taking action, and in opposite directions. In March this year, the Bitcoin network saw its first block supporting the BIP-110 proposal, mined by Ocean pool. Ocean recently stated it will upgrade its backend to independently follow multiple chains if BIP-110 causes a chain split, effectively operating as two separate pools from the fork point.
Top mining pool Foundry is leaving the decision to its clients, letting pool accounts vote weighted by average hash power. It will only switch to supporting BIP-110 signaling if the approval votes exceed 51% of the voting hash power.
Miners, nodes, and pools are all answering the same question in their own ways. Does the legitimacy of a Bitcoin upgrade come from PoW, from node enforcement, or from the checks and balances between them? The pole holding real signaling power is not even unified internally.
BlockSlop: When Forking Moves from Talk to Upgrade Path, Engineering Risks Become Visible
It is precisely against this backdrop that a technical tail risk was publicly disclosed.
According to a long article "BlockSlop: BIP 110 Consensus Bug Public Disclosure" released by researcher Dathon Pwn (Note: the discloser Dathon Pwn and proposal author Dathon Ohm are two different people; 'Pwn' in hacker slang means to compromise/exploit), the activation client for BIP-110 contains a consensus bug on the late upgrade path.
According to the disclosure, the problem is not that BIP-110's new rules cannot check new blocks, but that a node might first accept a block under the old rules and, after enabling BIP-110, continue to trust its existing database without re-validating that segment of history 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 scratch 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 split, nor does it mean installing the software will trigger the issue. The trigger condition is that a block that is valid under the old rules but invalid under the new rules indeed exists on-chain, and the 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 about whether to signal. It places a pre-conditioned yet fixable upgrade path defect before all participants who might mine, settle, or build upon this chain. For miners, exchanges, wallets, and custodial institutions, hidden disagreements are often harder to handle than public forks.
Corporate Treasuries Entering the Fray: A New Variable in Protocol Politics
Returning to Saylor, his involvement adds a new layer of 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 BIP-9's 95% standard. He also criticizes the removal of the usual timeout and failure states, which could increase coordination failures, chain splits, and market uncertainty.
He also believes tools like block space fees, node relaying policies, miner policies, pruning, and Layer 2 can address related issues without altering consensus.
According to his disclosure, even if the rules are only temporary, the governance precedent they establish may persist long-term. Thus, the governance approach proposed is more dangerous than the problem it aims to solve.
Saylor's uniqueness lies in representing BTC holders at the publicly-traded 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 on which chain is BTC.
What he possesses is narrative power and weight in capital markets. He can influence how markets and media interpret this dispute, provide legitimacy endorsement for one side, and amplify his preferences through capital markets.
In the previous round of Bitcoin governance debates, the stage was usually occupied by developers, miners, node operators, and even exchanges. This time, the balance sheet of a publicly listed company has also stepped onto the stage of protocol politics. This might be the biggest change left by BIP-110.
Finally
Putting these five forces together, what BIP-110 truly exposes becomes clear. Bitcoin lacks a universally recognized arbiter.
Miners hold hash power but are internally divided. Node operators advocate for equal validation, rejecting weighting by economic scale. A few developers hold code merge permissions, can actually change the network's defaults, yet lack accountability to 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 resistance to change itself as a source of legitimacy.
Each faction cites different sources of authority, and each is competing 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 claims of defending monetary boundaries and maintaining protocol neutrality collide head-on, each side will claim they are the ones protecting Bitcoin. The true core of this dispute is: Who has the right to decide what Bitcoin is?
