A temporary one-year soft fork aimed at “spam” transactions has turned into the sharpest governance fight Bitcoin has had in years, pitting node operators worried about bloat against developers warning that the cure sets a precedent worse than the disease.
Bitcoin doesn’t change often, and when it does, the process is usually slow enough to be boring. BIP-110 is the exception. A proposal ostensibly about block-space hygiene has instead become a referendum on who gets to decide what a “legitimate” Bitcoin transaction looks lik—and the answer, depending on who you ask, is either “nobody” or “everybody, so long as they signal at 55%.”
The problem BIP-110 says it’s solving
Since the rise of Ordinals and inscriptions in 2023, a growing share of Bitcoin’s block space has gone to transactions that embed images, text, and other arbitrary data rather than moving bitcoin from one party to another. To supporters of restricting this activity, that’s a resource problem: bigger blocks and heavier witness data mean higher costs to run a full node, more strain on the UTXO set, and less block space left for what they consider Bitcoin’s actual job—settling payments cheaply.
BIP-110, authored in the Bitcoin Knots orbit and associated with developer Luke Dashjr, is the technical answer to that complaint. It reached “Complete” status in the BIPs repository on June 25, 2026 under BIP-3‘s process rules, that label means the authors consider the spec finished, not that Bitcoin has agreed to run it.
What the proposal actually does
BIP-110 is a temporary soft fork—active for roughly a year—that layers seven new consensus restrictions on top of existing rules:
- Caps new scriptPubKeys at 34 bytes, with an 83-byte exception carved out for OP_RETURN outputs
- Limits most pushed payloads and script-argument witness items to 256 bytes
- Blocks spending from undefined witness and Tapleaf versions (though such outputs can still be created)
- Prohibits use of the Taproot annex
- Caps Taproot control blocks at 257 bytes, which limits how deep a Taproot script tree can go
- Rejects Tapscripts containing OP_SUCCESSx opcodes
- Rejects executed OP_IF or OP_NOTIF within Tapscript
In plain terms: it narrows the byte-size and structural options available for embedding data in a transaction, on the theory that inscriptions and similar uses need those wider options and payment transactions mostly don’t.
UTXOs that already exist before activation are grandfathered in, so the proposal isn’t retroactively confiscating anyone’s coins. But transactions built during the active window face the new limits, and the spec itself acknowledges a narrow but real risk: some pre-signed Taproot arrangements that span the activation date could behave unexpectedly or become unspendable, which is why the authors advise affected users to migrate funds ahead of time.
Why the activation mechanism is its own fight
Most Bitcoin soft forks activate through BIP-9: miners signal readiness, and if 95% of blocks in a signaling period show support, the change locks in. If support never reaches that bar, the proposal simply times out and nothing happens. That high threshold is a deliberate feature—it’s meant to make certain that a change genuinely has overwhelming buy-in from the network’s hash power before Bitcoin’s rules actually change.
BIP-110 modifies that formula in three ways that critics find alarming on their own, separate from the data-restriction debate entirely:
- It lowers the signaling threshold from 95% to 55%.
- It removes the standard timeout/FAILED state, meaning the proposal can’t simply expire quietly if it fails to attract support.
- It adds a mandatory-signaling period and guarantees lock-in on the “enforcing” chain by a specific block height, regardless of how much of the network has actually opted in.
According to the proposal’s own monitoring dashboard, signaling has been running below 1% as if July 19—nowhere near the 55% threshold, let alone the 95% bar used historically. That gap is precisely what worries opponents: a soft fork can, in principle, activate on a subset of the network even while the overwhelming majority of economic activity continues under the old rules, which is the textbook recipe for a chain split.
The argument for BIP-110
Supporters, largely aligned with the Bitcoin Knots camp and Dashjr, see this as proportionate. Their case:
- Data-heavy transactions impose real, measurable costs on every full node that has to validate and store them, and that cost falls disproportionately on ordinary node operators rather than the miners collecting the fees.
- Existing relay and mining policy (things like Bitcoin Core’s configurable OP_RETURN limits) can be bypassed by submitting transactions directly to miners, so voluntary policy alone hasn’t been sufficient to curb the activity.
- A time-limited, technically blunt fix that ships quickly is preferable to years of design debate while the underlying cost keeps accruing.
- Keeping the base layer lean protects Bitcoin’s core function—cheap, reliable payment settlement—from being crowded out by unrelated use cases.
The argument against
Opponents, including Strategy’s Michael Saylor, Blockstream CEO Adam Back, Casa’s CTO Jameson Lopp, and Samson Mow of Aqua Wallet, don’t necessarily disagree that node costs and block-space competition are real issues. Their objection is to the remedy:
- Bitcoin can’t determine intent. A validating node has no way to distinguish an inscription from a cryptographic proof, a smart-contract commitment, or a future application nobody has invented yet. Restricting the technical form used to store data therefore restricts legitimate future uses along with the ones the proposal is targeting.
- It closes upgrade paths that were deliberately reserved. The Taproot annex, undefined witness/Tapleaf versions, and OP_SUCCESSx opcodes exist specifically as hooks for future soft forks. Disabling them — even temporarily — burns option value that developers spent years preserving.
- The threshold mismatch is the real danger. A 55% signaling bar with no failure state, activating on a fixed schedule regardless of broader consensus, is exactly the kind of mismatched enforcement that can fracture the network rather than unify it.
- The precedent outlasts the rule. Even though the restrictions themselves expire after roughly a year, critics argue the underlying logic — that a large enough coalition can alter consensus to suppress a use case it disapproves of — does not expire. Saylor has been most explicit here, warning that privacy tools, novel custody schemes, stablecoin settlement, or token systems could face “similar arguments” down the line, calling it “not a prediction” but “a governance risk.”
- Better tools already exist and haven’t been exhausted. Relay policy, mining policy, and the fee market itself already ration block space without requiring the network to classify transactions by purpose. Opponents argue those levers deserve more attempts before reaching for a consensus change.
Why this is really a fight about Bitcoin’s identity
Strip away the byte counts and control-block math, and BIP-110 is a proxy fight over a question Bitcoin has never fully settled: is the protocol a neutral settlement layer that validates anything meeting its technical rules, or a monetary network entitled to defend a particular vision of “legitimate” use, even at the cost of rewriting consensus to do it?
Both camps say they want the same outcome—a Bitcoin that’s cheap to validate, resistant to capture, and focused on sound money. What they disagree about is whether narrowing what counts as a valid transaction gets you there, or whether it hands a precedent to whoever the next disputed use case turns out to be.
What happens next
The proposal’s mandatory signaling window opens in August, with activation targeted around September 1, 2026. Given that signaling currently sits under 1%, the coming weeks will determine whether BIP-110 gains enough miner support to lock in, stalls out short of its own mandatory threshold, or—in the scenario its critics fear most—activates on a portion of the network while the rest continues enforcing the old rules, setting up a live test of exactly the coordination risk Saylor and others have been warning about.
Sources: BIP-110 specification; BIP-9 activation standard; BIP-3 process definitions; BIP-110 signaling monitor; Decrypt’s coverage of the divide.