The BIP-110 Chain Split: Anatomy of a Failed Mandatory-Signaling Activation

Abstract. At 19:35:55 UTC on 8 August 2026, AntPool mined Bitcoin block 961,632 without setting version bit 4. Nodes enforcing BIP-110 — a temporary soft fork restricting non-financial data, whose activation design made signaling mandatory from exactly that height — rejected the block, and 36 minutes later a miner identified as Roughnecks, working through the OCEAN pool, mined a competing, signaling block at the same height. Bitcoin had a chain split. It was not a surprise: BIP-110 required 1,109 of 2,016 blocks (55%) to signal and never achieved more than 2.7% in any measured window, closing its final voluntary period at 2.53%. This paper reconstructs how a proposal with roughly a fifth of reachable nodes but under 3% of hashrate and no meaningful economic backing reached its flag day anyway; why its activation design converted insufficient support into a chain split rather than an abort; and what the minority chain now faces — full mainnet difficulty (an expected block every ~6.4 hours at 2.6% of hashrate, with the next retarget roughly 1.5 years away at that rate), no replay protection, no exchange support, and a structural asymmetry under which its own success condition is a reorganisation of Bitcoin itself. A live monitor embedded in §6 tracks both chains, the signaling record and the pool distribution as the event develops. The paper closes by setting BIP-110 against BIP-148, the 2017 user-activated soft fork it explicitly cited as precedent, and argues the comparison explains the failure: mandatory signaling is a commitment device that transfers risk onto whoever has less economic weight, and in 2026 that was, measurably, the enforcing side.

Key findings

1. The split was designed in, not accidental. BIP-110's activation parameters guarantee lock-in at block 963,648 whether or not miners signal, and command enforcing nodes to reject every non-signaling block from 961,632. With 2.53% signaling, rejection of the majority chain — a chain split — was the mechanical outcome, and it executed on schedule.
2. Support was nodes, not hashrate, and the two were confused throughout. Bitcoin Knots reached somewhere between 8% and 23% of reachable nodes (the range itself is contested); miner signaling peaked at ~2.7%, every signal traced to miners paying out through a single pool (OCEAN), and the four pools controlling >70% of hashrate never signaled once.
3. Even the champion pool did not follow its own cause. OCEAN — whose CTO Luke Dashjr was BIP-110's most prominent advocate — mined at least one non-signaling block on the majority chain inside the mandatory window, while its VP of engineering had publicly given the proposal "less than a 5% chance".
4. The fork chain is in a difficulty trap. It inherits full mainnet difficulty (127.5 T) and cannot retarget for 2,014 more blocks. At 2.6% of network hashrate that is one block every ~6.4 hours and a first retarget ~1.5 years away; at its observed post-split output the horizon is longer.
5. There is no replay protection, and the grandfather clause means there never fully will be. A signed transaction spending pre-fork coins is valid on both chains indefinitely; anyone who "sells their fork coins" hands the buyer a transaction that can be replayed to take the real BTC. Doing nothing is the only safe default for holders.
6. The asymmetry runs one way. BIP-110's chain is valid under legacy rules, so if it ever accumulated more work than the main chain, every non-enforcing node would reorganise onto it — but the main chain is permanently invalid to BIP-110 nodes. The fork's only winning condition is overturning Bitcoin's recent history; its losing condition is the status quo.
7. BIP-148 is the instructive contrast, not the precedent. The 2017 UASF never had to execute: a credible economic majority plus 30–45% sympathetic hashrate made miner capitulation (BIP-91) the cheaper option. BIP-110 executed its threat with neither, and the market's verdict was a 0.2% intraday move.

1. Background: three years of the data war

BIP-110 is the terminal act of a conflict that opened on 21 January 2023, when former Bitcoin Core contributor Casey Rodarmor launched the Ordinals protocol. Ordinals exploits two properties of post-Taproot Bitcoin — the removal of script-size limits and SegWit's four-times discount on witness data — to "inscribe" arbitrary content (images, text, tokens) into transactions. Within roughly three weeks, inscriptions were estimated at half of all block space; in May 2023 the BRC-20 token mania pushed total transaction fees above the block subsidy for the first time since December 2017, and miners collected 2,749.95 BTC (~$63 million) in fees in that month alone. For miners this was found revenue — 2023 fee income roughly quintupled year over year. For one faction of node operators it was an existential adulteration of a monetary network.

