Author: Zhou, ChainCatcher
Recently, BIP-110 has pulled the Bitcoin community back into a familiar yet unfamiliar debate.
Familiarly, controversy still surrounds on-chain arbitrary data, inscriptions, Runes, OP_RETURN, and the nodes themselves. Unfamiliarly, the participants this time are no longer just developers and node operators.
Strategy founder Michael Saylor, Blockstream co-founder Adam Back, mining pool Foundry, and Ocean, Bitcoin Knots node supporters, and Ordinals ecosystem participants have all weighed in on this debate from different perspectives.
On July 18, Michael Saylor listed 110 reasons against BIP-110 in a lengthy article titled 110 Reasons BIP-110 Is a Bad Idea. He argues that this proposal would escalate the battle over junk data into a consensus rule change and invalidate transactions that are currently valid and willing to pay fees.
This makes BIP-110 more than just a technical proposal—it begins to challenge the Bitcoin community with a more fundamental question: who has the right to decide what Bitcoin should be?
What is BIP-110: Moving anti-spam from the forwarding policy to the consensus layer
BIP-110 stands for Reduced Data Temporary Softfork, which can be translated into Chinese as “Reduced Data Temporary Softfork”, and its predecessor is BIP-444; the original author of the current BIP-0110 is Dathon Ohm.
Image source:FARSIDE
It plans to introduce seven new restrictions via consensus rules over approximately one year, including limiting most new output scripts to 34 bytes or less, restoring the OP_RETURN limit to 83 bytes, restricting data pushes exceeding 256 bytes and certain witness elements, and temporarily disabling some undefined witness versions and Taproot extension paths.
The proposal is set to expire automatically after one year, and coins existing prior to activation are grandfathered in.
Source:GitHub
Regarding the deployment mechanism, according to the original BIP-0110, the proposal uses miner signaling via bit 4, with a threshold of 1,109 out of 2,016, or 55%. The mandatory signaling period is set between blocks 961,632 and 963,647, with lock-in occurring no later than block 963,648 and activation taking place at block 965,664.
Supporters argue that non-monetary data such as inscriptions and Runes consume block space, increase the long-term burden on full nodes, and divert developers' attention from Bitcoin's core mission as a monetary network.
What truly sparked controversy was BIP-110 pushing this issue to the consensus layer. Previously, nodes could choose not to relay certain transactions, and miners could choose not to include certain transactions in blocks. BIP-110 aims to render certain currently valid transactions invalid at the protocol level.
This step changes the nature of the issue.
v30 and node forwarding policy: Why supporters say default governance has failed
One context behind BIP-110 is Bitcoin Core v30's adjustment to the default policy for OP_RETURN.
According to the release notes for Bitcoin Core 30.0, the default value of datacarriersize has been increased to 100,000, effectively removing the default limit on OP_RETURN data carriers; users can still revert to the previous limit by manually setting datacarriersize back to 83. Multiple OP_RETURN outputs within the same transaction are now also allowed to be relayed and mined, with the limit now calculated based on the aggregated size of all related scriptPubKeys.
Here, it’s important to distinguish three layers. The forwarding policy determines what nodes default to forwarding, the mining policy determines what miners default to including, and only the consensus rules determine whether a block is valid. v30 adjusts the first two layers; the controversy around BIP-110 is that it attempts to elevate the policy dispute from the first two layers into the third.
The rationale for the Core side is that this change pertains to forwarding and mining policies, not consensus rules. Since users can already write data to miners through other script paths, private forwarding channels, or direct submissions, maintaining a default restriction that is easily circumvented only creates a false sense of security. The default node software should more closely align with the transactions that miners and the market are actually likely to accept, in accordance with consensus rules.
Supporters of BIP-110 do not accept this interpretation.
According to early Bitcoin participant secsovereign, it was the development of infrastructure such as direct API submissions, alternative relay networks, and private pool connections that brought us to today’s situation. These advancements allow transactions to bypass the default filtering of public nodes and reach miners’ block templates directly. The inscriptions themselves did not break the balance—they merely exposed that it had already been lost.
According to this narrative, the node forwarding strategy has long since lost its enforceability. According to its disclosure, Core v30’s relaxation of the OP_RETURN default limit has been viewed by supporters as formalizing this concession. Since the policy layer can no longer hold the line, the boundary must be moved to the consensus layer.
This section truly addresses not OP_RETURN itself, but the power of default software. Bitcoin Core has not changed consensus rules, yet it can influence the actual behavior of a large number of nodes and miners through default policies.
Supporters argue that the change to the v30 default policy was implemented without a signaling window or threshold, carried out by a small group with merge permissions. In contrast, BIP-110 requires a 55% miner signal, setting a higher threshold than the one it seeks to correct.
Opponents argue that the failure of the strategy layer does not automatically prove that the consensus layer restrictions are legitimate, effective, and low-risk solutions.
Adam Back's rebuttal: Technical consensus is Bitcoin's own immune system.
The most complete first-principles argument against BIP-110 comes from Adam Back,
According to Adam Back's post, he personally despises spam data, and his design of Hashcash was originally related to anti-spam efforts. However, he believes that as the foundation of permissionless money, Bitcoin is something no one should impose their own value judgments on others.
In his statement, users can modify their own software but cannot modify others' software. The side effect of decentralization is that there are no police in the network, nor any authority that can determine legitimate uses for everyone.
Back also refers to Bitcoin's technical consensus process as a form of protective resistance. Any protocol change must undergo extensive review by a large number of developers and protocol observers; this IETF-like technical consensus, while slow, prevents unverified modifications from eroding the system's fundamental 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 band together to fork, but Bitcoin will not join.
Ironic punch: Even if activated, BIP-110 may not stop 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, in March he disclosed that he wrote a 66KB TIFF image in a single transaction without using OP_RETURN, Taproot, or OP_IF, and the file is publicly verifiable and decodable on-chain in its entirety.
This means that as long as Bitcoin allows sufficiently complex state transitions, data can be split, encoded, or disguised and entered on-chain.
Tools for routing around these restrictions are also taking shape.Leonidas, co-founder of Runestone points out that he is launching an open-source client called DOG Mode, specifically designed to relax BIP-110 restrictions on non-financial data. It does not alter consensus rules or require voting—only changes the forwarding rules of individual nodes. If enough nodes and miners adopt it, relevant transactions may be propagated and confirmed.
@secsovereign pointed out that BIP-110 primarily blocks large continuous data channels but cannot fully prevent distributed data injection, so a separate minimum output value proposal is still needed to address issues caused by dispersed outputs.
This places BIP-110 in an awkward position: it assumes the risk of a consensus change but may not fully achieve its cleanup goal. It can increase the cost of data embedding, but it struggles to end the data war.
Miners and Nodes: PoW Constitution, Knots Sovereignty, Foundry Hashrate Voting
The activation mechanism of BIP-110 has reignited the old tensions between miners and nodes.
F2Pool co-founder Wang Chun stated that PoW is the constitution of Bitcoin, and nodes should respect miners. This reflects a core belief among the miner faction: without miner support, soft forks—especially UASFs with mandatory signaling periods—struggle to gain legitimacy in implementation. He previously opposed BIP-110, arguing that protocol upgrades should not mimic American politicians’ bundled legislation.
The answers given by Knots nodes are completely different. @MarcanoFilms believes that the more than 15,000 nodes currently running the RDTS rules are genuine sovereign operators, not the product of sybil attacks. Each node equally enforces consensus rules, and the protocol layer does not grant additional validation rights to a node simply because it belongs to a large exchange.
Miners themselves are also taking action, but in the opposite direction.This year3month,the Bitcoin network saw its first block supporting BIP-110, mined by Ocean Pool.OceanRecently stated it will upgrade its backend to independently follow multiple chains in the event of a fork caused by BIP-110, effectively operating as two separate pools from the fork point onward.
The leading mining pool, Foundry, delegates the decision to its customers, allowing mining pool accounts to vote based on weighted average hash rate; a switch to signaling support for BIP-110 will only occur if votes in favor exceed 51% of the total voting hash rate.
Miners, nodes, and mining pools are each answering the same question in their own way: Where does the legitimacy of Bitcoin’s upgrade come from—PoW, node enforcement, or the balance between the two? Even within the party holding real signaling power, there is no unified opinion.
BlockSlop: When forks turn from verbal battles into upgrade paths, engineering risks begin to surface
It was against this backdrop that a technical tail risk was publicly disclosed.
According to researcher Dathon Pwn’slong-formarticle“BlockSlop: BIP 110 Consensus Bug Public Disclosure”,there is a consensus vulnerability in the BIP-110 activation client’s delayed upgrade path.(Note: The discloser Dathon Pwn and the proposal author Dathon Ohm are two different individuals; “Pwn” means “to compromise” in hacker slang.)
According to its disclosure, the issue is not that the new BIP-110 rules cannot verify new blocks, but that nodes may initially accept a block under the old rules and, after enabling BIP-110, continue to trust the existing database without revalidating that history under the new rules.
In other words, a late-upgrade node retains historical blocks that were valid under the old rules but should have been rejected under BIP-110, while a brand-new BIP-110 node rejects the same block during initial validation. Both claim to have enabled BIP-110, yet they provide conflicting answers about the same historical record.
Dathon Pwn also emphasized that this does not mean the mainnet has split, nor does installing the software trigger the issue. The trigger condition is that a block following the old rule but invalid under the new rule actually exists on-chain, and the node has already accepted and stored it before enabling BIP-110.
The significance of this discovery lies in its timing. It emerges just as Foundry is deciding whether to signal for miner input, bringing a conditional but fixable flaw in the upgrade path to the attention of all participants who may mine, settle, or build on this chain. For miners, exchanges, wallets, and custodians, hidden disagreements are often harder to manage than public forks.
Corporate treasuries enter the arena: A new variable in protocol politics
Back to Saylor,his involvement this time adds new weight to the debate.
In "110 Reasons BIP 110 Is a Bad Idea", he opposes BIP-110’s 55% miner signaling threshold, arguing that it is significantly lower than BIP-9’s 95% standard and eliminates the conventional timeout and failure states, potentially increasing the risk of coordination failures, chain splits, and market uncertainty.
He also believes that tools such as block space fees, node forwarding strategies, miner strategies, pruning, and Layer2 can address these issues without modifying the consensus.
According to its disclosure, even if the rules are only temporarily in effect, the governance precedent they establish may persist long-term, making this proposed governance framework more dangerous than the issue it seeks to address.
Saylor's uniqueness lies in the fact that he represents a publicly traded company-level BTC holder. According to the latest disclosure, Strategy holds 843,775 BTC.
It is not a mining pool, not the Core maintenance team, nor the general node community, but its balance sheet influences the market’s perception of which chain is BTC.
What he possesses is the power of narrative and the weight of the capital markets. He can influence how the market and media interpret this controversy, provide legitimacy to one side, and amplify his own preferences through the capital markets.
In the last Bitcoin governance debate, the stage was typically occupied by developers, miners, and node operators,evenexchanges.This time, a public company’s balance sheet has also stepped onto the stage of protocol politics. This may be the biggest change left by BIP-110.
Finally
Putting these five forces together makes it clear what BIP-110 truly exposes: Bitcoin has no universally recognized arbiter.
Miners control the hashing power, yet internal divisions persist. Node operators advocate for equal validation and reject weighting based on economic size. A small group of developers holds the authority to merge code, enabling them to effectively alter the network’s default settings, yet there is no accountability mechanism toward node operators who bear the permanent costs.
Wallet holders hold narrative and capital but lack on-chain votes. Meanwhile, the technical consensus process represented by Adam Back treats resistance to change as a source of legitimacy.
Each side invokes different sources of authority and competes for the right to define the terms "neutral" and "conservative."
BIP-110 may ultimately fail to activate, but it has already undergone a governance stress test.
When the claims of defending monetary boundaries and maintaining protocol neutrality come into direct conflict, each side will claim to be the true defender of Bitcoin. The real core of this dispute is who has the right to decide what Bitcoin is.