At block 961,632, two sets of Bitcoin nodes began applying different rules to the same parent. One accepted a block whether it signaled for BIP-110 or not. The other rejected blocks that did not set version bit 4.

What happened next was visible. What it meant was not.

The first ordinary, non-signaling child of block 961,631 was hash 00000000000000000000d1e01392faa65ceeaed307f0a3159144b84146ff24ba. Its version was 0x20006000, with bit 4 unset. Monitors attributed it to AntPool. Its miner-supplied header timestamp was August 8, 2026 at 19:35:55 UTC.[2][4]

A competing signaling child arrived with hash 0000000000000000000169eb6f811ddbd0daf343af7b62180cdb13e7c78dbc16. Its version was 0x27d60010, with bit 4 set. The monitor attributed it to Ocean.xyz. Its header time was 20:12:12 UTC.[4]

Same parent. Same height. Different rule sets.

By FF2K's frozen cutoff roughly 27 hours later, the ordinary, Bitcoin Core-compatible branch was at height 961,781, tip hash 00000000000000000000505e2f2c0eb6250bd0cd7f3aad69df66a1fea5129a24. The BIP-110-enforcing branch was at 961,633, tip hash 0000000000000000000139eda19858a84b2ed80cb6056ba8449f0792d13d0968.[2][4]

That is 150 post-fork blocks on the ordinary branch and two on the enforcing branch. Both branches used the same difficulty target, so the desk's linked-header calculation found a 148-block-work gap: exact chainwork 00000000000000000000000000000000000000013e40776fc9f338aeff8099fe versus 00000000000000000000000000000000000000013dfd6fb8aa1165743eef8f7a. Mempool.space independently agreed on the ordinary tip height and hash at the cutoff.[5][6] Blockstream returned the same result.[7][8]

The ordinary branch had overwhelmingly more accumulated proof of work. That is the clean fact.

Calling it a democratic vote would be fan fiction with a block explorer.

First correction: the payload rules did not activate

BIP-110 proposed seven temporary consensus restrictions on data-bearing transaction structures. But those restrictions were not active at height 961,632. What began there was mandatory signaling: enforcing nodes would reject blocks without bit 4 during heights 961,632 through 963,647. Under the proposal, lock-in would occur by 963,648 on an accepted enforcing history, with the reduced-data rules scheduled for 965,664.[1]

The final voluntary signaling period, heights 959,616 through 961,631, recorded 51 signaling blocks out of 2,016, or 2.53 percent. After mandatory signaling began, the orange.surf feed found zero bit-4 signals in the first 150 ordinary-branch blocks.[3][9]

So the event tested enforcement coordination before it tested the seven restrictions. The chain can tell us how much work followed each accepted history. It cannot tell us how the still-inactive payload rules would have affected fees, inscriptions, UTXO growth, wallet compatibility, or future script use.

That distinction ruins several victory laps, which is usually a sign the distinction matters.

How the argument reached 961,632

The immediate trigger was not born in August.

FF2K's earlier Part One framed the dispute around defaults, legitimacy, and incentives; this post-mortem tests that frame against the observed outcome rather than treating it as a conclusion.[23]

On June 9, 2025, Bitcoin Core merged PR #32406. Bitcoin Core 30.0 later documented a default -datacarriersize of 100,000 bytes, effectively uncapping the old OP_RETURN policy because transaction-size limits bind first, while permitting multiple data-carrier outputs. Users could still configure the older-sized policy. This changed relay and mining policy defaults, not transaction or block consensus validity.[11][12]

BIP-110's response was to move the boundary from local policy to temporary consensus. Its initial draft was dated October 24, 2025; its number was assigned in December. A repository commit advanced its BIP status to Complete on June 24, 2026 UTC, while the BIP changelog labels version 1.0.0 June 25. Under BIP 3, Complete describes document maturity and an adoption recommendation. It is not proof of network adoption.[21][22]

Bitcoin Knots shipped RDTS enforcement code in May, but not merely by association with the Knots brand. The release asked GUI users to confirm and instructed command-line operators to set consensusrules=rdts; it also offered a non-RDTS build. Running “Knots” did not by itself prove enforcement.[13]

Bitcoin Core did not merge BIP-110. The proposed Core implementation PR was closed and locked after explicit objections that broad support had not been shown.[14]