The factions acquired software. Luke Dashjr, one of Bitcoin's longest-serving developers, classified inscriptions as an exploit — registering CVE-2023-50428, "datacarrier size limits can be bypassed by obfuscating data as code" — and shipped filters in his Bitcoin Knots implementation; his January 2024 attempt to bring equivalent filtering into Bitcoin Core was rejected. The OCEAN mining pool, launched November 2023 by a company Dashjr co-founded with a $6.2 million seed round led by Jack Dorsey, mined Knots-filtered block templates. Bitcoin Core then moved in the opposite direction: pull request #32406 (Greg Sanders, merged 9 June 2025), raised the default OP_RETURN data-carrier limit from 83 bytes to 100,000 bytes, shipping in Core v30 on 10 October 2025, three days after a statement signed by 31 Core contributors had defended the relay-policy philosophy behind the change.

The backlash to v30 became the largest node-software migration in Bitcoin's history. Knots grew from 69 reachable nodes in January 2024 to over 4,200 by September 2025 — touching roughly a quarter of the reachable network at its peak, though how much of that count is real, independent, economically relevant infrastructure is one of this paper's recurring caveats (§9). What the migration conspicuously did not include was hashrate. No major mining pool ever adopted filtered templates beyond OCEAN, and none at all would come to signal for what followed.

2. The proposal: what BIP-110 actually restricts

BIP-110, "Reduced Data Temporary Softfork", was posted to the bitcoindev mailing list on 25 October 2025 at 20:43 UTC by a pseudonymous author, Dathon Ohm, who framed it as operationalising an earlier idea of Dashjr's: "Due to Bitcoin Core v30 gaining in popularity, it has become necessary to move forward on luke-jr's ML proposal to temporarily limit arbitrary data at the consensus level… Bitcoin is money." The specification's entire Credits section reads: "Original draft and advice: Luke-Jr". The proposal circulated under the provisional number BIP-444, was assigned BIP 110 on 3 December 2025, and was merged into the BIPs repository as a Draft in February 2026 by editor Mark "Murch" Erhardt — who simultaneously called it "a misguided and unusually careless softfork proposal". The review thread (93 comments, 399 review comments, repeated moderation locks) set the tone: Peter Todd NACKed it two days in by pointing to an on-chain transaction containing the full text of the BIP itself while remaining BIP-110-compliant ("…shows how utterly ineffective this approach is"); Greg Maxwell alleged the PR was "being tendered on behalf of Ocean Mining" through a concealing account; Ohm denied the affiliation while conceding the BIP "was originally drafted by one of them" — an OCEAN employee. Procedurally admitted, substantively rejected by most senior reviewers: that tension marked the proposal's whole life.

Substantively, BIP-110 is seven temporary consensus rules that convert long-standing relay policy preferences into validity rules for about one year (52,416 blocks) after activation:

Two properties matter for everything that follows. First, the rules are deliberately temporary and grandfathered — the author's own rationale concedes that permanent versions "would severely constrain future upgrades", and answers the question of whether the proposal breaks existing uses with unusual candour: "Yes, this proposal intentionally breaks user space, specifically the data storage user space." (It also concedes "in theory, yes" on the possibility of freezing funds locked in pre-signed Taproot transactions that use the banned constructions, and that the control-block cap breaks BitVM.) Second, its effectiveness was contested from day one: Todd's compliant BIP-text transaction made the point in October; in July 2026 an Ordinals developer shipped an ord update that splits large inscriptions into fragments below BIP-110's limits — "Ordinals are now BIP-110 ready" — validated by Rodarmor himself; and Galaxy's Alex Thorn noted that oversized OP_RETURN outputs, the rule-1 target, consumed less than 0.1% of block space. The proposal's practical payload, in other words, was smaller than its constitutional one: the real question it posed was whether node operators could impose validity rules on miners without them.

3. Activation design: a splice of three mechanisms

BIP-110's deployment is formally "modified BIP-9", but the modifications are the story. It splices together the three activation mechanisms Bitcoin has used or debated since 2015, keeping from each the part that maximises the probability of activation rather than of consensus:

