bitcoin-forks.org August 2026 consensus-event monitor

Learn · Explainer 2 of 6

What the seven rules restrict (data carriage)

This is the detailed article on BIP-110's seven transaction rules. It is byte-exact where the specification is byte-exact. Read Understanding BIP-110 first for the vocabulary and the overview. Read this when you need to know precisely what an active BIP-110 block will and will not accept, which is the question that matters to wallet developers, miners, and anyone building or classifying transactions in the window.

These rules restrict data carriage: the practice of embedding arbitrary data in transaction outputs, witnesses, and scripts. The name comes from that intent, but the rules are defined mechanically in bytes and opcodes, not by intent, and this article describes the mechanics. Whether restricting data carriage is desirable is a position held by participants, argued on both sides, and not adjudicated here.

Figure slot 01 Ordinals Are Not Inscriptions
The terminology the debate runs on: ordinal numbering of satoshis is a separate idea from the inscription envelopes the rules actually constrain.
figure pending
Figure slot 02 Transaction X-Ray
An annotated transaction showing where each of the seven rules applies: output scripts, scriptSig pushes, witness items, control blocks, and Tapscript.
figure pending

The seven rules, one at a time

While the deployment is ACTIVE, blocks are checked against seven additional restrictions. Each one only ever narrows the set of valid blocks. The table below is the specification-level statement; the sections after it give the byte-level detail.

# 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.
Figure slot 03 Seven-Rule Calipers
The seven restrictions drawn as a set of calipers, each measuring a different structural feature of a transaction.
figure pending

Rule 1: output script size

Every new output scriptPubKey may be at most 34 bytes. The single exception is a script whose first opcode is OP_RETURN: such a script may be up to 83 bytes total. The 83 bytes are the whole script size, including the OP_RETURN opcode and any push opcodes, not 83 bytes of embeddable payload. A 34-byte cap is exactly the size of the largest standard output types (P2TR and P2WSH are 34 bytes; P2PKH, P2SH, P2WPKH are smaller), and the OP_RETURN allowance preserves a small labelled-data output.

This is the only rule that applies to outputs rather than inputs, and it is the one that survives grandfathering (see below). A 35-byte non-OP_RETURN output is invalid in an active block even if every input to the transaction is a grandfathered pre-activation coin.

Rule 2: push-payload and witness-item size

Any OP_PUSHDATA payload, and any witness item that is a script argument, may be at most 256 bytes. Two clarifications matter:

  • The BIP16 redeemScript push in a scriptSig is exempt. A P2SH redeemScript can therefore still exceed 256 bytes when pushed as the final scriptSig element.
  • Witness scripts (the P2WSH witnessScript) and Tapleaf scripts are treated as scripts, not as argument items, so the script itself is not capped by this rule. But pushes that execute inside those scripts are still limited to 256 bytes.

The effect is a cap on the size of any single embedded data blob carried as a push, which is the mechanism most inscription-style data carriage relies on.

Figure slot 04 Classic versus Bare Inscriptions
How the classic envelope inscription and the bare-push variant differ in structure, and where rule 2's 256-byte push cap bites each.
figure pending
Figure slot 05 Ord 4545 Streaming Envelope
A worked example of a large streaming inscription envelope and which of its pushes exceed the 256-byte limit under RDTS.
figure pending

Rules 3 to 7: witness and Tapscript restrictions

These five rules all constrain how coins are spent, which is why they are all subject to per-input grandfathering.

  • Rule 3, undefined versions. Spending an output that uses an undefined witness version or an undefined Tapleaf version is invalid. Witness v0 (SegWit), Taproot, and P2A are the recognised exceptions. Note the asymmetry: creating an output that uses an undefined witness version is still valid; only spending one is restricted. 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 while the RDTS flags apply.
  • Rule 4, Taproot annex. A Taproot spend that includes an annex is invalid. The annex is an optional, currently-unused extension field in a Taproot witness.
  • Rule 5, control-block depth. A Taproot control block may be at most 257 bytes. A control block is 33 bytes plus 32 bytes per Merkle path step, so 257 bytes corresponds to a maximum Merkle path depth of 7. Deeper script trees cannot be revealed while the rules are active.
  • Rule 6, OP_SUCCESS. A Tapscript containing any OP_SUCCESS opcode is invalid, even if execution would never reach that opcode. The presence of the byte in the script is enough. OP_SUCCESS opcodes are the currently-reserved upgrade opcodes in Tapscript.
  • Rule 7, OP_IF and OP_NOTIF. Executing OP_IF or OP_NOTIF in Tapscript is invalid, regardless of whether the condition evaluates true or false. The distinction is execution, not presence: having the OP_IF byte sitting inside a data push is not execution and is not a violation. A Tapscript that reaches an OP_IF on the executed path fails.

