A temporary consensus-level softfork to limit arbitrary data storage on Bitcoin — targeting inscriptions, and refocusing the network on its purpose as sound, permissionless money.
Real-time data from reachable listening Bitcoin nodes. Bitcoin Knots implements BIP110; Core (≥30.0) = versions after OP_RETURN limit removal; Core (<30.0) = versions with the traditional OP_RETURN limit.
Blocks during the temporary deployment are invalid if they violate any of these rules. Pre-activation UTXOs are exempt.
scriptPubKeys exceeding 34 bytes are invalid — except OP_RETURN which allows up to 83 bytes.OP_PUSHDATA* payloads and witness items exceeding 256 bytes are invalid (redeemScripts exempted).OP_SUCCESS* anywhere are invalid.OP_IF or OP_NOTIF are invalid.| Parameter | Value |
|---|---|
| Name | reduced_data |
| Bit | 4 |
| Start Time | December 1, 2025 |
| Threshold | 55% (vs BIP9 standard 95%) |
| Max Activation Height | 965,664 (~September 1, 2026) |
| Active Duration | 52,416 blocks (~1 year) |
| Timeout | None (height-based forced lock-in) |
| Mandatory Signaling | Blocks 961,632 – 963,647 |
Pre-signed Taproot transactions with OP_IF Tapleaves or trees deeper than 7 levels could become unspendable. Mitigation: 2-week grace period, pre-activation UTXO exemption.
BitVM relies on large Taproot trees (>128 leaves). The 257-byte control block limit may impede mainnet BitVM development during the softfork.
Miniscript compiler may produce OP_IF-based Tapleaves. Needs patching during the deployment.
55% miner threshold (vs Bitcoin's standard 95%) is a significant deviation — critics warn of precedent and potential network split risk.
Undefined witness versions and OP_SUCCESS* opcodes are disabled for the deployment's duration.
BIP acknowledges it can't fully prevent spam — but raises cost and sends a clear signal that data storage is unsupported.