In July, OCEAN announced separate signaling and non-signaling Stratum endpoints. DMND said miners using Stratum V2 Job Declaration build their own templates, including the version field, and that DMND would not override their choices.[15][16]

Then came the last voluntary period: 51 signals, 1,965 non-signals. At 961,632, enforcing and non-enforcing nodes stopped agreeing about which child was acceptable.

The strongest case for BIP-110

The pro-BIP case starts with a real limitation of local policy. A node can decline to relay a consensus-valid transaction; that does not prevent a miner from receiving it through a private submission service, another relay network, or a different encoding. Proponents argue that arbitrary data creates costs for node operators and competes with monetary use, while dominant-client defaults carry social force even when technically configurable.[1][10]

Their strongest claim is not that one OP_RETURN flag controls Bitcoin. It is that policy theater cannot hold a line miners can route around, and that a temporary consensus restriction was the only honest way to force the network to decide.

The chain outcome weakens the coordination case. The voluntary threshold was missed by miles, and the enforcing branch attracted two observed blocks by the cutoff. BIP-110's own website now describes a “two-block BIP-110 branch” while offering instructions for users who choose to leave it.[10]

But the outcome did not prove arbitrary data harmless. It did not answer whether Core's default was wise. And it did not run the proposed restrictions long enough to measure their effects, because they never entered the ACTIVE state.

The strongest case against BIP-110

Critics warned that mandatory signaling with little miner readiness would create divergence before the payload rules could demonstrate any benefit. They argued that the restrictions were broad, could interfere with legitimate or future script uses, and turned a disputed view of transaction purpose into consensus validity. Jameson Lopp's February critique explicitly warned of increased chain-split risk and argued that miners had a fee incentive not to enforce restrictions.[20]

The observed result supports the narrow prediction: divergence occurred at the mandatory-signaling boundary, and the enforcing history accumulated very little work.

It does not prove every predicted harm occurred. We recovered no primary evidence at cutoff of a major exchange pause, wallet failure, customer loss, separate market price, or broad payment disruption. No evidence found is not the same as evidence of none. Anyone selling certainty here is selling inventory.

Miners did not cast 150 individual ballots

A pool label on a block is not a complete decision trail.

Coinbase tags and monitoring heuristics can attribute a block to a pool brand. They usually cannot tell us which independent hasher supplied the work, whether the pool or miner built the template, who selected transactions, or whether a bit expressed politics, readiness, version rolling, or software default.

This case makes the distinction impossible to ignore. The ordinary branch included two blocks attributed to OCEAN with bit 4 unset, while the two enforcing-branch blocks were attributed to Ocean.xyz.[3][4] OCEAN had offered different endpoints, and DMND says Job Declaration miners control their own templates and version fields.[15][16]

“Miners rejected BIP-110” is therefore too broad. The verified statement is narrower: at the cutoff, observed work overwhelmingly extended the ordinary non-signaling history. Intent requires operators to answer questions.

What the work result proved

It proved that, under the observed software perspectives and at the frozen cutoff, the ordinary branch had accumulated far more valid proof of work for nodes that accepted both histories.

It proved that BIP-110's voluntary threshold had not been reached.

It proved that mandatory-signaling enforcement created two accepted-history perspectives at the same height.

It proved that greater work does not make an enforcing node accept a chain its added rule classifies as invalid. Reconnection requires a software or configuration change, or a BIP-valid history that eventually overtakes in work.

And it proved that public support claims, node counts, and social intensity did not automatically become continuing hashpower.

What it did not prove

It did not prove that users, economic nodes, or “the community” voted against BIP-110.

It did not prove every hasher consciously chose non-enforcement. Defaults at pools, software packages, and endpoints may have made many decisions upstream.

It did not validate Bitcoin Core 30's OP_RETURN policy. A failed or weak activation path can reject a remedy without endorsing the condition that provoked it.

It did not prove arbitrary-data use legitimate, useful, or socially accepted.

It did not test BIP-110's seven reduced-data restrictions in production.

It did not establish permanent mathematical finality. A signaling branch valid to both rule sets could theoretically overtake in work, though the observed deficit made that increasingly remote.

