Skip to main content

BIP-110: The Reduced Data Soft Fork

BIP-110, the Reduced Data Temporary Softfork (RDTS) — originally floated as "BIP-444" — is a temporary soft fork 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 (July 2026)
  • Official designation: BIP-110 in the bitcoin/bips repository
  • Author: Dathon Ohm (pseudonymous)
  • Shipped in Bitcoin Knots: the standard v29.3.knots20260508 build (May 2026) enforces RDTS on its schedule; a non-enforcing build is also published — see BIP-110 / RDTS Integration
  • Signaling: live since March 2026, but minimal — roughly 0.31% of hashrate (~5 EH/s of ~940 EH/s) as of late June 2026, almost entirely from Ocean pool
  • Threshold: 55% of blocks in a difficulty period (1,109 of 2,016) for early lock-in
  • Next milestone: mandatory signaling period at blocks 961,632–963,647 (early August 2026); activation at height 965,664 (~September 1, 2026)

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 restrictionsAnnexes invalidatedPrevent annex-based data
Control block limitsMax 257 bytesLimit Taproot control blocks
Opcode restrictionsOP_SUCCESS* and OP_IF/OP_NOTIF prohibited in TapscriptsDisable inscription techniques

Key Features​

  • Temporary: Auto-expires ~1 year after activation (block height 1,018,080)
  • Grandfathered UTXOs: Outputs created before activation exempt from restrictions
  • Hybrid activation: miner signaling with 55% early lock-in, plus a mandatory-signaling "flag day" fallback (UASF-style)
  • Knots-based: Built on Bitcoin Knots, not Core

Activation Timeline​

Dec 1, 2025      Signaling opens (bit 4)
                 ↓
                 Early lock-in if 55% (1,109/2,016 blocks) in any period
                 — as of late June 2026, signaling is ~0.31% of hashrate
                 ↓
Blocks 961,632–  Mandatory signaling period (~early August 2026)
963,647          ↓
Block 963,648    Lock-in (no later than)
                 ↓
Block 965,664    Activation (~September 1, 2026)
                 ↓
Block 1,018,080  Auto-expiry (~52,416 blocks, ~1 year later)

How to Run It​

Bitcoin Knots v29.3 (the mainstream route)​

Since May 2026, the primary way to enforce BIP-110 is Bitcoin Knots itself: the standard v29.3.knots20260508 build enforces RDTS on its deployment schedule, and asks each user for explicit confirmation — a GUI prompt at startup, or in bitcoin.conf:

consensusrules=rdts

Note that the setting records confirmation rather than toggling enforcement — in this build, enforcement follows the deployment schedule regardless, and unconfirmed bitcoind nodes log hourly warnings. A parallel build without any RDTS enforcement (v29.3.knots20260507) is published for users who prefer a client that cannot enforce it at all. For the full mechanics — the two builds, the confirmation flow, build flags, and how to monitor enforcement — see BIP-110 / RDTS Integration.

The Standalone Activation Client​

Before Knots shipped RDTS, the pseudonymous author distributed a standalone activation client:

VersionDateStatus
RC1December 10, 2025Buggy — severe criticism
RC2January 3, 2026Fixes applied
Knots v29.3.knots20260508May 8, 2026RDTS shipped in mainline Knots (confirmation required)

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-BIP-110 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​

The first signaling blocks appeared in March 2026, and as of late June 2026 signaling stands at roughly 0.31% of network hashrate (~5 EH/s out of ~940 EH/s) — nowhere near the 55% early lock-in threshold. Ocean pool has produced the large majority of signaling blocks; no other major pool has committed to signaling.

Estimates of nodes running BIP-110-capable software range from 2% to 8% of listening nodes, though the figures are disputed.

With early lock-in out of reach, attention has shifted to the mandatory signaling period (blocks 961,632–963,647, ~early August 2026): nodes that have opted in will begin rejecting non-signaling blocks then, regardless of hashrate support. Adam Back and Jameson Lopp have both publicly warned that these activation parameters risk a chain split; Lopp's "A Layman's Guide to BIP-110" is one of the more thorough critical walkthroughs.

Relationship to Bitcoin Knots​

BIP-110 is built on Bitcoin Knots, not Bitcoin Core — and since v29.3.knots20260508 (May 2026), the standard mainline Knots build enforces it. This is significant because:

  • Knots already has conservative defaults (83-byte OP_RETURN limit)
  • Knots users are the natural constituency for BIP-110
  • The roughly 23% of reachable nodes running Knots (July 2026) represents the potential base — though only an estimated 2–8% of listening nodes currently run BIP-110-capable software

However, even many Knots supporters are skeptical of consensus-level restrictions, preferring policy-level solutions — which is one reason a non-enforcing build (v29.3.knots20260507) is published alongside the standard one.

What Happens Next?​

If 55% miner signaling is reached (currently far off at ~0.31%):

  • Early lock-in, then activation one period later
  • Transactions violating the seven rules become invalid
  • Ordinals-style inscriptions would be blocked
  • Restrictions last ~1 year (to block 1,018,080), then expire

The live scenario — flag-day activation without hashrate support:

  • Enforcing nodes begin requiring mandatory signaling at block 961,632 (~early August 2026) and the full restrictions at block 965,664 (~September 1, 2026)
  • If miners keep producing non-signaling blocks, enforcing nodes reject them while the rest of the network follows the majority chain — the chain-split scenario Back and Lopp warn about
  • How much economic weight is behind enforcing nodes at that point determines whether this is a non-event or a serious split

If it expires or fizzles:

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

How to Monitor​

See Also​

Sources​