The rollout of Core 30 has done little to settle the debate over transactions with arbitrary data, with the monetary maximalist side of Bitcoin supporters offering up a few consensus change proposals of their own.
One being The CAT, which is a rather aggressive proposal that has already ruffled several feathers, but I think it was needed as a comparison for BIP 110, a more moderate proposal. If not for the CAT, BIP 110 would be dismissed off the bat as unreasonable, but without the CAT, BIP 110 seems more like an olive branch.
In October 2025, a Bitcoin developer using the pseudonym “Dathon Ohm” introduced a the proposal: BIP 444, the “Reduced Data Temporary Softfork” in an attempt to address what many view as an existential crisis—the explosion of arbitrary data storage on the blockchain through protocols like Ordinals and Stamps—before it permanently damages Bitcoin’s core function as a monetary network.
Unlike typical Bitcoin Improvement Proposals that undergo years of careful deliberation, BIP 444 reassigned as BIP 110 was conceived as an emergency response with an aggressive timeline. The proposal aims to temporarily restrict several consensus rules that enable large amounts of non-monetary data to be embedded in transactions, giving the community breathing room to develop more permanent solutions.
What makes BIP 110 particularly significant isn’t just its technical specifications—it’s the activation method the proposal employs: a User-Activated Soft Fork (UASF).
This action represents another moment in history in which Bitcoin users and node operators could be called to take sides via their reference implementation, asserting their power to change consensus rules regardless of miner support, echoing the 2017 UASF that successfully activated SegWit.
The Crisis: Bitcoin Core v30 and the 100KB OP_RETURN
To give you a bit of back story on why BIP 110 emerged, you need to understand Bitcoin Core version 30’s controversial change. Bitcoin Core v30 removed the 83-byte cap on OP_RETURN outputs, allowing much larger data payloads as long as users pay sufficient transaction fees. While this change was intended to support complex Layer-2 systems and cross-chain proofs, it opened the floodgates for massive data storage on Bitcoin’s blockchain.
OP_RETURN is a Bitcoin script opcode that creates provably unspendable outputs—transactions that can never be spent but whose data remains in the blockchain forever. For years, OP_RETURN was limited to 83 bytes, restricting its use to small data commitments like hash anchors and payment references.
Core v30 removed this limitation, enabling what critics call “officially sanctioned” large-scale data storage. Proponents argue that this enables the storage of non-monetary content in a contiguous format without requiring the misinterpretation of data, thereby creating legal liability for node operators.
What Is BIP 110? The Technical Specification
BIP 110 proposes seven specific consensus rule changes that would temporarily restrict Bitcoin’s ability to carry arbitrary data. These restrictions would remain in effect for approximately 1 year (ending at block height 987,424), after which they would automatically expire unless explicitly extended.
The Seven Key Restrictions
1. ScriptPubKey Size Limit (34 Bytes)
New output scriptPubKeys would be limited to 34 bytes or less, except for OP_RETURN outputs which could be up to 83 bytes. This prevents data storage in complex script conditions while preserving standard payment types like P2PKH, P2WPKH, P2SH, and P2TR which all fit within 34 bytes.
2. OP_PUSHDATA Size Limit (256 Bytes)
OP_PUSHDATA operations pushing more than 256 bytes would become invalid, except for BIP16 redeemScript pushes which require larger sizes. This targets methods used by Ordinals and similar protocols to embed large data chunks in witness data.
3. Undefined Witness Versions Become Invalid
Spending from undefined witness versions (anything beyond v0 and v1 Taproot) would become invalid. This prevents future witness versions from being co-opted for data storage before they’re properly specified.
4. Taproot Annex Prohibition
Witness stacks containing a Taproot annex would become invalid. The annex feature, while specified in Taproot, has never been formally defined for use, yet it provides another vector for arbitrary data storage.
5. Taproot Control Block Size Limit (257 Bytes)
Taproot control blocks exceeding 257 bytes (representing merkle trees with more than 128 script leaves) would become invalid. This prevents extremely deep Taptrees being used primarily for data storage rather than legitimate smart contract functionality.
6. OP_IF Prohibition in Tapscript
The OP_IF opcode would be disabled within Tapscripts. This targets specific encoding methods used by Ordinals inscriptions, which rely on conditional logic to embed data in witness scripts.
7. OP_RETURN Size Limit (83 Bytes)
Restores the historical 83-byte limit on OP_RETURN outputs, reversing Core v30’s expansion to 100KB+ capacity.
The Temporary Nature
Critically, BIP 110 implements these restrictions as a temporary soft fork. After approximately one year, the restrictions automatically expire and Bitcoin returns to pre-BIP-110 rules. T
his design gives the community time to:
- Develop more elegant, permanent solutions if consensus emerges that restrictions are valuable
- Allow experimentation with reduced data loads to measure impacts on fees, UTXO set size, and blockchain growth
- Provide an escape hatch if the restrictions prove harmful or unnecessary
As the proposal states:
“After a year, the soft fork expires, giving us time to come up with a more permanent solution.”
It’s basically a cool-off period (returning the previous status quo) for the toddlers throwing their toys out of the cot on both ends of the argument
What Are User-Activated Soft Forks (UASF)
BIP 110’s activation method is perhaps as significant as its technical content. The proposal employs a User-Activated Soft Fork (UASF)—a mechanism where Bitcoin users and node operators activate new consensus rules at a specific date, regardless of miner support.
How Traditional Soft Forks Work
Historically, most Bitcoin soft forks used miner-activated mechanisms. Miners signal readiness by including special version bits in blocks they mine. Once a supermajority threshold is reached (typically 95%), the new rules activate. This approach ensures that most hash power supports the fork before activation, minimising disruption.
How UASF Works Differently
A UASF bypasses miner signaling entirely. Instead, it specifies a “flag day”—a specific block height where new rules automatically activate for nodes running UASF-compatible software, regardless of what miners think.
BIP 110 proposes activation at block height approximately February 1st, 2026, giving users roughly three months to upgrade their nodes if they support the changes.
The Power Dynamics of UASF
UASFs represent a fundamental assertion of power: economic nodes control Bitcoin consensus, not miners. Miners can only mine blocks that economic nodes accept as valid. If a supermajority of economic activity runs UASF nodes, miners mining non-UASF-compliant blocks would find their blocks rejected, their block rewards worthless, and their hash power wasted.
This creates powerful incentives for miners to follow UASF rules even if they oppose them philosophically—they must mine blocks that nodes accept or go bankrupt, burning electricity for worthless rewards.
The 2017 Precedent: UASF and SegWit
The UASF mechanism isn’t theoretical—it was successfully employed in 2017 to activate SegWit (BIP 148). After years of deadlock over block size increases and SegWit deployment, a grassroots movement emerged advocating for a UASF that would activate SegWit on August 1, 2017, with or without miner support.
As UASF support grew among economic nodes and exchanges, miners faced a choice: support SegWit or risk a chain split where their non-SegWit blocks would be rejected by significant economic activity. The threat of UASF drove sufficient miner signaling to activate SegWit through the traditional BIP 9 mechanism just before the UASF flag day.
BIP 110 explicitly invokes this precedent, positioning itself as BIP 148’s spiritual successor—another moment where users must assert consensus power to protect Bitcoin from capture by special interests.
The Risks of UASF
Despite the 2017 success, UASFs carry significant risks:
- Chain Splits: If a UASF doesn’t achieve overwhelming economic node support, Bitcoin could split into two chains—one following UASF rules and one following old rules. Users could lose funds, exchange rates could crash, and network effects would fragment.
- Rushed Deployment: Critics argue that such a short timeframe is utterly absurd for a UASF with no mechanism for miner activation at all. BIP 110’s February 2026 activation date gives only ~3 months for ecosystem coordination—far shorter than typical soft fork timelines.
- Economic Miscalculation: If UASF advocates overestimate their economic support, they could find themselves on a minority chain with limited hash power, rendering it insecure and economically worthless.
The Fierce Debate: Support and Opposition
BIP 110 has sparked one of Bitcoin’s most contentious debates since the 2017 block size wars, revealing deep ideological divides.
Arguments Supporting BIP 110
- Bitcoin Is Money, Not Data Storage: Proponents argue: “The idea is to strongly re-affirm in consensus that bitcoin is money, not data storage”. They view arbitrary data protocols as parasitic uses that burden Bitcoin’s monetary function with unnecessary costs.
- Node Operator Protection: Supporters emphasizs legal and moral risks: “if Bitcoin provides an officially supported method of storing arbitrary data (i.e., OP_RETURN), and the capacity of that method is large enough to store hazardous content in a contiguous format… node operators could conceivably be held responsible for possession and distribution”.
- UTXO Set and Blockchain Bloat” Data storage protocols create permanent costs for all node operators, increasing hardware requirements and reducing decentralisation. BIP 110 supporters view this as unsustainable and contrary to Bitcoin’s long-term viability.
- Community Support: As of December 2025, the GitHub pull request has received significant support, with hundreds of positive reactions and dozens of detailed technical reviews.
Arguments Opposing BIP 110
- Censorship Resistance Violations: Critics argue that BIP 110 introduces subjective content-based restrictions. As one commenter noted: “Bitcoin should remain neutral about how data is interpreted or used, as long as it follows the defined rules and pays the required fees.
- Confiscation Risks: Greg Maxwell warns: “There likely exist chains of not yet confirmed (and potentially timelocked) transactions that involve violations of this rule. Those would appear to the network to be outputs created at a later time, although they really weren’t. This means presigned transactions relying on features BIP 110 restricts could become unspendable, constituting de facto confiscation.
- Technical Ineffectiveness: Peter Todd demonstrated that BIP 110’s restrictions can be evaded by encoding data across multiple outputs or using alternative methods. He embedded the entire BIP 110 text in a single transaction while complying with the proposal’s restrictions.
- Rushed Timeline and Insufficient Review: Multiple prominent voices have raised concerns about inadequate review time, unclear specifications, and the dangerous precedent of implementing major consensus changes under “emergency” pretences.
- Slippery Slope Concerns: Once Bitcoin accepts content-based restrictions, where does it stop? Could future proposals target mixer transactions, Lightning channels, or other controversial uses? Critics warn BIP 110 opens doors better left closed.
The Controversial Origins
BIP 110’s origins have fueled additional controversy. Greg Maxwell revealed:
“prior to you making this proposal I received minutes from a meeting which noted that Ocean Mining was the true author of this proposal and would be presenting it under a false identity in order to conceal their involvement”.
Greg Maxwell
While Dathon Ohm denies affiliation with Ocean, the proposal’s origins remain murky. The anonymous author’s GitHub account was created just weeks before the proposal, and questions about authorship, funding, and motivations have complicated technical discussions.
Implementation and Current Status
As of December 2025, BIP 110 has been assigned an official number (110) by BIP editors, indicating it meets minimal standards for consideration—though assignment doesn’t imply endorsement.
A reference implementation exists at the UASF Bitcoin repository, built on top of Bitcoin Knots 29.2. However, adoption remains minimal, with most Bitcoin users continuing to run standard Bitcoin Core releases.
The proposal faces significant headwinds:
- No major Bitcoin Core developers have endorsed it
- Most prominent bitcoiners have expressed opposition or scepticism
- Mining pools have shown no interest in supporting it
- The February 2026 activation date leaves minimal time for ecosystem coordination
The Broader Implications
Regardless of whether BIP 110 activates, its emergence reveals important truths about Bitcoin’s governance and future:
- The Power of Users: BIP 110 demonstrates that any sufficiently motivated group can propose and attempt to activate consensus changes through UASF mechanisms, regardless of developer or miner support.
- Unresolved Purpose Questions: Bitcoin’s community remains deeply divided on whether Bitcoin should be purely monetary or accept arbitrary data uses. BIP 110 forces this question into the open.
- Governance Fragility: Bitcoin’s lack of formal governance mechanisms means controversial changes can emerge suddenly, with unclear processes for resolution and significant risks of community splits.
- Emergency Activation Risks: The “emergency” framing of BIP 110 sets dangerous precedents. If rushed activation becomes normalised, Bitcoin could face continual disruption from groups claiming various “crises” justify bypassing normal deliberation.
A Test of Bitcoin’s Governance
BIP 110 represents more than a technical proposal to restrict arbitrary data—it’s a stress test of Bitcoin’s governance, a referendum on Bitcoin’s purpose, and potentially a preview of future conflicts as Bitcoin matures.
The temporary nature of the proposal provides some safety: if it somehow activates, the worst-case damage is limited to one year. But the precedents it sets—rushing consensus changes, using UASF coercion, framing technical disputes as emergencies—could prove more lasting than any temporary restrictions.
For Bitcoin users, BIP 110 poses difficult questions: Do you support using consensus rules to enforce a particular vision of Bitcoin’s purpose? Do you trust UASF mechanisms to navigate controversial changes without catastrophic splits? Do you believe the arbitrary data “crisis” justifies emergency action?
As February 2026 approaches, the Bitcoin community must grapple with these questions. Whether BIP 110 activates, fails, or evolves into something different, the debate it has sparked will shape Bitcoin’s trajectory for years to come.
As one supporter stated: “Bitcoin is money”.
BIP 110’s ultimate legacy may be forcing Bitcoin to collectively decide whether that simple statement is a complete description of what Bitcoin should be, or merely the beginning of a more complex answer.