The concrete parameters: signal on version bit 4 from ~1 December 2025 (starttime 1764547200); no timeout; voluntary lock-in in any 2,016-block difficulty period reaching 1,109 signals; failing that, a mandatory signaling window spanning blocks 961,632–963,647 — exactly difficulty period 477, since 961,632 = 477 × 2,016 — during which enforcing nodes reject any block without bit 4; guaranteed lock-in at 963,648; rules active no later than height 965,664, and expiring 52,416 blocks later. A new EXPIRED terminal state ends the whole experiment automatically.

Note what this design does: it makes activation unconditional from the perspective of enforcing nodes. BIP-9 deployments fail silently when miners decline; Speedy Trial was explicitly built to fail fast and cheaply. BIP-110 cannot fail on its own terms — below-threshold support does not abort the deployment, it relocates the failure into a chain split, transferring the cost of the disagreement onto whichever side commands less hashrate and economic weight. The designers understood this was the BIP-148 gambit; §8 examines why the gambit's 2017 success conditions were absent. Bitcoin Core never merged an implementation (the PR sat unmerged); the enforcing client shipped as a Bitcoin Knots derivative, patched in February 2026 after a consensus flaw was found in its first release — the node visible in our monitor runs /Satoshi:29.3.0/Knots:20260508/.

4. The signaling record: December 2025 – August 2026

Across eight months, BIP-110's miner support went from zero to nearly zero. The first signaling block was mined on 1 March 2026 — three months into the window — by Barefoot Mining, through OCEAN. Every signaling block ever recorded traced to the same channel: individual miners using OCEAN's DATUM protocol, which lets them build their own block templates while sharing payouts through the pool. Entities publicly identified as signaling include Roughnecks, Barefoot Mining, Sazmining and a dozen smaller DATUM operators. Signals from any other pool: zero, a fact Michael Saylor's running arithmetic made into a public scoreboard — at block 960,561 on 1 August: "24 signals in 946 blocks (2.54%)… Signals outside OCEAN: 0. The 55% voluntary threshold is now mathematically unreachable this period."

In hashrate terms the picture was starker still. TFTC measured signaling support near 5 EH/s in late June against a network of roughly 940 EH/s — about half a percent — rising to roughly 24 EH/s (~2.6%) by early August. The four pools controlling over 70% of network hashrate — Foundry USA, AntPool, F2Pool, ViaBTC — never signaled; Foundry ran a customer vote that never reached its own 51% trigger. Against this, the enforcing side's strength was measured in nodes: Bitcoin Knots at somewhere between 8% and 23% of the reachable network depending on methodology (§9). The proposal's supporters read node share as economic consensus; its opponents replied, in Saylor's formulation, that this "confuses software distribution with true economic consensus — Bitcoin is not one node, one vote." By 1 August the tracking service Farside declared the 55% threshold could "never" be reached; F2Pool put its position in five words — "No way we'll signal BIP-110" — and OCEAN's own VP of engineering had already given the proposal "less than a 5% chance… and I consider that generous." The author's response, roughly 48 hours before the window, was a general mobilisation order: "ATTENTION. THIS IS NOT A DRILL… All miners must begin signaling readiness for BIP-110 (versionbit 4) by that time, or their blocks will be discarded as invalid." The only open question left was whether the mandatory window would arrive to an abandoned deployment or a live one.

5. The split at block 961,632

It arrived to a live one. The last common block of the two chains is 961,631 (…9327ce8a). What happened next is fully reconstructable from the two chains' own data:

Three details of the day deserve emphasis. First, the ideological lines did not hold under economic pressure: OCEAN itself — the pool whose infrastructure produced every BIP-110 signal in history and whose CTO was the proposal's champion — mined a non-signaling block on the majority chain inside the mandatory window: block 961,634, coinbase-tagged < OCEAN.XYZ >, version 0x25ae2000, at 20:29:22 UTC — seventeen minutes after Roughnecks mined the fork's first block through the same pool. The pool's institutional behaviour (follow the majority chain, permit DATUM customers to do otherwise) contradicted its leadership's rhetoric on the day the rhetoric was tested. Second, the language escalated to match the mechanics: Dashjr called AntPool's routine, majority-consistent block an attack on Bitcoin; Bitcoin Mechanic told AntPool it had "mined an invalid block"; under BIP-110's rules both statements are true, and under everyone else's rules both are false — the dispute is precisely about which rulebook is Bitcoin. Third, the market declined to participate: BTC had touched an August high of $65,340 the day before on the fifth straight day of ETF inflows, and traded at $64,894, down 0.20%, while the chains diverged. As a referendum on systemic risk, the split priced at approximately zero — though the operational risk was not quite zero either: Core contributor Jon Atack had advised pausing transfers around block 961,632 "because short reorgs are possible", and two Australian bitcoin-only exchanges (Hardblock, Bitaroo) warned they might pause operations around the window.

6. Live telemetry: the two chains now

Because this event is ongoing, this section is instrumented rather than written. The monitor below aggregates, on our server every five minutes: the main-chain tip from mempool.space; the BIP-110 chain tip from mempool.kilombino.com (the supporter-run mempool instance that follows the fork chain — the only public source of fork-tip timestamps and miner attribution); and the two-node comparison and bit-4 signaling scan from bip110.orange.surf, whose enforcing Knots node and Core observer node provide the divergence status and the per-block pool attribution of the mandatory window. The page repaints every 60 seconds without reloading.

How to read it: the gap is the headline — if the fork chain's height freezes while the main chain advances ~144 blocks a day, its hashrate has gone; occasional single blocks hours or days apart are consistent with one or two persistent DATUM miners. The signaling strip should be read as an obituary rather than a race: because the mandatory window's main-chain history already contains non-signaling blocks, no amount of future signaling can reconcile enforcing nodes to it — the strip simply documents how completely miners declined to participate. A word of caution on provenance: every fork-side figure ultimately comes from infrastructure run by BIP-110 supporters, and pool attribution is a coinbase-tag heuristic (§9).

What would falsify this paper's headline conclusion? Sustained acceleration of the fork chain — the gap shrinking rather than growing across days — would mean hashrate is migrating and the game theory Ohm invoked is operating; §7 quantifies how much would be needed. Chain death, conversely, has a concrete signature: no new fork-chain blocks across weeks, followed by the monitoring infrastructure itself going dark.

7. Risk analysis: replay, wipeout, difficulty

7.1 Replay: the "free airdrop" that can cost real bitcoin

Soft forks cannot add replay protection — by construction, their transactions are valid under both rule sets — and BIP-110's grandfather clause (§2) extends the problem indefinitely: an ordinary transaction spending pre-fork coins to ordinary outputs is, and will remain, valid on both chains. The practical consequence was spelled out by Wizardsardine's Kevin Loaec two days before the split: anyone who treats fork-chain coins as a free airdrop and sells them signs a transaction that a counterparty can replay on the main chain, taking "the real BTC" — "It is a big security risk for people who just believe they will get an 'airdrop'… large holders could be targeted first." Deliberately splitting coins is possible but only after the fork chain activates its rules (at its height 965,664, months away at its block rate) and only by crafting transactions one chain rejects — an annex-bearing spend, for instance — which is expert territory. Before then, the only true split is tainting coins with a post-fork coinbase output, which requires a cooperating miner on each chain — and coinbase maturity makes even that glacial on the fork side: at roughly two blocks a day, a fork-chain coinbase needs ~50 days just to reach its 100-confirmation spendability. Loaec's default is also ours: "doing nothing will be a safer option, as coins that never move cannot be replayed because there is no signed transaction to copy." Peter Todd had made the same point as satire before the split: miners could "signal for it, but not actually enforce BIP-110 rules… that way the true fork is delayed until easy replay protection."

7.2 Wipeout: the asymmetry both sides are counting on