And it did not prove nobody was harmed. That requires service records, wallet incidents, miner accounting, and interviews—not vibes wearing a hard hat.

Economic services: mostly preparation, little aftermath

Before the height, Start9 published operator guidance, Crypto Finance discussed custody and replay implications, and Bitaroo said it would communicate any temporary deposit or withdrawal measures if a split appeared likely.[17][18][19]

At cutoff, we had not recovered a directly hosted post-height operational notice from a major global exchange, major wallet, major pool, Bitcoin Core as a project, Dathon Ohm, Luke Dashjr, or Lopp. That is a search-negative finding from this reporting pass, not proof that no statement exists.

The absence matters because chainwork is only one layer. Exchange recognition, custody accounting, wallet behavior, merchant acceptance, and miner revenue are how a fork acquires—or fails to acquire—economic weight. We can observe the work result now. The economic record remains incomplete.

Unresolved questions

Who selected the two competing 961,632 templates? What did AntPool's and OCEAN's participating hashers intend? Did any enforcing miner lose revenue measured in a market anyone could access? Which exchanges or custodians paused, credited, quarantined, or ignored the two-block branch? Did any Lightning user, wallet, or presigned transaction encounter replay or balance problems?

Will BIP-110 enforcement remain maintained? Is the two-block branch still intended to continue? What evidence would its proponents accept as failure? What safer alternative would critics support for the externalities they acknowledge? And what measurable outcome would Core contributors accept as proof that the v30 OP_RETURN default improved the network rather than merely changing what the dominant client calls normal?

Those are right-of-reply questions, not rhetorical furniture. Publication should wait for answers or a disclosed deadline.

Methodology

FF2K froze the cutoff at 2026-08-09T22:17:21.209859Z. We fetched the final BIP text, implementation and release records, dual-node fork telemetry, and a signaling feed.[1][2][3] We cross-checked fork.observer and independent main-tip endpoints from mempool.space and Blockstream.[4][5][7] We calculated exact chainwork from linked headers using the per-block proof formula and preserved the result in a frozen JSON snapshot.

Header timestamps are miner supplied, so we do not present them as propagation or first-seen times. Pool names are monitor attributions, not proof of individual identity or motive. Faction descriptions are attributed. Inferences are labeled. Service statements that were not recovered are not treated as nonexistent.

The chain settled one question at this cutoff: which observed history carried the work.

The rest still requires reporting.

Everybody has an angle. Blocks have hashes. Confusing the two is how propaganda gets dressed as a post-mortem.

Sources

  1. https://github.com/bitcoin/bips/blob/master/bip-0110.mediawiki
  2. https://bip110.orange.surf/api/nodes
  3. https://bip110.orange.surf/api/signaling
  4. https://fork.observer/api/1/data.json
  5. https://mempool.space/api/blocks/tip/height
  6. https://mempool.space/api/blocks/tip/hash
  7. https://blockstream.info/api/blocks/tip/height
  8. https://blockstream.info/api/blocks/tip/hash
  9. https://bip110monitor.com/api
  10. https://bip110.org
  11. https://github.com/bitcoin/bitcoin/pull/32406
  12. https://bitcoincore.org/en/releases/30.0
  13. https://github.com/bitcoinknots/bitcoin/releases/tag/v29.3.knots20260508
  14. https://github.com/bitcoin/bitcoin/pull/34930
  15. https://blog.dmnd.work/miner-signaling-via-dmnd-stratum-v2-you-decide-what-to-signal
  16. https://www.linkedin.com/posts/ocean-mining_today-ocean-is-launching-two-additional-activity-7480591626386702336-7gHT
  17. https://start9.com/bip110
  18. https://www.crypto-finance.com/bip-110-and-the-custody-implications-of-a-bitcoin-chain-split
  19. https://www.bitaroo.com.au/bip-110-in-august-what-might-happen-and-how-to-prepare
  20. https://blog.lopp.net/a-laymans-guide-to-bip-110
  21. https://github.com/bitcoin/bips/commit/f952fd1fc0a8f4921bddba7b7fe0561ca6c6e036
  22. https://github.com/bitcoin/bips/blob/master/bip-0003.md
  23. https://ff2k.us/trent-jones/the-default-is-the-message-bip110-opreturn-bitcoin-core