Skip to main content

BIP-110 / RDTS Integration

Since v29.3.knots20260508 (May 2026), Bitcoin Knots ships the BIP-110 soft fork — called the Reduced Data Temporary Softfork (RDTS) throughout the Knots source and release notes. This page covers the operational side: which builds enforce it, how the confirmation mechanism works, the exact configuration entries and build flags, and how to monitor your node's enforcement status.

For what BIP-110 actually restricts, the activation timeline, and the surrounding debate, see BIP-110: The Reduced Data Soft Fork.

Understand what you are running

BIP-110 is a consensus change with minimal miner signaling so far. If it activates on schedule without broad hashrate support, enforcing nodes can end up on a minority chain — see chain split risk. Know which build you are running and what it will enforce before the activation window (September 2026).

The Two Builds​

Bitcoin Knots v29.3 is published in two variants:

BuildRDTS enforcementWho it's for
v29.3.knots20260508Yes — enforces the RDTS deployment on its scheduleUsers who accept (or want to support) the upgrade
v29.3.knots20260507No — RDTS rules are never enforcedUsers not ready to adopt RDTS
Enforcement is a property of the build, not the config

A common misconception is that consensusrules=rdts switches enforcement on and off. It does not. In the standard 20260508 build, the RDTS deployment schedule is enforced whether or not you set it — the option records your explicit confirmation and silences warnings. The way to run v29.3 without RDTS enforcement is to run the 20260507 build.

The release notes take the position that declining the upgrade does not "reject" it: to actually reject an upgrade that gains network adoption, you would need software designed to split away from the upgraded network. Critics dispute the framing in the other direction — that a soft fork without hashrate majority splits itself away. Both perspectives are covered in the main guide.

The Confirmation Mechanism​

The standard build asks every user for explicit confirmation, and behaves differently until it gets it:

GUI (bitcoin-qt)​

On first startup after upgrading, the GUI shows a "BIP110/RDTS Network Upgrade" dialog explaining the change:

  • OK — your consent is written to settings.json ("consensusrules": "rdts") so you are not asked again.
  • Abort — the GUI exits. It does not run unconfirmed.

Daemon (bitcoind)​

bitcoind starts and enforces RDTS even without confirmation, but logs an error every hour until you confirm:

This software applies the BIP110/RDTS network upgrade, which fixes critical
vulnerabilities, but explicit user confirmation has not been configured.
To confirm this upgrade and dismiss this warning, add to your bitcoin.conf
file: consensusrules=rdts

Test networks​

Confirmation is not required on test chains (testnet, signet, regtest).

Configuration Entries​

Confirmation can be recorded in any of the usual configuration channels:

bitcoin.conf
consensusrules=rdts
# Or as a command-line argument
bitcoind -consensusrules=rdts
settings.json (written automatically when you click OK in the GUI)
{
  "consensusrules": "rdts"
}

From bitcoind -help-debug:

-consensusrules=<rules>
       Enforce the specified consensus rules (default: none). Must be rdts to
       use this software.

There is no environment variable for this — Bitcoin Knots does not read consent (or any options) from the environment.

For source builds, the consent behavior is fixed at compile time by a required CMake option:

cmake -B build -D RDTS_CONSENT=RUNTIME_WARN
ValueBehavior when unconfirmed
RUNTIME_WARNEnforces RDTS; warns hourly until consensusrules=rdts is set. This is what official release binaries use.
RUNTIME_CHECKRefuses to start: bitcoind exits with "User has not consented to supported protocol rules." (The GUI internally escalates RUNTIME_WARN to this, which is why it prompts.)
IMPLICITConsent is assumed at installation; no prompt, no warning. Intended for packagers whose install process obtains consent.
UNSUPPORTED_UNSAFE_NO_ENFORCEMENTDoes not enforce RDTS, warns hourly, and drops the NODE_REDUCED_DATA service advertisement. The build system explicitly labels this unsupported ("Use at your own risk").

Configuring without setting RDTS_CONSENT fails with an error listing the options. There is also a debug-only runtime override, -rdts_consent_flag=<n>, for testing the consent modes — it is hidden behind -help-debug and not meant for production use.

Deployment Parameters (Mainnet)​

Source-verified from src/kernel/chainparams.cpp:

ParameterValue
Deployment namereduced_data
Signal bit4
Signaling startDecember 1, 2025 (timestamp 1764547200)
Early lock-in threshold1,109 of 2,016 blocks (55%)
Maximum activation height965,664 (~September 1, 2026)
Active duration52,416 blocks (~1 year)
Expiry height1,018,080

Monitoring Your Node​

Deployment status​

bitcoin-cli getdeploymentinfo

Look for the reduced_data deployment in the result. During signaling it reports BIP9-style status (started, locked_in, active) and per-period statistics, including how many blocks in the current window are signaling bit 4.

Service advertisement​

Nodes enforcing RDTS advertise a dedicated service bit, NODE_REDUCED_DATA (bit 27):

# Your own node's services
bitcoin-cli getnetworkinfo | jq '.localservicesnames'

# Which of your peers advertise RDTS enforcement
bitcoin-cli getpeerinfo | jq '.[] | {addr, rdts: (.servicesnames | contains(["REDUCED_DATA"]))}'

This is also how network crawlers count BIP-110-capable nodes — see the node statistics resources for a live NODE_REDUCED_DATA query.

Startup logs​

debug.log records the consent state at startup, e.g. User already consented to 'rdts' consensus rules (in config), and carries the hourly warnings described above when unconfirmed.

For Miners​

Block templates produced by an RDTS-enforcing build signal bit 4 automatically while the deployment is in its signaling phase — this is standard BIP9 behavior (ComputeBlockVersion sets the bit for any deployment in the started or locked_in state). In other words, a miner running the standard 20260508 build signals for BIP-110 by default; a miner who does not want to signal needs the non-RDTS 20260507 build. Ocean pool has been signaling since March 2026 — see the mining guide and current signaling levels.

See Also​