Because BIP-110 is a restriction, every block on its chain is valid under legacy rules. If the fork chain ever carried more cumulative work than the main chain, every non-enforcing node on earth would reorganise onto it automatically, erasing the main chain back to block 961,631 — a "wipeout". The reverse cannot happen: the main chain contains non-signaling blocks in the mandatory window, which enforcing nodes reject permanently. This asymmetry is the entire strategic content of "the game theory starts to kick in": the fork's existence is a standing option on a miner stampede. Pre-split, proponents argued the option would exercise itself — one pro-BIP-110 analysis called signaling a "weakly dominant strategy" and put miners' orphan-risk exposure across the mandatory window at ~2,835 BTC (~$280 million) if enforcement carried the economy with it. It did not, and without that condition the arithmetic inverts: under the classic minority-catch-up model, a chain with share q overtakes from z blocks behind with probability on the order of (q/p)^z — at 2.6% and 18 blocks behind, roughly 10^-28, shrinking by another factor of ~40 with each main-chain block. The same asymmetry was central to the 2017 discourse — Bitmain justified its UAHF contingency plan by it, and contemporary guides warned legacy-chain users their history could be rewritten — and the majority side even has a manual defence if it ever mattered (deliberately invalidating the minority chain's blocks, a "URSF"). The difference is that BIP-148's proponents could plausibly threaten the stampede and BIP-110's could not (§8). Jimmy Song's pre-split taxonomy remains the honest summary: every clean resolution — hashrate collapse to zero, majority wipeout, a deliberate hard fork, or a URSF — is individually unlikely, leaving "a minority chain holding the specter of a wipeout over the majority chain" indefinitely, at vanishing but nonzero probability.

7.3 The difficulty trap

The fork chain inherited the main chain's difficulty — 127.48 T, set at the 961,632 retarget — and Bitcoin's retarget rules now work against it three ways: the next adjustment is 2,014 blocks away (fork height 963,648); the adjustment is computed from elapsed time but clamped at 4× per period; and until then every block costs majority-chain mining economics for a coin with no exchange price.

The economics close the loop. Mining the fork chain means paying full mainnet production costs for a reward no exchange will credit — none announced support, Lopp had predicted exactly that in February ("there's simply not enough interest"), and US spot-ETF prospectuses irrevocably abandon forked assets. Even the proposal's policy goal is moot on its own chain: the Ordinals toolchain shipped BIP-110-compliant fragmentation in July, so the data the fork was built to exclude can be inscribed on it anyway. The fork chain's continued existence is therefore best modelled not as a competing currency but as a subsidised protest — sustained exactly as long as its remaining miners are willing to donate hashrate to it.

8. Discussion: why BIP-148 worked and BIP-110 did not

BIP-110's proponents explicitly invoked the 2017 user-activated soft fork as precedent, and the comparison is genuinely the best lens on the failure — because every load-bearing element of 2017 was missing in 2026.

In 2017, SegWit already commanded 30–45% of miner signaling under BIP-9 and near-universal support among developers, wallets, and the businesses that would later sabotage SegWit2x; what BIP-148 added was a credible threat that the economic majority — exchanges and payment processors prepared to value the UASF chain — would orphan non-signaling miners' revenue. Miners faced losing block rewards on the chain where coins had buyers. They capitulated eleven days early through BIP-91, signaling became unanimous, and the UASF "quietly activated to little effect". The threat never had to execute, which is the definition of a successful commitment device.

In 2026 the direction of economic pressure was reversed. The proposal's support was concentrated in node counts of contested provenance; against it stood every major pool, the largest treasury holder (Saylor, publicly, for months), senior Core contributors including the BIP's own editor, prediction markets at 98% failure, and — fatally — no exchange or custodian prepared to value the enforcing chain. Even natural allies split: Giacomo Zucco's "Spam is Bad. So is BIP-110" separated the anti-spam cause from the mechanism, and OCEAN's institutional hedging (§5) showed the mechanism had no unconditional backers at all. Under those conditions, mandatory signaling stops being a commitment device and becomes an exit: the enforcing side pre-commits to leaving consensus if it loses, and it lost. SegWit2x completes the taxonomy from the opposite corner — hashrate and corporate weight without node-and-user consent also failed, cancelled three weeks before its own flag day. Bitcoin's governance, on this record, requires the conjunction of nodes, hashrate and economic weight; any faction holding one of the three can veto, and none can rule.

A distribution detail deserves separate emphasis, because it corrodes the headline node statistic from the inside. Official Bitcoin Knots release binaries from May 2026 onward enforce BIP-110 by default: a node whose operator never opted in logs an hourly warning — "User has not consented to supported protocol rules. This node will STILL enforce them" — and disabling enforcement requires recompiling from source. However large the enforcing node count was, some unknowable fraction of it was a software default rather than an operator's decision, which is precisely the "software distribution versus economic consensus" distinction the opposition kept drawing. Meanwhile Bitcoin Core's repository closed the BIP-110 implementation PR eight seconds after it was opened ("There is nowhere near broad support for BIP-110, as you of course know"), so no Core release enforces or can enforce it — the enforcing population is definitionally a Knots-derivative population.

Two tail risks keep the story open. Dashjr has said that if BIP-110 fails "the only option is a PoW change", and an associated developer has already rebased his 2017 proof-of-work-change code onto current Knots "in case miners betray bitcoin" — an escalation path from minority soft fork to deliberate hard fork. And the underlying grievance — a fifth of node operators who believe the network they validate has been annexed by data they consider spam — has not gone anywhere. BIP-110 resolved a question of power. The question of purpose that produced it is still unresolved.

9. Limitations and open questions

1. Fork-side observability. Every figure about the BIP-110 chain flows through supporter-operated infrastructure (mempool.kilombino.com; bip110.orange.surf's enforcing node). We cross-checked hashes and heights between the two and against press reports, but we did not run an enforcing node, and a single-operator data path is a single point of failure — and of narrative.
2. Pool attribution is a heuristic. Coinbase tags identify the template producer, not the hashrate owner — especially under DATUM, where "OCEAN" blocks are built by customers. At least one mandatory-window block (961,634) is attributed to different miners by different sources.
3. Node-share numbers are soft, twice over. Published Knots shares span 8–23% depending on methodology, and Sybil-cheap Tor nodes inflate raw counts. Deeper: only Knots builds from May 2026 onward (and the standalone activation clients) enforce BIP-110 at all, and those builds enforce it by default, warning non-consenting operators hourly rather than deferring to them — so the enforcing-node count neither equals the Knots count nor cleanly measures operator intent, in either direction.
4. The escalation the day of the fork is under-analysed. Knots 29.4 was published hours before the split with release notes asserting that Bitcoin Core "will no longer be a fully validating node or safe" from the window onward — a claim whose consequences for the remaining Knots user base (do they follow the fork chain by default?) we have not been able to quantify.
5. Hashrate on the fork is unmeasurable from two blocks. The ~2.6% figure is signaling share before the split; post-split commitment could be far lower. Weeks of block arrivals are needed for any honest estimate.
6. Open questions we expect to revise on: whether Roughnecks (or anyone) keeps mining the fork; whether any venue ever prices its coin; whether the enforcing client ships an escape hatch or its operators simply return to the majority chain; whether the PoW-change thread progresses beyond a rebase; and whether a better-designed successor proposal (a BIP-8 deployment with honest thresholds, or a filtering approach that does not require consensus change) emerges from the wreckage.

Frequently asked questions

Methodology and data sources

Compiled 8–9 August 2026 from: primary block data via the mempool.space REST API (main chain) and mempool.kilombino.com (fork chain), quoted with hashes, version words and timestamps; monitoring APIs at bip110.orange.surf (node comparison, bit-4 epoch scan with pool attribution) and bip110monitor.com (per-period signaling history); the BIP-110 specification and its bitcoindev announcement thread; and the cited press coverage for events and statements we could not observe on-chain. X-post timestamps were decoded from snowflake IDs. The live monitor in §6 re-aggregates the same sources server-side every five minutes; prose figures are frozen at publication and revised, with the revision logged, rather than silently updated. We verified the split block's timestamp and version directly against the chain (8 August 2026, 19:35:55 UTC, 0x20006000) and note where press dating differs. Claims about future behaviour of miners, markets or developers are analysis, not reporting, and are worded as such.

References

1. BIP 110: Reduced Data Temporary Softfork — specification (Dathon Ohm) — https://github.com/bitcoin/bips/blob/master/bip-0110.mediawiki
2. [BIP Proposal] Reduced Data Temporary Softfork — bitcoindev announcement, 25 Oct 2025 — https://gnusha.org/pi/bitcoindev/AWiF9dIo9yjUF9RAs_NLwYdGK11BF8C8oEArR6Cys-rbcZ8_qs3RoJURqK3CqwCCWM_zwGFn5n3RECW_j5hGS01ntGzPLptqcOyOejunYsU=@proton.me/
3. bitcoin/bips pull request #2017 — the review thread (Todd's NACK, the OCEAN allegation) — https://github.com/bitcoin/bips/pull/2017
4. Bitcoin Optech — Newsletter #379, first coverage of the proposal (7 Nov 2025) — https://bitcoinops.org/en/newsletters/2025/11/07/
5. BIP110 Situation Monitor — live two-node comparison and signaling APIs — https://bip110.orange.surf/live.html
6. bip110monitor.com — independent per-period signaling history — https://bip110monitor.com/
7. mempool.space — main-chain block 961,632 (AntPool, non-signaling) — https://mempool.space/block/00000000000000000000d1e01392faa65ceeaed307f0a3159144b84146ff24ba
8. mempool.kilombino.com — BIP-110-chain block 961,632 (Roughnecks via OCEAN) — https://mempool.kilombino.com/block/0000000000000000000169eb6f811ddbd0daf343af7b62180cdb13e7c78dbc16
9. CoinDesk — Bitcoin hits block 961,632 as the controversial BIP-110 soft fork attempt begins — https://www.coindesk.com/tech/2026/08/07/frame-bitcoin-s-bip-110-enters-mandatory-signaling-with-less-than-3-miner-support
10. CoinDesk — Bitcoin holders risk losing real BTC if they sell coins from BIP-110 fork (Kevin Loaec) — https://www.coindesk.com/tech/2026/08/08/bitcoin-holders-risk-losing-real-btc-if-they-sell-coins-from-bip-110-fork-says-developer
11. news.bitcoin.com — BIP-110 Splits Bitcoin as Rival Miners Clash at Block 961632 — https://cryptonews.net/news/bitcoin/33268527/
12. The Block — BIP-110 supporters split onto minority chain as main network pulls ahead — https://www.theblock.co/news/ecosystems/2026-08-08-bitcoins-bip-110-supporters-split-onto-minority-chain-as-main-network-pulls-ahead-411213
13. Crypto Briefing — BIP-110 nodes fork from main chain after rejecting non-signaling block — https://cryptobriefing.com/bip-110-nodes-fork-bitcoin-chain-split/
14. Jameson Lopp — A Layman's Guide to BIP-110 (23 Feb 2026) — https://blog.lopp.net/a-laymans-guide-to-bip-110/
15. Jimmy Song — The Messy Middle, or what actually happens after the split (27 Jul 2026) — https://jimmysong.substack.com/p/the-messy-middle-or-what-actually
16. Bitcoin Magazine (Aaron van Wirdum) — Bitcoin's BIP-110 moment: three possible scenarios — https://bitcoinmagazine.com/technical/bitcoins-bip110-moment-three-possible-scenarios
17. Michael Saylor — verdict post on BIP-110 signaling, 8 Aug 2026 — https://x.com/saylor/status/2086057411056447861
18. TFTC — BIP-110 Enters Mandatory Signaling Window Below 1% Hashrate (22 Jul 2026) — https://www.tftc.io/bip-110-mandatory-signaling-window-miner-support-bitcoin-consensus
19. TFTC — Luke Dashjr Threatens PoW Hard Fork as BIP-110 Fails to Hit 55% Threshold (7 Aug 2026) — https://www.tftc.io/bip-110-pow-hard-fork-dashjr-block-961632
20. Bitcoin Core — development and transaction relay policy, joint statement (6 Jun 2025) — https://bitcoincore.org/en/2025/06/06/relay-statement/
21. BIP 148: Mandatory activation of segwit deployment (Shaolinfry, 2017) — https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
22. Bitcoin Magazine — BIP 91 Has Locked In. Here's What That Means (Jul 2017) — https://bitcoinmagazine.com/technical/bip-91-has-activated-heres-what-means-and-what-it-does-not

Revision history

Disclaimer. This research is published for information and education. It is not financial advice, and it is emphatically not a recommendation to acquire, sell or attempt to split fork-chain coins — §7.1 describes how attempting to do so can lose real bitcoin. If you hold BTC, the analysed safe default is to do nothing.