The Bitcoin BIP-110 chain split is a practical reminder that mining operations depend on more than raw hashrate. When nodes apply different acceptance rules, pools can build on the same parent block yet produce competing blocks that different parts of the network accept or reject. For operators, the immediate task is not to take a position on the proposal. It is to identify the chain each template targets, measure acceptance under relevant node rule sets, protect settlement processes, and communicate evidence-based conditions to miners.
This article examines the observable split at block 961,632 on 2026-08-08 as an operations case study. It distinguishes the BIP-110 specification from subsequent branch observations, explains why two tips can emerge, and sets out controls for Bitcoin mining pool chain split incidents.
The 2026-08-08 split at Bitcoin block 961,632
Competing Bitcoin branches became observable at block 961,632 on 2026-08-08 after BIP-110-enforcing nodes rejected a non-signaling block on the dominant chain. Contemporary reporting described rival blocks at that height.
For a mining pool, the key operational fact is that divergence can begin at a single parent. One pool may receive or construct a block template whose previous-block hash references a tip accepted by its relevant nodes, while another may work from a competing tip. Both candidate blocks can have the same height and parent while containing different transactions, coinbase data, signaling, or other template differences. Acceptance depends on the node rule set evaluating the block.
That does not determine a branch's legitimacy, permanence, or market value. It signals changed operating conditions: pools, miners, wallets, exchanges, and monitoring systems may no longer be observing one universally accepted tip.
What BIP-110 specified before the split
BIP-110 is titled Reduced Data Temporary Softfork in the Bitcoin BIPs repository. It is specified as a consensus soft-fork proposal, not as a normal Bitcoin Core activation.
Its deployment specification set a threshold of 1,109 of 2,016 blocks, or 55%. It also defined a BIP-110 mandatory signaling period from block 961,632 through block 963,647. During that period, signaling is part of the proposal's specified deployment behavior, not merely an indicator of support.
The specification identifies two later milestones:
- Block 963,648 as the forced lock-in height.
- Block 965,664 as the height at which the proposed data rules would take effect.
These are proposal heights, not proof that the intended sequence occurred identically on every observed branch. During a split, operators must distinguish the written deployment schedule from the block history and rule enforcement visible to a particular node set.
A pool should record the exact block hash, parent hash, version signaling, local node response, peer propagation, and submitted-block outcome at relevant heights.
Mandatory signaling, acceptance rules, and why two tips emerged
BIP-110 mandatory signaling illustrates how Bitcoin consensus split operations can turn version fields and template policy into immediate production concerns. If one set of nodes enforces a requirement that another set does not, a block may be accepted by the latter and rejected by the former. Once miners extend different accepted tips, competing branch histories can develop.
Shared parents can lead to different blocks
At a shared parent, two blocks at the next height may differ in transactions, coinbase data, timestamp, version bits, or other valid template choices. Under one rule set, a non-signaling block may remain acceptable. Under an enforcing rule set, that same block may be rejected. The next block produced by miners following each view will reference a different previous-block hash.
A pool therefore cannot infer its effective mining target from height alone. Height is an ordering label; the block hash and parent relationship identify the branch a template extends.
Rule sets define acceptance
A block's acceptance is evaluated by software applying a specific set of consensus rules. During a contentious activation, independent nodes should be configured for each rule set that may create divergent acceptance. Pools should compare outputs rather than assume their default production node represents every relevant network view.
The practical question is which template the pool distributes, which nodes accept it, and what evidence supports accounting and settlement decisions. Those questions are more actionable than trying to resolve a broader policy dispute during an incident.
Dominant chain versus minority chain: use precise operational language
A Bitcoin minority chain is generally the branch with less observed accumulated work, mining activity, propagation, or ecosystem support at a particular time. These labels are operational shorthand, not permanent conclusions. A branch comparison depends on the measurement method, node connectivity, and observation time.
Pool operators should describe what they can verify: independent node tips, observed cumulative-work differences where available, block propagation, accepted submissions, and confirmation behavior. They should avoid presenting a dashboard's inferred pool attribution, node count, or short-lived height gap as conclusive proof of network-wide consensus.
A branch behind in height is not automatically behind in every relevant measure, and a branch ahead in height is not automatically safe for every settlement workflow. Confirmation-risk assessments must consider the rule environment, work accumulation, reorganization potential, and the policies of counterparties handling deposits or withdrawals.
The reported early chain status and its limits as a time-stamped snapshot
Contemporary reporting stated that by 6:00 p.m. ET on 2026-08-08, the dominant chain was at height 961,640 while the BIP-110 branch was at height 961,633, seven blocks behind. This was an early incident snapshot, not a statement of the branch's current condition.
Bitcoin fork monitoring must treat such observations as time-stamped telemetry. Subsequent blocks, changes in miner behavior, peer connectivity, software configuration, exchange policies, or chain reorganizations can alter the practical risk picture.
An incident report should preserve the source, collection time, time zone, node configuration, observed hashes, and caveats. A statement such as “seven blocks behind” is incomplete without identifying the branch comparison and observation time.
What a mining pool must monitor during a consensus-rule disagreement
A Bitcoin mining pool chain split requires a monitoring model that tests production assumptions independently. Nominal hashrate is important, but it does not establish which templates are being built, which node policies accept them, or whether a pool's payout workflow is exposed to a divergent chain.
Independent tips and previous-block hashes
Run independently operated monitoring nodes configured for the rule sets relevant to the disagreement. At minimum, compare:
- Best-block hash and height from each node.
- Parent relationships around disputed heights.
- Cumulative-work information where the node exposes it.
- The previous-block hash included in every production and failover template.
- Version bits and other Bitcoin miner signaling fields used by the template.
A pool's template service should log the upstream source, creation time, job identifier, previous-block hash, version, coinbase construction, and distribution scope. If a template switches branches, that transition should be visible in alerts and audit records rather than discovered after shares have been submitted.
Peer behavior, work, and confirmation indicators
Monitor peer connectivity and relay behavior separately from the pool's primary production path. A node can have a local tip without demonstrating broad propagation. Compare what independent nodes receive, whether candidate blocks are relayed or rejected, and how quickly a relevant node set advances.
Also monitor confirmation-risk indicators for the assets and workflows in scope. These may include subsequent blocks under each observed rule set, chainwork comparisons, reorganization events, deposit-credit thresholds, and counterparties' published policies. Do not reduce this to a single number: the appropriate response depends on whether the pool is crediting shares, making a normal payout, or supporting a customer-facing external transfer.
Block templates, version signaling, and submitted-block acceptance
Bitcoin block template monitoring should connect the pool's job-generation layer to node-level validation. During a disagreement, a template can be technically well-formed while still being rejected by nodes enforcing a different consensus interpretation.
First, validate that every production template references the intended previous-block hash. A stale or unexpected parent hash can cause miners to spend hashrate on a branch the operator did not intend to extend. Next, retain the exact version and signaling data provided to miners. BIP-110 mandatory signaling makes this especially important because a visible signaling choice may affect acceptance under an enforcing node set.
Submitted-block telemetry should record whether the pool found a block, the exact block hash, submission target, RPC response, rejection reason where supplied, and later visibility from independent nodes. A successful local submission is not the same as broad acceptance. Conversely, a rejection from one node must be interpreted in the context of that node's configured rules and synchronization state.
Operationally, use a controlled change process for template-source changes. Require a second reviewer or automated invariant check when the parent hash, node policy, version configuration, or payout assumptions change during an active split. This reduces the chance that a hurried mitigation creates a separate template-selection error.
Settlement, confirmations, and communication with pool miners
Mining-share accounting, block discovery, pool crediting, and external settlement are related but distinct processes. During a rule disagreement, pool operators should document the chain view used for each process and state any temporary controls clearly.
For example, an operator may need to review whether a found block is accepted by the node set used for accounting, whether that chain remains the intended production target, and whether external counterparties recognize deposits from that branch. These are separate evidence questions. They should not be collapsed into an assurance that all balances or transfers are unaffected.
Miner communication should be factual and dated. A useful notice can state:
- The observed chain tips and the timestamp of observation.
- The template parent hash and rule-set monitoring method.
- Whether any temporary confirmation or settlement review is in place.
- What is known, what remains under verification, and when the next update will be issued.
Avoid speculative language about permanent outcomes, losses, or another party's policy. Clear disclosure helps miners understand the chain being mined and the basis for pool settlement without overstating certainty.
How to design independent fork monitoring without over-trusting dashboards
Independent monitoring is strongest when it uses nodes under the operator's control and makes their rule configuration explicit. The BIP-110 Observer describes its chain comparison as requiring separate Bitcoin Core and Bitcoin Knots nodes. It also notes that a node-count sample does not measure support for BIP-110.
That limitation matters. Node counts can describe a sample of reachable nodes, but they are not a proxy for consensus support, economic acceptance, or the work securing a branch. Likewise, dashboard labels and pool attribution may be estimates based on public data rather than direct statements from operators.
Before relying on any dashboard as a settlement source, understand its methodology, collection interval, data provenance, peer-selection bias, outage behavior, and stated limitations. Use it alongside independent node data, template logs, submitted-block results, and direct counterparty notices.
A resilient design separates observation from production. Production nodes can prioritize reliable template delivery, while monitoring nodes compare relevant acceptance rules, collect evidence, and trigger alerts without silently changing the pool's mining target.
A practical incident checklist for pool operators
When divergent Bitcoin acceptance rules are suspected, use a controlled checklist:
- Freeze and preserve template, node, and submission logs around the first disputed block.
- Record best-block hashes, heights, parent hashes, and chainwork from independent nodes configured for each relevant rule set.
- Confirm the previous-block hash and version signaling on every active mining template.
- Check whether found blocks are accepted, rejected, or absent across the relevant node views; retain exact responses and timestamps.
- Assess peer relay and propagation without using a single dashboard as definitive evidence.
- Review confirmation thresholds, settlement dependencies, exchange deposit and withdrawal policies, and wallet operations before making external-transfer decisions.
- Publish a dated miner notice describing the observed conditions, template target, accounting basis, and unresolved questions.
- Establish an incident owner, review cadence, rollback criteria, and escalation path for engineering, support, and compliance teams.
This process does not decide which proposal should prevail. It makes the pool's Bitcoin block template monitoring and operational decisions auditable under uncertainty.
Lessons for future contentious Bitcoin upgrades
The main lesson of the Bitcoin BIP-110 chain split is that consensus disagreements become operational events before they become settled history. Pools need independent node views, template-level observability, block-submission evidence, settlement controls, and disciplined communication.
The BIP-110 specification provides defined signaling, lock-in, and activation heights. Actual branch conditions still require current verification. Operators that separate specified rules from observed network behavior will be better positioned to manage future contentious upgrades without overstating what their monitoring can prove.
Before publication or operational action, recheck the current state of both branches, the current BIP-110 status, relevant exchange policies, and any applicable pool notice. Chain conditions and counterparty treatment can change quickly.