Rules 3, 6, and 7 also close upgrade hooks for the duration: undefined versions and OP_SUCCESS are exactly the mechanisms a future soft fork would use, and they cannot be used while RDTS is active.

Grandfathering is per input, not per transaction

This is the rule that most often trips up analysis. Exemption from the input and script rules (rules 2 through 7) is decided per input, using the height at which each input's UTXO was confirmed on the selected ancestry.

  • An input spending a UTXO created below that branch's activation height is exempt from all the new input and script rules.
  • An input spending a UTXO created at or above the activation height is not exempt.
  • In a mixed transaction, the implementation selects flags independently for each input. One input can be grandfathered while another in the same transaction is checked.

Output rule 1 does not grandfather. Every output created in an active block is new, so its size is always checked, coinbase outputs included. The consequences are precise:

  • A pre-activation UTXO cannot be made BIP-only or permissive-only merely by using a witness construction that rules 2 through 7 forbid. Its input is grandfathered, so the construction is simply exempt.
  • A post-activation transaction that spends an old UTXO can still be made permissive-only, by violating output rule 1 (for example creating a 35-byte non-OP_RETURN output), subject to relay and miner policy.
  • Outputs created during STARTED or LOCKED_IN are still pre-activation UTXOs, so they receive the input-side exemption later, once the rules are active.
  • A reorganization that moves the same funding transaction from below the activation height to at or above it changes its outputs from grandfathered to restricted. Grandfathering follows the confirmed coin height on the selected ancestry, so it is branch-relative like everything else in this event.
  • At EXPIRED, the consensus restrictions stop for all new spends, but local mempool policy can remain stricter.
Figure slot 07 Activation and Grandfathering
A timeline of coin ages showing which inputs are grandfathered at activation and why every new output is checked regardless.
figure pending

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. This is a deliberate design choice, and it has consequences that matter for everything you see on the Live dashboard:

  • Pre-activation transaction relay is already partially partitioned by policy. A transaction that violates the RDTS-style checks may be refused by a BIP node's mempool today, long before the rules are consensus rules.
  • A consensus-valid spend of a grandfathered input may need direct miner submission if ordinary relay policy rejects it.
  • Changing a policy option cannot make an active-period consensus-invalid block valid. Policy can only narrow what a node relays or mines, never widen the set of valid blocks.
  • Seeing a transaction absent from a BIP node's mempool does not prove it would be invalid in a block at the current height.

The rule to carry from this: policy can make a node refuse transactions that consensus would allow; policy cannot make a node accept a block that active consensus forbids.

Figure slot 06 Consensus versus Knots Policy
The same transaction evaluated against active RDTS consensus and against Knots relay and template policy, showing where the two diverge.
figure pending
Figure slot 08 Storage Consequences
The downstream storage effect the authors cite as rationale: how the rules bound the data a single block can carry.
figure pending

Try it: the interactive tools

Two interactive tools accompany this article. The Data-Carriage Matrix and Atlas lets you cross-reference each of the seven rules against transaction and output types and see which combinations are restricted, grandfathered, or unaffected. The Script Lab lets you build an input or output and test it against both active RDTS consensus and Knots policy, so you can see for yourself where a given push size, control-block depth, or Tapscript construction crosses a limit.

Interactive figure slot Data-Carriage Matrix and Atlas
Interactive cross-reference of the seven rules against transaction and output types, with grandfathering state.
figure pending
Interactive figure slot Script Lab
Build a script or witness and test it against active RDTS consensus and against Knots relay policy side by side.
figure pending

What to watch

On the Live dashboard, the data-carriage rules are what the mempool-divergence panel is actually measuring. When Core and Knots mempools disagree about a transaction, it is usually because that transaction crosses one of these limits as Knots policy even before activation. Watch the mempool-divergence panel with the guardrail in mind: absence from the Knots mempool is a policy outcome (one of these seven checks applied as relay policy), not a consensus verdict. After activation, the split-telemetry panel would show a realized RDTS-invalid block only if one is actually mined; the rule difference stays latent until then.

Sources

This page restates the BIP-110 technical walkthrough sections What BIP 110 changes (the seven-rule table and the surrounding notes on upgrade hooks), Grandfathering is per input, not per transaction, and Consensus and policy are intentionally different. Byte counts, the 34/83/256/257-byte limits, and the depth-7 figure are quoted from that walkthrough, which draws them from the BIP-110 text and the reviewed Knots and standalone-client source.