BIP-110: Temporarily Limiting Arbitrary Data
THE PROPOSAL
"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."
CONTEXT
Developed as a reaction to Bitcoin Core v30 removing the long-standing
83-byte OP_RETURN standardness limit. Previously known as BIP-444. Proposes 7 consensus-level restrictions on arbitrary data for approximately one year.KEY DISTINCTION
This is a consensus rule change, not just a policy/standardness change. If activated, nodes would reject blocks containing transactions that violate these rules — miners who include them would have their blocks orphaned.
The 7 Consensus Rules
CATEGORY 1
Output Size Limits
New outputs limited to 34 bytes, except OP_RETURN which allows up to 83 bytes.
CATEGORY 2
Data Push Limits
Data pushes and witness elements limited to 256 bytes maximum.
CATEGORY 3
Witness Version Restrictions
Only well-defined witness versions (v0 and Taproot) can be spent during deployment.
CATEGORY 4
Taproot Restrictions
No Taproot annex. Control blocks ≤257 bytes (128 script leaves). No OP_SUCCESS*. No OP_IF / OP_NOTIF in tapscripts.
GRANDFATHERING
Pre-existing UTXOs are exempt — "Inputs spending UTXOs that were created before the activation height are exempt from the new rules."
Deployment Timeline & Signaling
December 1, 2025
Signaling Period Starts — miners can begin signaling support using bit 4.
~September 1, 2026
Maximum Activation Height — Block 965664. Requires 55% miner signaling (1109/2016 blocks).
~1 Year After Activation
Rules expire automatically. Temporary restriction by design.
0 blocks
have signaled for BIP-110 activation
Not a single block — not even from Ocean or other aligned pools
Running the Client ≠ Having a Vote
🎭 VIRTUE SIGNALING
Running a BIP-110 compatible client (Bitcoin Knots) has zero influence on whether the soft fork activates. The 55% activation threshold counts only miner-produced blocks — not nodes. Your node doesn't vote; it just pre-commits to enforce rules if miners activate them.
THE NUMBERS THAT DON'T MATTER
~2.38% of reachable nodes (~583 of 24,481) are running BIP-110 software. This figure is frequently cited by supporters as evidence of "growing support" — but it contributes exactly nothing to the activation mechanism. It's a sentiment poll with no governance weight.
CONTRAST: REAL UASFs
BIP-148 (SegWit UASF) nodes actually rejected non-signaling blocks — creating economic pressure on miners. BIP-110 nodes don't reject anything until/unless miners hit 55%. It's "user-activated" in name only; miners still hold all the cards.
WHAT YOU'RE ACTUALLY DOING
Running the client is a statement of intent — "I will enforce these rules if they activate." It signals ideological alignment with the proposal's goals, but has no mechanism to make activation more likely. It's solidarity, not sovereignty.
Arguments Against
⚡ TRIVIALLY BYPASSABLE
Peter Todd embedded the entire BIP-110 proposal text on-chain in a single transaction — while fully complying with the proposal's own restrictions. The data size limits can be worked around by encoding data across multiple smaller fields.
🔒 CONFISCATION RISK
Greg Maxwell warned that there likely exist chains of not-yet-confirmed transactions that would violate the new rules. While the proposal exempts pre-existing UTXOs, the exemption doesn't cover pre-signed spending paths that create new outputs violating the rules. Funds could become unspendable.
💥 COLLATERAL DAMAGE
BitVM & Advanced Contracts — the 257-byte control block limit constrains large Taptrees needed for complex covenant and bridge constructions.
🐛 BUGGY IMPLEMENTATION
The initial release client was found to be rife with bugs — the test suite was failing on release.