The Bitcoin BIP-110 fork has been simmering in developer forums for months, dismissed by many as a low-signal fringe dispute. That calculus is starting to shift — not because miner support has surged, but because a fixed block-height deadline is now close enough that exchanges, wallets, mining pools, and node operators can no longer treat it as someone else’s problem.
- The Bitcoin BIP-110 fork has a mandatory-signaling window arriving in August, forcing exchanges and miners to act now.
- Miner support for the Bitcoin BIP-110 fork sits at just 0.42%, far short of the 55% lock-in threshold required.
- Farside Investors’ live alert system makes every new signaling block a public, trackable infrastructure event.
- Exchanges, wallet teams, and node operators face real operational risks even if full activation never happens.
Table of Contents
What the Bitcoin BIP-110 Fork Actually Proposes
The Bitcoin BIP-110 fork is deployed under the identifier reduced_data using version bit 4, and targets the practice of embedding arbitrary data in Bitcoin transactions — most controversially, the kind of data popularised by the Ordinals and Inscriptions boom that drove block space demand and fee spikes throughout 2023 and 2024. Supporters argue Bitcoin’s base layer was never designed to be a general-purpose data store, and that large non-financial payloads crowd out legitimate financial transactions. Opponents counter that censoring transaction types crosses a line Bitcoin’s censorship-resistance model was specifically built to prevent.
That ideological battle has been fought extensively on social media and in Bitcoin Core mailing lists. What’s changed now is that the Bitcoin BIP-110 fork has moved from a theoretical disagreement into a live infrastructure event with real dates attached to it.
The Numbers Behind the Bitcoin BIP-110 Fork Debate
The headline figure is stark: miner support is minimal. Data from BGeometrics, pulled on July 3 and current through July 2, shows just 38 signaling blocks out of 9,066 total blocks since May 1 — a rate of 0.42%. In the most recent seven-day window covering June 26 through July 2, the count was 8 out of 1,000 blocks, or 0.8%. Individual daily snapshots show similar numbers: roughly 0.70% on July 1, ticking up to 1.53% on July 2.
Lock-in requires 1,109 out of 2,016 blocks — 55% — in a single difficulty adjustment period. At the current pace, the Bitcoin BIP-110 fork isn’t remotely close to activation. BGeometrics noted in its June 10 background report that signaling was essentially zero from May 1 through approximately May 20, with only low activity appearing around May 21. The firm characterised the observed volume as consistent with individual miners or smaller operations, with no visible commitment from any major pool.
That last point is the crux. BGeometrics called out Foundry USA and Antpool specifically as the kinds of operations whose participation would move the needle from low single digits into meaningful territory almost overnight. Either one shifting to BIP-110 signaling would transform the picture within a single difficulty adjustment window. Neither has signalled any intent to do so publicly.
Why the August Window Changes Everything
Here’s where the Bitcoin BIP-110 fork gets operationally interesting, independent of whether it ever achieves miner-driven lock-in. The BIP text defines a mandatory-signaling period spanning blocks 961,632 to 963,647. During this window, enforcing nodes reject any block that does not signal version bit 4 as invalid. Lock-in is hardcoded for no later than block height 963,648, with activation one retarget period later at height 965,664.
The BIP-110 website frames that as an August mandatory-lock-in window followed by roughly two weeks before the rules go live, then about one year of active enforcement before the proposal expires at the 52,416-block mark. That self-sunsetting design is unusual — Bitcoin soft forks typically don’t include expiry clauses — and reflects the authors’ acknowledgment that this is a contested intervention rather than a broadly endorsed protocol upgrade.
Farside Investors has added real-time visibility to all of this. The firm’s X account now posts automatically each time a Bitcoin BIP-110 fork signaling block is produced, turning what was a niche developer tracker into a public feed that any exchange compliance team, mining pool operator, or infrastructure engineer can monitor passively. A July 3 Farside post flagged a new signaling block and counted seven signals in the current period. Seven out of a possible 1,109 required — the gap is enormous — but the point isn’t whether those seven signals mean lock-in is near. The point is that each alert builds a public, timestamped record against which operational readiness can be measured.
What Exchanges, Wallets, and Pools Need to Do Now
The practical implications vary by role, but they’re concrete across the board.
- Exchanges need updated deposit, withdrawal, confirmation-count, and chain-risk policies that account for a contentious activation path. If enforcing nodes start rejecting non-signaling blocks during the mandatory window, chain splits and reorg risk become deposit-table questions, not just developer questions.
- Wallet developers face a specific technical flag in the BIP text itself: the spec acknowledges that the Miniscript compiler would require changes if BIP-110 activates, and notes — in cautious language — very unlikely scenarios in which funds could theoretically be frozen or lost. Taproot and Miniscript compatibility checks should be running now, not in late August.
- Mining pools need an explicit version-bit policy. Miners in a pool that hasn’t declared a BIP-110 stance may find themselves producing blocks that enforcing nodes reject, depending on how the mandatory-signaling window plays out.
- Node operators — whether they’re running infrastructure for an exchange, a payment processor, or a self-custody product — need to know whether their software is enforcing BIP-110 rules, and what that means for block validity decisions during the mandatory window.
None of these decisions require treating activation as certain. The whole point is that the Bitcoin BIP-110 fork mechanism with fixed block heights creates operational demands before the support numbers look threatening. That’s a feature of the design, not a bug — and it’s the same dynamic that played out, on a much larger scale, during the SegWit2x standoff in 2017 and the Bitcoin Cash split. Infrastructure teams that waited for clarity in those episodes were scrambling on deadlines that had been visible for months.
The Broader Fork-Risk Picture for Bitcoin
It’s easy to look at 0.42% miner signaling and file this under ‘not a real threat.’ That’s probably the right call for near-term activation probability. But the Bitcoin BIP-110 fork question sits inside a larger and genuinely uncomfortable tension in the Bitcoin ecosystem: what happens when the community can’t agree on what Bitcoin’s block space is for?
The Ordinals and BRC-20 debate exposed a fault line that the ‘Bitcoin is digital gold’ and ‘Bitcoin is a transaction layer’ camps hadn’t had to confront seriously before 2023. The Bitcoin BIP-110 fork is one response — a technically specific, time-bounded attempt to reassert a particular vision of Bitcoin’s purpose through the protocol itself. Bitcoin Core has not endorsed BIP-110, which is significant. Without reference client support, a proposal faces an enormous uphill battle even if a coalition of miners technically activates it, because the majority of economic nodes — the exchanges, payment processors, and custodians that collectively define ‘Bitcoin’ for most users — are unlikely to follow.
That’s roughly the lesson of SegWit2x: miners signaling doesn’t automatically equal economic consensus, and economic consensus is what actually settles a fork dispute in Bitcoin’s model. The mandatory-signaling window in BIP-110 is a creative mechanism designed to force that question into the open, but it doesn’t resolve the underlying disagreement.
What it does do — and what Farside’s alert system amplifies — is make the dispute impossible for infrastructure teams to treat as background noise. Every signaling block is now a notification. August is now a planning constraint. And if a single major pool shifts its stance, the entire probability calculus changes faster than most operations have response cycles for. That’s the real story here — not the 0.42%, but the readiness gap that number might be concealing.
Source: CryptoSlate
Frequently Asked Questions
What is the Bitcoin BIP-110 fork and why does it matter?
The Bitcoin BIP-110 fork is a proposed protocol change targeting arbitrary data storage on the Bitcoin blockchain. It matters because it includes a mandatory-signaling window in August and a defined activation path, meaning exchanges, miners, and node operators must prepare procedures regardless of whether full miner lock-in occurs.
How much miner support does BIP-110 currently have?
As of early July, miner signaling for BIP-110 stands at just 0.42% — 38 signaling blocks out of 9,066 total since May 1. Lock-in requires 55% of blocks in a difficulty adjustment period, so a major pool like Foundry USA or Antpool would need to move for that to change quickly.
What happens during the BIP-110 mandatory-signaling window?
During the mandatory-signaling period, defined as blocks 961,632 to 963,647, blocks that do not signal version bit 4 are rejected as invalid by enforcing nodes. Lock-in is set for no later than height 963,648, with activation one retarget period later at height 965,664.
Does BIP-110 activation permanently change Bitcoin’s rules?
No. The BIP text specifies an active duration of 52,416 blocks, after which the rules expire. That’s roughly one year of active restrictions, which the BIP-110 site describes as an August mandatory-lock-in window followed by roughly two weeks before activation, then about one year of active restrictions before the proposal sunsets automatically.
Why should wallet users care about the Bitcoin BIP-110 fork?
The BIP text explicitly acknowledges that Miniscript compiler changes would be needed if BIP-110 activates, and notes very unlikely scenarios in which funds could theoretically be frozen or lost. Wallet teams are being advised to run Taproot and Miniscript compatibility checks now, well ahead of the August window.
