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.
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
Direct download of the BIP-110 enabled Bitcoin Knots release
Start9
One-click install for Start9 v0.3 and v0.4
Umbrel
One-click install from the Umbrel app store
myNode
One-click install for myNode servers
Parmanode
Simple one-click style install for Parmanode users
Docker
For advanced users running their own Docker infrastructure
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.
“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.
Common Questions
Answers to frequently asked questions about BIP-110
Articles
In-depth reading on BIP-110 and why it matters
BIP 110 Neutralizes Bitcoin's Biggest Legal Attack Vector
Arbitrary data on the blockchain creates untested legal exposure for every node operator on the network. BIP 110 is the protocol-level fix that shrinks it.
Bitcoin Has a Squatter Problem. BIP 110 Is the Eviction Notice.
Why a temporary soft fork is the most important thing happening in Bitcoin right now, and why the FUD about it is dead wrong.
BIP-110: The Temporary Softfork
A deep-dive game theory analysis and code audit examining what the mechanism design reveals and what the code actually does.
BIP-110: The Corrected Analysis
Issue #5's simulation had bugs. The real numbers are bigger and more interesting.
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
Signaling Begins
Miners signal readiness using bit 4. Early lock-in if 55% of blocks signal in a retarget period (1109/2016).
Mandatory Lock-in
If not locked in early, mandatory signaling begins — blocks that don't signal are rejected as invalid, guaranteeing lock-in.
Activation
New consensus rules take effect. Blocks violating these rules are rejected by all enforcing nodes. Pre-existing UTXOs remain permanently exempt.
Expiry
52,416 blocks after activation, all restrictions lift automatically.
Signaling uses bit 4 • 55% threshold for early lock-in • Mandatory signaling guarantees activation