BIP-110:Protecting Bitcoin's Purpose

Consensus (soft fork)

BIP-110:

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 Ohm•Created 2025-12-03•BSD-3-Clause

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

[](https://bip110.org/#key)

Key Points

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

Run BIP-110

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

View detailed installation instructions

Live BIP-110 signaling

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

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

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

Why is this proposal temporary?

Are there any tradeoffs?

Is there any risk of funds being frozen or lost?

Won't spammers just spread their data over multiple fields?

Why not let the fee market manage data storage?

Why limit scriptPubKeys to 34 bytes?

Does this break multisig?

Does the 256-byte limit restrict multisig to 7 keys?

Is this a slippery slope toward banning use cases?

Does this solve spam completely?

Does this affect the UTXO set?

Does this affect the Lightning Network?

Why is OP\_IF restricted in Tapscripts?

How is this different from relay policy filters?

Why does the OP\_RETURN limit removal matter?

Is this optional for miners?

What happens when the deployment expires?

Articles

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

CAPTURE: The NetworkPart one documents the people, institutions, and incentives that hodlonaut argues shaped Bitcoin Core's informal power structure before the OP\_RETURN controversy.hodlonaut•Mar 27, 2026CAPTURE: The LeverPart two examines how funding, review influence, and institutional weight can sideline inconvenient contributors without a formal governance process.hodlonaut•Apr 29, 2026CAPTURE: The MergePart 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.hodlonaut•Jun 15, 2026The 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 Carvalho•Feb 2026

Code WalkthroughFull Reading Path

Important Considerations

Honest assessment of limitations and risks

Fund Safety

Funds are at risk only if ALL of these conditions are met: the UTXO is P2TR, it's in a pre-signed transaction, it must be confirmed AND spent during the one-year deployment, the selected Tapleaf violates the new rules, AND there are no other valid spending paths. In practice, this scenario is extremely unlikely.

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