Skip to main content

BIP-110: The Reduced Data Soft Fork

BIP-110 (originally called BIP-444) is a temporary soft fork proposal that would restrict arbitrary data storage on Bitcoin for approximately one year. It represents the most aggressive technical response to the OP_RETURN controversy.

Current Status
  • Official designation: BIP-110 (assigned December 2025)
  • Author: Dathon Ohm (pseudonymous)
  • Activation client: RC2 released January 3, 2026
  • Signaling: Begins December 1, 2025
  • Threshold: 55% miner support required

Background​

Following Bitcoin Core v30's removal of OP_RETURN limits, some developers argued that consensus-level restrictions were needed — not just relay policy changes. BIP-110 is the result.

The proposal was initially called "BIP-444" and contained controversial language about "legal and moral consequences" for rejecting it. It was later officially assigned number 110 and some of the more inflammatory language was moderated.

What BIP-110 Would Do​

The Seven Consensus Rule Changes​

RuleRestrictionPurpose
Output size limitsMax 34 bytes (OP_RETURN gets 83)Limit data in outputs
Data push limitsMax 256 bytesPrevent large data pushes
Witness element limitsMax 256 bytesRestrict witness data
Witness version restrictionsOnly v0 and Taproot permittedBlock future witness abuse
Taproot annex restrictionsTemporarily restrictedPrevent annex-based data
Control block limitsMax 257 bytesLimit Taproot control blocks
Opcode restrictionsCertain opcodes limitedDisable inscription techniques

Key Features​

  • Temporary: Auto-expires after ~1 year (block height 987,424)
  • Grandfathered UTXOs: Pre-existing outputs exempt from restrictions
  • UASF mechanism: User-activated, not miner-activated
  • Knots-based: Built on Bitcoin Knots, not Core

Activation Timeline​

Dec 1, 2025    Signaling begins (bit 4)
               ↓
               55% threshold (1,109/2,016 blocks)
               ↓
~Sept 1, 2026  Max activation (block 965,664)
               ↓
               ~52,416 blocks (~1 year)
               ↓
               Auto-expiry (unless extended)

The Activation Client​

Release History​

VersionDateStatus
RC1December 10, 2025Buggy — severe criticism
RC2January 3, 2026Fixes applied

RC1 Problems​

The initial release candidate received harsh criticism from developers:

  • Functional tests failing
  • Fuzz tests failing
  • Tests stubbed out with early returns
  • Binaries uploaded before Guix signatures

Michael Ford (Bitcoin Core maintainer):

"If you want to run this, wait for a later release candidate."

Rob Hamilton:

"Very possible [the client] could still have consensus bugs."

The criticism raised questions about whether the author had sufficient technical capability to spearhead a soft fork activation.

RC2 Improvements​

Released January 3, 2026:

  • CI now fully passing
  • Fixed spurious Taproot deployment warning
  • Proper preferred peer requests when querying DNS seeds

Known issue: Peer-finding difficulties when upgrading from non-BIP110 clients (workaround: delete peers.dat or use addnode=)

Arguments For BIP-110​

Supporters argue:

  1. Existential threat: Arbitrary data (especially illegal content) threatens node operator liability
  2. Relay policy failed: Core v30 proved policy-level restrictions can be removed
  3. Temporary measure: Buys time to design a permanent solution
  4. User choice: UASF respects user sovereignty over miners

Luke Dashjr (supports but denies authorship):

"This isn't intended to be an ideal solution, only good enough and super simple to buy time to design a long term solution."

Arguments Against BIP-110​

Critics argue:

  1. Censorship: Restricting transaction types violates Bitcoin's permissionless nature
  2. Ineffective: Peter Todd embedded the entire BIP text on-chain to prove it's bypassable
  3. Dangerous precedent: UASF coercion sets bad governance precedent
  4. Perverse incentives: Could incentivize worse behavior

Peter Todd: Embedded the entire BIP-110 proposal text on-chain, claiming it's "100% standard and fully compatible with the proposal" — demonstrating the restrictions can be bypassed.

Alex Thorn (Galaxy Digital):

Called the soft fork "an attack on Bitcoin" and "incredibly stupid."

BitMEX Research:

"A bad actor who wants to conduct a double-spend attack could put CSAM onchain to cause a re-org and succeed with their attack. The proposal therefore provides an economic incentive for onchain CSAM."

The Controversial Language​

The original BIP-444 draft contained provocative statements (lines 261-272):

"There is a moral and legal impediment to any attempt to reject this soft fork. Rejecting this soft fork may subject you to legal or moral consequences, or could result in you splitting off to a new altcoin like Bcash."

This language drew criticism for mixing technical proposals with legal threats. Some of this language has been moderated in the BIP-110 version.

Technical Concerns​

Can It Actually Be Enforced?​

Peter Todd's demonstration — embedding the full BIP text on-chain — suggests determined actors can still store data. The restrictions target specific methods, not data storage itself.

Chain Split Risk​

If BIP-110 activates without broad consensus:

  • Nodes running BIP-110 would reject blocks containing restricted transactions
  • Non-BIP-110 nodes would accept those blocks
  • Result: potential chain split

The SegWit2x Parallel​

Some observers compare BIP-110's rushed development to the failed SegWit2x fork of 2017, where inadequate coordination led to catastrophic failures.

Current Miner Signaling​

As of January 2026, miner signaling for BIP-110 is minimal. The 55% threshold has not been approached.

Key mining pools have not publicly committed to supporting or opposing the proposal.

Relationship to Bitcoin Knots​

BIP-110 is built on Bitcoin Knots, not Bitcoin Core. This is significant because:

  • Knots already has conservative defaults (83-byte OP_RETURN limit)
  • Knots users are the natural constituency for BIP-110
  • The ~21% of nodes running Knots represents the potential base

However, even many Knots supporters are skeptical of consensus-level restrictions, preferring policy-level solutions.

What Happens If It Activates?​

If BIP-110 activates (55% miner support reached):

  • Transactions violating the seven rules become invalid
  • Ordinals-style inscriptions would be blocked
  • Large OP_RETURN outputs would be rejected
  • Restrictions last ~1 year, then expire

If it fails to activate:

  • No consensus change occurs
  • The debate continues at the policy level
  • Proponents may attempt a revised proposal

How to Monitor​

See Also​

Sources​