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.
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.
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 exempt from these rules.
Common Questions
Answers to frequently asked questions about BIP-110
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 using Miniscript may create Tapleaves with OP_IF. The grace period and exemption for pre-existing UTXOs mitigates this risk.
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 Period Starts
Miners can begin signaling support using bit 4.
Maximum Activation Height
Block 965664. Activation requires 55% miner signaling (1109/2016 blocks).
Activation
New rules take effect. Grace period allows users to prepare.
Expiry
52,416 blocks after activation, restrictions expire automatically.
Signaling uses bit 4 • Activation requires 55% threshold (1109/2016 blocks)