ReducedData Temporary Softfork (BIP-110/RDTS)

[dathonohm]

(Also submitted upstream as bitcoin/bitcoin#34930.)

This PR implements consensus changes and deployment parameters for BIP-110 (ReducedData Temporary Softfork). It is built on top of #1 (upstream), which implements the versionbits extensions needed for BIP-110's activation. I will rebase this PR on master once #1 (upstream) 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 (this figure is artificially inflated) 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 #1 (upstream):

• Bit: 4
• Start: December 1, 2025 (epoch 1764547200)
• max_activation_height: 965664 (~September 1, 2026) - mandatory activation deadline
• active_duration: 52416 blocks (~1 year) - temporary deployment, transitions to EXPIRED after the active period
• threshold: 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_SUCCESS enforced at consensus level
• Taproot annex forbidden
• Taproot control block limited to 257 bytes (tree depth 7)
• OP_IF/OP_NOTIF forbidden 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::OutputSizeLimit enforcement, fuzz test updates for REDUCED_DATA flag
• feature_rdts.py: tests each consensus rule individually, policy enforcement before activation, consensus enforcement after activation
• feature_reduced_data_utxo_height.py: pre-activation UTXO exemption, post-activation enforcement, cache-poisoning prevention
• feature_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, #1 (upstream)) 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 #1 (upstream)). 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.