BIP-110's Chain Split, Explained

A block height is not a consensus change. It is only a number in the chain until independently validating nodes enforce new rules. CoinDesk's headline read: "Bitcoin hits block 961,632 as the controversial BIP-110 soft fork attempt begins." That's an accurate report of an operational event. It is not, on its own, a reason to touch your miner configuration.

For miners, the question is not whether BIP-110 has a memorable activation height, a loud opposition, or a louder counter-movement. The question is precise: what rules does the proposal change, what activation condition does it define, and which nodes will actually reject a block that violates it?

What BIP-110 Actually Changes

BIP-110, the "Reduced Data Temporary Softfork," writes seven consensus rules aimed at data-carrying transactions rather than payments. Per its own technical summary: new output scripts cap at 34 bytes (payment outputs excepted), OP_RETURN outputs cap at 83 bytes, data pushes and witness items cap at 256 bytes, Taproot control blocks cap at 257 bytes, undefined witness versions and Taproot annex fields become invalid to spend, and OP_SUCCESS/OP_IF/OP_NOTIF are disallowed in Tapscripts. UTXOs created before activation are grandfathered — no deadline to move funds, existing inscriptions untouched. The rules expire on their own 52,416 blocks after activation, about a year, with no vote required to sunset them.

That's the entire technical content of the proposal. Everything else — the block height, the headline, the hashtag — is commentary on top of it.

The Split, As Far As It's Actually Been Verified

At block 961,632, the mandatory signaling window opened. When the first block arrived without the required version-bit-4 signal, nodes actively enforcing BIP-110 rejected it and diverged onto their own chain. Reporting from that day describes what's left on that side as close to a ghost network — no exchange infrastructure waiting to receive it, single-digit miner interest, and a difficulty mechanism that assumes far more hashrate than a minority chain actually has, so blocks on it arrive slowly if at all.

How slowly: an hour before this was written, Ordinals advocate Leonidas posted live that "the BIP-110 supporters just forked off of Bitcoin and created their own chain that now has two blocks." Two blocks, hours into the window — that's the minority chain's entire output so far, and it's a fair independent confirmation of just how little hashrate actually followed the rule change. Whatever the exact depth is by the time you're reading this, a live fork monitor will tell you more accurately than this paragraph will.

Meanwhile the chain carrying the network's actual hashrate — the one every exchange, wallet, and payment processor is still built on — kept adding blocks at its normal pace the entire time. Whether you call that "a split" or "a rounding error" depends on which chain you're asking about, and that's worth sitting with: the same event can be a real fork and a non-event, depending on how much of the network actually followed it.

Miner Support Was Never Close

A live signaling monitor read 0.00% of blocks signaling in the current difficulty period at the time this was checked. Press coverage through the week put the trailing rate anywhere from roughly 0.3% to 2.6%, depending on the exact window measured — CoinDesk put it at "seldom exceeding 2.5%." All of it is a long way from the 55% supermajority the proposal needs inside a single 2,016-block period to lock in.

Foundry structured an internal vote that keeps the pool signaling "No" with every block until "Yes" votes cross 51% of its own participating hashrate — weighted by each customer's ten-day average — and that threshold hasn't been crossed. AntPool and ViaBTC haven't moved either. Signaling has come mostly from Ocean and a long tail of smaller operations.

None of that is coincidence. Ordinals and Runes activity pays real transaction fees, and BIP-110 exists specifically to restrict the traffic that produces them. A pool declining to signal against its own revenue isn't making an ideological statement. It's doing arithmetic.

These numbers move by the block. Check the live monitor before repeating any figure in this article, including the ones above.

Opposition Is a Signal, Not a Consensus Rule

Two of Bitcoin's more prominent voices went on record against the proposal this week. Michael Saylor called it "a consensus change that would invalidate some currently valid, fee-paying transactions." Adam Back opposed it publicly as well. Mark "Murch" Erhardt, a Bitcoin Core BIP editor, was blunter, calling it "a misguided and unusually careless softfork proposal."

That opposition is real information about coordination risk — it says this proposal doesn't have quiet consensus even among people who review Bitcoin's rules for a living. It isn't a vote that settles anything, in either direction. Bitcoin's consensus is enforced by the software a node runs and the validation rules that software applies, not by whose account has more followers.

The Fight Isn't Two-Sided

