BIP-110
Consensus (soft fork)

BIP-110:
Protecting Bitcoin's Purpose

Temporarily limit the size of data fields at the consensus level, in order to correct distorted incentives caused by standardizing support for arbitrary data, and to refocus priorities on improving Bitcoin as money.

Read the Full BIP
By Dathon OhmCreated 2025-12-03BSD-3-Clause

BIP-110: Also referred to as RDTS (BIP-444)

Key Points

A temporary, focused intervention to protect Bitcoin's core mission

Temporary Protection

A one-year deployment that can be refined or extended based on community feedback.

Limits Data Storage

Restricts arbitrary data embedding that burdens node operators and diverts resources.

Preserves Monetary Use

All known monetary use cases remain fully functional and unaffected.

Refocuses Bitcoin

Signals that Bitcoin's priority is being the world's best money, not data storage.

Run BIP-110

Support BIP-110 by running a node that signals for activation

Bitcoin Knots

Official Bitcoin Knots release with BIP-110/RDTS support

Start9

Official Start9 package with an RDTS activation task

Umbrel

One-click install from the Umbrel app store

myNode

Custom Bitcoin Version option with RDTS confirmation

Parmanode

Simple one-click style install for Parmanode users

Docker

For advanced users running their own Docker infrastructure

View detailed installation instructions

Live BIP-110 signaling

Track current miner support, period progress, and the remaining signals needed for activation.

Loading live status
Full monitor

Loading

N/A

Waiting for monitor data

Loading

N/A

Waiting for monitor data

Loading

N/A

Waiting for monitor data

Protecting Bitcoin's Purpose

Starting with the 'inscription' hack in 2022, a trend emerged around embedding arbitrary data into Bitcoin transactions. This creates unnecessary burdens on node operators and diverts development focus from Bitcoin's fundamental purpose: being sound, permissionless, borderless money.

Data storage competes unfairly with payments, making Bitcoin transactions unnecessarily costly. This encourages reliance on third-party payment processors, making Bitcoin payments easier to censor.

By limiting data storage, this proposal liberates developers from endless scope creep, enabling them to focus on what's really important: Bitcoin's success as money.

Evidence archive

WTF Happened in Feb 2023?

Review the blockspace, fee pressure, and node-resource data behind the February 2023 spam wave.

“Bitcoin should do one thing, and do it well.”

How It Works

Simple restrictions that preserve all monetary use cases while limiting data abuse

Output Size Limits

New outputs are limited to 34 bytes, except OP_RETURN which allows up to 83 bytes.

Data Push Limits

Data pushes and witness elements are limited to 256 bytes maximum.

Witness Version Restrictions

Only well-defined witness versions (v0 and Taproot) can be spent during the deployment.

Taproot Restrictions

Taproot annexes, large control blocks, and certain opcodes are temporarily restricted.

Inputs spending UTXOs created before activation are permanently exempt from these rules — there is no deadline to move existing funds.

Inspect the implementation

The commented walkthrough ties each rule to the tagged Bitcoin Knots source.

Open code walkthrough

Common Questions

Answers to frequently asked questions about BIP-110

Articles

Start with the background, then continue into the BIP-110 analysis

CAPTURE: The Network

Part one documents the people, institutions, and incentives that hodlonaut argues shaped Bitcoin Core's informal power structure before the OP_RETURN controversy.

hodlonautMar 27, 2026

CAPTURE: The Lever

Part two examines how funding, review influence, and institutional weight can sideline inconvenient contributors without a formal governance process.

hodlonautApr 29, 2026

CAPTURE: The Merge

Part three of hodlonaut's CAPTURE series traces how a documentation change, Luke's filter patch, and the OP_RETURN uncap PRs built toward Bitcoin Core's contested 2025 merge.

hodlonautJun 15, 2026

The OP_RETURN Limit Removal: Gaslighting or Technical Necessity?

Melvin Carvalho's research report weighs the stated technical case for removing Bitcoin's 80-byte OP_RETURN limit against process concerns, conflicts of interest, and BIP-110's response.

Melvin CarvalhoFeb 2026
Code WalkthroughFull Reading Path

Important Considerations

Honest assessment of limitations and risks

BitVM & Advanced Contracts

The 257-byte control block limit constrains large Taptrees. Advanced smart contracts like BitVM may need to wait until expiry or use testnet/sidechains.

Wallet Compatibility

Some wallets like Nunchuk allow arbitrary Miniscript and may create Tapleaves with OP_IF. These wallets would need to update before activation to stop creating Tapleaves with OP_IF. UTXOs created before activation are permanently exempt, so existing funds are unaffected regardless of wallet software. Wallet developers have until mandatory lock-in (~August 2026) plus a two-week grace period to update. Even after activation, only newly created UTXOs are subject to the new rules. Updating is straightforward: split OP_IF branches into separate tapleaves, which is already best practice for Taproot.

Upgrade Hooks

Upgrade hooks via undefined witness versions and OP_SUCCESS are unavailable during deployment. Since softforks take over a year to coordinate, this shouldn't be a practical issue.

Deployment Timeline

Key dates and milestones for BIP-110 activation

December 1, 2025

Signaling Begins

Miners signal readiness using bit 4. Early lock-in if 55% of blocks signal in a retarget period (1109/2016).

~August 2026

Mandatory Lock-in

If not locked in early, mandatory signaling begins — blocks that don't signal are rejected as invalid, guaranteeing lock-in.

2 weeks post lock-in

Activation

New consensus rules take effect. Blocks violating these rules are rejected by all enforcing nodes. Pre-existing UTXOs remain permanently exempt.

~1 year after activation

Expiry

52,416 blocks after activation, all restrictions lift automatically.

Signaling uses bit 4 • 55% threshold for early lock-in • Mandatory signaling guarantees activation