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)
A temporary, focused intervention to protect Bitcoin's core mission
Support BIP-110 by running a node that signals for activation
Track current miner support, period progress, and the remaining signals needed for activation.
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.”
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.
Answers to frequently asked questions about BIP-110
Start with the background, then continue into the BIP-110 analysis
Part one documents the people, institutions, and incentives that hodlonaut argues shaped Bitcoin Core's informal power structure before the OP_RETURN controversy.
Part two examines how funding, review influence, and institutional weight can sideline inconvenient contributors without a formal governance process.
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.
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.
Technical responses to arguments against BIP-110.
Response to BlockSlop
A late upgrade to BIP-110 can leave nodes on different chains even though both nodes report BIP-110 as enabled, so the activation client has a consensus bug.
The RDTS checks work. The report describes reusing chainstate after mixing non-enforcing and enforcing software—a late-upgrade footgun, already handled both ways by Start9 packaging, with the same class of mess if you switch away from BIP-110.
Response to OP_PLENTY
Because arbitrary payloads can still be encoded as valid Tapscript under BIP-110, limits on recognized data carriers are ineffective.
OP_RETURN is Bitcoin's explicit data outlet and contains payload bytes directly. OP_PLENTY repurposes executable opcodes, which custom software must decode to recover the original bytes.
Honest assessment of limitations and risks
Key dates and milestones for BIP-110 activation
Miners signal readiness using bit 4. Early lock-in if 55% of blocks signal in a retarget period (1109/2016).
If not locked in early, mandatory signaling begins — blocks that don't signal are rejected as invalid, guaranteeing lock-in.
New consensus rules take effect. Blocks violating these rules are rejected by all enforcing nodes. Pre-existing UTXOs remain permanently exempt.
52,416 blocks after activation, all restrictions lift automatically.
Signaling uses bit 4 • 55% threshold for early lock-in • Mandatory signaling guarantees activation