Saylor, Back, and Murch are arguing BIP-110 shouldn't exist at all. On the other side of the room, Leonidas — the Ordinals and Runes advocate whose activity the proposal specifically targets — has spent the run-up arguing something closer to the opposite. Three days before the window opened, he wrote: "The sole purpose of this proposal is to attack Ordinals and Runes. It will fail to gain consensus and result in a minority fork that will have little to no adoption." That prediction is, so far, what happened.

His response wasn't a lobbying push. It was a client. DOG Mode relaxes Bitcoin Core's relay policy rather than tightening it — near-block-size transactions, a dust limit cut to one satoshi. It only needs one miner willing to run it to pull the transactions BIP-110 wants restricted straight out of the mempool. That's the opposite direction from BIP-110, published by the same community BIP-110 was written to restrict.

Meanwhile the softfork camp has its own escalation in motion. Luke Dashjr has said, "if BIP110 doesn't pan out, the only option is a PoW change," and developer Chris Guida has confirmed rebasing Dashjr's 2017 proof-of-work hard fork code onto Bitcoin Knots as a contingency.

That's three positions, not two: a softfork camp willing to escalate to a PoW change if signaling fails, an opposition camp calling the softfork itself reckless regardless of its target, and a third camp treating the softfork as license to build something more permissive than what existed before it. None of the three has anywhere near the coordination needed to change what your hardware actually has to satisfy today.

What Miners Should Verify Before Changing Anything

Do not replace a known-good node, firmware image, or pool endpoint because a contentious proposal reaches a named block. Verify the exact BIP text and the source code you intend to run. Confirm the consensus rule, the activation condition, the boundary height, and the behavior before and after activation.

Run a fully validating Bitcoin node under your own control. Confirm which software release and commit implement the claimed behavior. Inspect release signatures and reproducible-build guidance where available. Test on a non-production environment before letting any changed template or policy touch live hashing.

If a proposal involves version signaling, inspect the actual block headers and distinguish signaling from activation — they are not the same claim. If it changes script or transaction validity, test known-valid and known-invalid transactions against the implementation directly. If it imposes a date or height-based rule, confirm the boundary against your own node's best chain, not a dashboard or a screenshot.

The same standard applies to pool infrastructure. Ask whether the pool constructs templates from its own fully validating node, whether you can inspect the work you're submitting against, and whether a solved block pays directly to your address. A pool account balance is a promise. A correctly constructed coinbase output is evidence you can check before you ever need it.

Where NexusPool Stands

NexusPool is not signaling for BIP-110. The pool takes the version field straight off getblocktemplate and hashes what the network handed it — no bit forced on, no bit forced off. That's not a position on Ordinals or Runes. It's the same rule the pool follows for every other consensus question: it doesn't get a vote your hardware didn't cast.

Pull your own node's getblocktemplate response and look at the version field yourself. Compare it against what a pool is actually submitting on your behalf. If those two numbers ever disagree, that's the moment to ask questions — not before.

We didn't take press numbers on faith for this one either. Sampling the last 200 blocks directly against our own Bitcoin node put version-bit-4 signaling at roughly 1.5%, independently measured rather than trusted from a headline — the same order of magnitude the press was reporting, arrived at without needing to believe the press. That's the whole method behind Glass Ledger and everything else this pool publishes: a claim is only as good as your ability to check it against a node you control.

If BIP-110 clears 55% before block 963,648, that changes. Until then, the changelog is the record of what the pool actually runs — not this article, and not a dashboard.

The Real Risk Is Coordination, Not the Softfork Itself

The protocol-level danger here was never that a soft fork is inherently suspect. Bitcoin has shipped soft forks before, including some that started with weak signaling. The danger is poorly understood activation, ambiguous implementation, or an operator assuming someone else already did the validation work.

Resist the opposite error too. Don't assume 1% signaling makes the proposal irrelevant forever. Under a hash-signaling model, that number is close to the whole story. Under a UASF model, it's only one input, and the number that actually matters is how many economically significant nodes enforce the rule once the deadline passes. That's exactly the question a live monitor answers better than a headline does.

Keep your node independent, keep your firmware pinned to reviewed releases, and keep the evidence needed to explain every change in your mining path. Trust nothing. Verify the rule your hardware is actually helping enforce.

---

Sources: CoinDesk, Aug 7 · TFTC · Cryptobriefing on the split · Cryptobriefing on Foundry's vote · Simple Mining Insights, technical summary · BIP-110 Signaling Monitor · Leonidas on X · CoinDesk on DOG Mode.