BIP-110 (also called RDTS — Reduced Data Temporary Softfork; sometimes referenced alongside BIP-444 naming) proposes temporary consensus limits on large data fields so the chain stays focused on monetary use. The BIP document is finished; network activation is a separate, live signaling story.
Complete means the specification is finished. It does not mean Bitcoin Core ships it, or that majority hashrate has activated the rules.
Orange fill = signaling % this difficulty period. Green mark = 55% early lock-in threshold.
Loading…
Connecting to mempool.space…
Support signaling/enforcement by running compatible software. Review the code walkthrough before you rely on a build.
29.3.knots20260508+ with RDTS / consensusrules=rdts
Marketplace package + Activate RDTS task
App store update + RDTS prompt
Custom Knots version + confirmation
Knots path with RDTS option
Official image tag + conf line
New outputs limited to 34 bytes of script, except OP_RETURN up to 83 bytes.
Script pushes and witness elements capped at 256 bytes (narrow P2SH redeemScript exception).
Only well-defined witness versions (v0 and Taproot) can be spent while active; creating other outputs may still be allowed.
Annexes, oversized control blocks, OP_SUCCESS, and Tapscript OP_IF/OP_NOTIF are restricted while active.
Inputs spending UTXOs created before activation are permanently exempt from the new spend rules — there is no deadline to move those coins.
Control blocks are capped (~257 bytes) while active, so Tapleaves deeper than about 7 levels are unspendable on enforcing nodes. Deeper designs may wait for expiry or use pre-activation UTXOs.
Tapscript OP_IF/OP_NOTIF fail while active. Prefer separate leaves and keep required script-path leaves within the depth cap. Pre-activation UTXOs stay exempt.
Undefined witness versions and OP_SUCCESS-style escape hatches are unavailable while reduced-data rules are on.
Risk is narrow: typically P2TR coins that must confirm and spend during the window via a violating Tapleaf with no alternate path. Pre-activation coins remain spendable under old rules for those inputs.
Enforcing nodes that reject non-compliant blocks can follow a different tip than non-enforcing nodes if hashrate splits. Understand chain-split risk before you depend on a specific tip.
A time-bounded soft fork can address immediate data-incentive issues without permanently freezing every future script design. Expiry is part of the deployment parameters.
Some complex Taproot constructions and large data payloads are constrained during the window. Monetary payments that fit the limits continue; deeper trees and annex use are deferred or grandfathered via pre-activation coins.
Pre-activation UTXOs are exempt on a per-input basis. After activation, new outputs you create must satisfy the temporary rules to remain spendable on enforcing nodes. Always verify with software you trust.
Smaller pushes may still be possible within the 256-byte and output limits; the proposal aims to raise the cost and reduce convenience of bulk arbitrary data, not claim every encoding path is impossible.
Block space remains scarce. BIP-110 does not remove fees; it changes which constructions compete for that space while active.
Standard multisig and Lightning constructions that fit the temporary limits are intended to keep working. Review your specific script templates against the seven rules before relying on them during the window.
Executed OP_IF/OP_NOTIF in Tapscript fail while reduced-data rules are active. Prefer leaf-per-path designs.
Relay policy (e.g. historical OP_RETURN defaults) is not the same as consensus. BIP-110 is a consensus soft-fork proposal; nodes that do not enforce it will not reject the same blocks.
Much of the public debate followed policy changes around OP_RETURN size. BIP-110 responds at the consensus layer with temporary limits; see the articles list for background reading.
Before the mandatory window, signaling is voluntary. During mandatory signaling (if not already locked in), enforcing nodes treat non-signaling blocks as invalid in that height range.
After active_duration = 52,416 blocks from the height where the deployment becomes ACTIVE.
Complete = BIP text/status in the BIPs repo. Activated = locked in and ACTIVE on the chain under the deployment rules. This page tracks both separately.