This PR implements consensus changes and deployment parameters for BIP-110 (ReducedData Temporary Softfork). It is built on top of #34929, which implements the versionbits extensions needed for BIP-110’s activation. I will rebase this PR on master once #34929 is merged.
Background
Following BIP-110’s initial proposal in October 2025, and shortly before its acceptance into the BIPs repo, the first version of the official activation client for BIP-110 was released at the end of January as a fork of Bitcoin Knots. This client has proven immensely popular, and now comprises over 8 percent of listening nodes and over 10 percent of all nodes on the network, after just 2 months. While a few bugs were found early on, they were all swiftly resolved and the code has now been stable for several weeks.
For those new to BIP-110, it is a proposal to temporarily limit the size of data fields at the consensus level, in order to reject the standardization of data storage as a supported use case at the consensus level. It achieves this by temporarily limiting all officially supported methods of data storage (and methods of data storage that could be or become perceived as officially supported) to 256 bytes or less, while preserving all known monetary use cases.
This has several desirable effects, including but not limited to:
- Reducing demand for arbitrary data storage by frustrating attempts to monetize and gamify arbitrary data.
- Bringing consensus and policy back into closer alignment, by restoring policy limits from a few years ago in consensus.
- Protecting the decentralization of the node network by eliminating unnecessary costs and (in some cases, extreme) risks introduced by making arbitrary data storage an officially supported function of Bitcoin.
- Making Bitcoin better money by preventing Bitcoin payments from having to compete at an unfair disadvantage against gamified data spam.
Motivation
Due to BIP-110’s rising popularity, it seems prudent to augment Core with the ability to enforce the new rules, so that once BIP-110 is activated, Core users will remain secure because their nodes will follow the valid chain. While BIP-110’s mandatory signaling period is not until August, it allows for early activation if the threshold of 55% of hashpower signaling is reached before the deadline, so BIP-110’s activation could be imminent (as soon as a few weeks from now). Given this, I humbly suggest that we prepare sooner rather than later. My sincere hope is that BIP-110’s activation will heal the divide in our community and allow us all to get back to building Bitcoin into history’s greatest money.
Deployment
BIP-110 uses the versionbits extensions from #34929:
- Bit: 4
- Start: December 1, 2025 (epoch 1764547200)
max_activation_height: 965664 (~September 1, 2026) - mandatory activation deadlineactive_duration: 52416 blocks (~1 year) - temporary deployment, transitions to EXPIRED after the active periodthreshold: 1109 / 2016 (55%)
The deployment is temporary: after active_duration blocks, the rules expire and the EXPIRED state is terminal.
Features
Consensus rules (when DEPLOYMENT_REDUCED_DATA is active)
- Output scripts limited to 34 bytes (OP_RETURN limited to 83 bytes)
- Data push size limit reduced to 256 bytes, except BIP16 redeemScript
DISCOURAGE_UPGRADABLE_WITNESS_PROGRAM,DISCOURAGE_UPGRADABLE_TAPROOT_VERSION,DISCOURAGE_OP_SUCCESSenforced at consensus level- Taproot annex forbidden
- Taproot control block limited to 257 bytes (tree depth 7)
OP_IF/OP_NOTIFforbidden in Tapscript- Empty witness required for P2A spends
- UTXO-height exemption: inputs spending UTXOs created before activation are exempt from script rules
Policy
- The above rules are enforced unconditionally in policy
Tests
- Unit/fuzz tests: script verification tests for each new rule,
CheckTxInputsRules::OutputSizeLimitenforcement, fuzz test updates for REDUCED_DATA flag feature_rdts.py: tests each consensus rule individually, policy enforcement before activation, consensus enforcement after activationfeature_reduced_data_utxo_height.py: pre-activation UTXO exemption, post-activation enforcement, cache-poisoning preventionfeature_reduced_data_temporary_deployment.py: full deployment lifecycle (DEFINED -> STARTED -> LOCKED_IN -> ACTIVE -> EXPIRED), consensus rules enforced during active period, rules stop after expiry, chain split/reorg behavior
Commit structure (29 commits across 2 PRs)
The first 7 commits (PR 1, #34929) are versionbits extensions: max_activation_height, active_duration/EXPIRED state, mandatory signaling enforcement, -vbparams support, and tests. These are included here temporarily so CI passes; they will be dropped if and when PR 1 merges.
The remaining 22 commits (this PR) introduce the script validation rules first (initially unused), then wire up DEPLOYMENT_REDUCED_DATA activation, then add the remaining consensus features (coinbase output size limits, mandatory DISCOURAGE flag enforcement, and UTXO height exemption), and finally the functional tests. Every commit builds and passes all tests. One commit (a628bef9bf) is intentionally large because it breaks many tests, so test adaptations that must land atomically are bundled.
Size
~200 lines non-test C++/H (excluding activation infrastructure in #34929). For comparison against activated soft forks:
| Non-test C++/H | Soft fork | PRs |
|---|---|---|
| 3209 | SegWit (BIP 141/143/144) | 9 |
| 2903 | Taproot (BIP 340/341/342) | 11 |
| 1005 | CSV (BIP 68/112/113) | 8 |
| ~375 | BIP-110 (both PRs) | 2 |
| 143 | CLTV (BIP 65) | 2 |
The closest apples-to-apples comparison is CSV, which similarly included new reusable activation infrastructure (BIP 9).
| CSV (BIP 68/112/113) | BIP-110 | |
|---|---|---|
| Consensus rules | 120 | ~47 |
| Activation infrastructure | 605 | ~175 |
| Other (RPC, policy, etc.) | 280 | ~100 |
| Total non-test C++/H | 1005 | ~375 |
| PRs | 8 | 2 |
BIP-110 is roughly a third of the size of CSV across both PRs.
