Learn · Explainer 1 of 6
Understanding BIP-110
BIP-110, the Reduced Data Temporary Softfork (RDTS), is the August 2026 event this site covers first. This page is the overview: what it does, what it does not do, and how to read the live instruments on this site without mistaking a claim for a fact. If you read only one article in this series, read this one.
The short answer
BIP-110 is a temporary restrictive soft fork. The single most useful thing to hold onto is that it only ever removes possibilities. A block that is valid under BIP-110 is also valid to an unmodified Bitcoin node. The reverse is not guaranteed: an ordinary block can be perfectly valid today and still be rejected by a BIP-110 node once the rules are active.
"Temporary" is exact. The extra rules switch on at an activation height and switch off again after a fixed number of blocks (52,416, which is 26 signalling periods and nominally about a year). Expiry stops applying the rules to new blocks. It does not retroactively forgive a block that was invalid while the rules were active, and it does not merge two histories back together.
Four things that sound alike are actually different, and conflating them is the most common way to misread this event:
- Miner signalling: bit 4 set in a block header. This is a claim.
- Actual enforcement: a miner's validation and template stack really refusing invalid ancestry and transactions.
- Economic-node adoption: what exchanges, custodians, and wallet backends choose to follow and settle.
- Public-node counts: how many listening nodes advertise the rules, sampled by a crawl.
Setting bit 4 is not proof that a miner validated the new rules. Keeping these four apart is the whole discipline of reading this event correctly.
STARTED when it reaches height 961,632, it begins rejecting every block that does not signal bit 4. That mandatory-signalling interval runs from block 961,632 through 963,647 inclusive.A precise vocabulary
Calling one side "Core" and the other "Knots" is convenient but technically imprecise. An unmodified Bitcoin Core node does not permanently pick a permissive branch just because it does not enforce BIP-110: it accepts the restrictive branch too, and follows whichever valid chain has the most cumulative proof of work. This series uses these terms instead:
- BIP branch (restrictive branch): a history accepted by software enforcing BIP-110 at the relevant heights.
- Permissive branch: a history valid under the pre-BIP-110 rules but containing at least one block that BIP-110 software rejects.
- Unmodified node: a node applying the existing Bitcoin consensus rules without BIP-110.
- Signalling miner: a miner whose block header has the versionbits top pattern
001and bit 4 set. - Enforcing miner: a miner whose validation and template stack actually refuses BIP-110-invalid ancestry and transactions.
- Economic node: an exchange, custodian, merchant, wallet backend, or payment processor whose chain choice affects settlement or market naming.
The soft-fork relationship is asymmetric, and this asymmetry drives almost everything downstream. The set of BIP-valid blocks is a subset of the unmodified-valid set. An unmodified node can know about and select either branch. A BIP node cannot select a branch that contains a BIP-invalid ancestor, no matter how much cumulative work is built on top of it.
What BIP-110 restricts
While the deployment is ACTIVE, blocks are checked against seven additional restrictions. Every one of them narrows what a valid block may contain. None of them permits anything that was previously forbidden.
| # | Additional consensus restriction |
|---|---|
| 1 | Each new output scriptPubKey is at most 34 bytes. If its first opcode is OP_RETURN, the whole script may instead be at most 83 bytes. This is total script size, not 83 bytes of payload. |
| 2 | OP_PUSHDATA payloads and script-argument witness items are at most 256 bytes. The BIP16 redeemScript push in a scriptSig is exempt. Witness scripts and Tapleaf scripts are scripts rather than argument items, but pushes executed within them remain limited. |
| 3 | Spending an undefined witness version or undefined Tapleaf version is invalid. Witness v0, Taproot, and P2A are recognised exceptions. Creating an output using an undefined witness version remains valid. |
| 4 | A Taproot spend containing an annex is invalid. |
| 5 | A Taproot control block is at most 257 bytes, corresponding to a maximum Merkle path depth of 7. |
| 6 | A Tapscript containing any OP_SUCCESS opcode is invalid, even if execution would never reach it. |
| 7 | Executing OP_IF or OP_NOTIF in Tapscript is invalid, regardless of the condition result. Merely having the byte inside pushed data is not execution. |
The implementation treats the P2A exception as the empty-witness P2A form. A non-empty-witness P2A spend falls through to the upgradable-witness rejection when the RDTS flags apply. The full byte-level treatment, with the interactive matrix and script sandbox, is in the data-carriage article.
The rules also temporarily remove several protocol upgrade hooks. Undefined witness and Tapleaf versions and OP_SUCCESS cannot be used for a new soft fork while RDTS is active, a revealed Taproot path is limited to depth 7, and Tapscript constructions that execute OP_IF or OP_NOTIF must use another structure. The BIP itself notes possible effects on Miniscript edge cases and BitVM-like designs. Those are technical tradeoffs. The BIP's claims about spam, incentives, and Bitcoin's intended use are the authors' rationale, described in this series as a position held by participants, not adjudicated here.
Grandfathering is per input, not per transaction
An input spending a UTXO created below a branch's activation height is exempt from all of the new input and script rules. An input spending a UTXO created at or above that height is not exempt. In a mixed transaction, the implementation selects flags independently for each input.
Output rule 1 is different. Every output created in an active block is new, so its size is checked even if every input is grandfathered. Coinbase outputs are checked too. A transaction that spends an old UTXO can therefore still be invalid because it creates a 35-byte non-OP_RETURN output. Outputs created during STARTED or LOCKED_IN are still pre-activation UTXOs and receive the input-side exemption later.
Consensus and policy are intentionally different
The reviewed clients apply the RDTS script and output-size checks as ordinary mempool and mining policy even outside the ACTIVE period. A transaction can therefore be consensus-valid before activation or after expiry and still be refused by these nodes' mempools and block templates. This one fact is load-bearing for everything on the live dashboard:
Activation and the state machine
Activation follows a versionbits state machine with mainnet parameters compiled into the client. There is no supported configuration option to change them on mainnet.
| Parameter | Value |
|---|---|
| Deployment name | reduced_data |
| Version bit | 4, mask 0x10 |
| Start median-time-past | 1,764,547,200 (2025-12-01 00:00:00 UTC) |
| Timeout | None |
| Confirmation window | 2,016 blocks |
| Threshold | 1,109 of 2,016 (exactly 55.0099 percent) |
| Maximum activation height | 965,664 |
| Active duration | 52,416 blocks (26 periods) |
A qualifying signal needs both the normal versionbits top pattern 001 and bit 4. Setting bit 4 with a different top pattern does not count. State changes happen only at 2,016-block boundaries: reaching the threshold in the middle of a period has no immediate effect. State is also branch-relative, so a reorganization can replace the signalling history used at a boundary and cause a node to compute a different state on the alternative ancestry. The full state machine, including the mandatory-signalling subphase, is covered in the activation article.
The phases as heights
These are the five key heights. Heights are fixed and are the clock. The dates use the client-source-aligned projection (consistent with the reference client's own comment for the maximum-activation height); they drift with hashrate, and the Live rail recomputes them from the current tip. The technical walkthrough's independent projection, run from a different snapshot block, lands up to four days later for the same heights.
| Height | Approx. date | Milestone | Meaning |
|---|---|---|---|
| 957,600 | ~Jul 11 | Rehearsal split (passed) | Forknet dress-rehearsal split; evidence-capture baseline before the live window. |
| 959,616 | ~Jul 25 | Period 476 begins | The last voluntary signalling period before the mandatory height. |
| 961,632 | ~Aug 7 | Mandatory signalling begins | If still STARTED, every accepted BIP-branch header must signal or it is rejected. First decisive test of miner behaviour. |
| 963,648 | ~Aug 21 | Latest lock-in boundary | On an advancing valid branch, state becomes LOCKED_IN. As of the 2026-07 eCash announcement, the eCash drivechain fork is expected near this height, an unconfirmed alignment that could still shift. |
| 965,664 | ~Sep 1 | Maximum activation | The seven transaction rules become block-consensus rules on the branch, with per-input grandfathering. |
Activation is not itself a chain split. At height 965,664 the rules become consensus rules on that branch, but there is no automatic split simply because the state changes. A visible split needs an actually incompatible block, and for two live branches to persist it needs miners extending both valid ancestries.
How to read the live data
A split becomes visible from the bottom up: transaction-policy divergence between Core and Knots mempools first, then template divergence, then realized blocks, then rejection. The Live dashboard is arranged in that order. When you read it, keep these guards in mind, each one repeated on the panel it applies to:
- Header signalling is measurable but unauthenticated as readiness. Signalling is not hashrate.
- Service bit 27 on a peer is a handshake claim, not proof of enforcement.
- Reachable-node counts are a crawl sample, unrelated to hash power or economic weight.
- A mempool difference is a policy or timing difference, never on its own proof that a transaction would be rejected in a block.
What to watch
On the Live dashboard, this overview maps to every panel:
- Event clock: where the branch sits against the five key heights. Heights are the clock; dates are projections.
- Signalling by period: the current-period count against the 1,109 threshold. Bit 4 is a header claim, not enforcement.
- Mempool divergence (Core versus Knots): the bottom-up early warning. Absence is not rejection.
- Enforcement census: how many nodes advertise service bit 27. A crawl sample of flags, not hash power.
- Chain tips: during a fork, whether a second tip nodes disagree about has appeared.
Sources
This page restates the BIP-110 technical walkthrough sections The short answer, A precise vocabulary, What BIP 110 changes (including Grandfathering is per input and Consensus and policy are intentionally different), Activation parameters and state machine, and What to monitor in each phase. It states protocol behaviour, not predictions about miners or markets. Time-sensitive figures are rendered live or dated on the Live page.