BIP-110 Explained: Rules, Signalling and Why It Closed

BIP-110 explained: the final status

The authoritative starting point is the BIP-110 record, not a social-media label or block explorer banner. Its current header marks the proposal Closed. The changelog says version 1.0.1, dated 9 August 2026, closed it “following a chain split with stalled mining”.

That sentence supports three careful conclusions. A split occurred in connection with the proposal, mining on the affected chain stalled, and the BIP was then closed. It does not by itself establish every pool’s intent, quantify economic support or show that the rules became part of the continuing Bitcoin chain. Claims beyond the official record require separate evidence.

The earlier 25 June 2026 change to Complete can be misunderstood. Within the BIP process, document status is not the same as economic consensus. A specification can be sufficiently complete as a document without being accepted by the network. The later Closed status controls any current summary.

The seven BIP-110 consensus restrictions

BIP-110 did more than restore a small OP_RETURN policy. It proposed consensus checks across output scripts, witness data and Taproot. These rules would apply for the temporary active period.

1. Output-script size

New output scriptPubKeys above 34 bytes would be invalid, except an OP_RETURN output script could be up to 83 bytes. The distinction matters because ordinary spendable output scripts enter the UTXO set until spent, while provably unspendable OP_RETURN outputs do not.

2. Large pushes and witness arguments

OP_PUSHDATA payloads and script-argument witness items above 256 bytes would generally be invalid. The final text retained exceptions for the BIP16 redeemScript push and distinguished executable scripts from the arguments supplied to them.

3. Undefined witness and Tapleaf versions

Spending undefined witness or Tapleaf versions would be invalid, although creating such outputs remained valid. The stated rationale was that currently unused upgrade space could carry unrestricted data during the temporary period.

4. Taproot annexes

Witness stacks containing a Taproot annex would be invalid. The annex is reserved by BIP341 for possible future meaning, so restricting it also removed an upgrade hook temporarily.

5. Taproot control-block size

Taproot control blocks above 257 bytes would be invalid. That allowed a Merkle proof for up to 128 script leaves under the BIP’s calculation but could constrain designs using very large script trees.

6. OP_SUCCESS opcodes

A Tapscript containing OP_SUCCESS would be invalid even if execution did not reach it. Under BIP342, these opcodes are deliberately reserved to make future soft-fork upgrades possible. BIP-110 would close that route during its active period.

7. Conditional Tapscript

Execution of OP_IF or OP_NOTIF in Tapscript would be invalid. The proposal argued that Taproot can often express alternative paths as separate leaves and that conditional execution had become a route for inscription data. Critics noted that legitimate script constructions and experimentation could also be affected.

Together, these were consensus restrictions, not merely mempool relay preferences. A miner including a transaction that violated them could produce a block accepted by ordinary nodes but rejected by BIP-110-enforcing nodes.

UTXO grandfathering and wallet risk

The final design exempted inputs spending UTXOs created before activation from the new spending restrictions. This grandfathering aimed to preserve the spendability of coins already locked in scripts that BIP-110 would otherwise reject. New outputs created after activation would be subject to the temporary rules.

Grandfathering reduced one class of risk but did not make every pre-signed transaction safe. A transaction chain prepared before activation might create an affected UTXO only when broadcast later. If a later spend depended on a prohibited Tapleaf, annex, control block or conditional path, the sequence could fail on the enforcing chain. The BIP itself acknowledged unlikely scenarios involving frozen or lost funds.

For custodians and wallet developers, the correct control was script-level inventory rather than a general statement that “Taproot is supported”. They would need to identify actual witness versions, key-path alternatives, Tapleaf structures, pre-signed transactions and when each UTXO was confirmed.

How the BIP-110 deployment mechanism worked

The final specification used a modified form of BIP9 version-bit signalling. Its deployment name was reduced_data, using bit 4. The stated start time was around 1 December 2025 and there was no ordinary time-based failure timeout.

Instead, the design used height 965,664, estimated around 1 September 2026, as a maximum activation point. It specified mandatory signalling from blocks 961,632 through 963,647, lock-in no later than 963,648 and activation one retarget period later. Once active, the rules would last 52,416 blocks, approximately one year, before expiring.

The temporary expiry was unusual. Ordinary consensus upgrades are designed to remain active. BIP-110 introduced an EXPIRED state after its active duration, at which point the extra restrictions would cease and affected UTXOs would again be unrestricted.

Why the 55% threshold mattered

Standard BIP9 examples commonly use a threshold close to 95% so that a permanent rule change locks in only after overwhelming miner readiness. BIP-110 set its threshold at 1,109 out of 2,016 blocks, approximately 55%. Its rationale was urgency and the temporary one-year duration.

A 55% threshold leaves up to approximately 45% of recent blocks outside the signalling set. Signalling also measures block production, not the views or upgrade readiness of exchanges, merchants, wallet providers, custodians, node operators and holders. Even miner signalling can be ambiguous when pools set the version field while individual hashers have limited visibility into the full block template.

The deployment’s mandatory-signalling phase added another fault line. During that window, enforcing nodes would reject blocks that did not signal bit 4. That rejection could happen before the proposed transaction restrictions became active. A non-signalling block could therefore extend the ordinary Bitcoin chain while being ignored by mandatory-signalling nodes.

The design attempted to force lock-in by a known height, but forcing a state transition is not the same as creating consensus. Where participants disagree about the legitimacy of the forcing rule, the mechanism can instead reveal the disagreement as separate chains.

How a soft fork can produce a chain split

Assume group A runs ordinary Bitcoin rules and group B runs BIP-110 enforcement. A block obeying BIP-110 is valid to both groups. A block that violates BIP-110 can be valid to A but invalid to B. If group A builds on that block while group B builds on the last mutually accepted block, two tips exist.

If B has a decisive and sustained majority, its chain may outpace the other chain and ordinary nodes can reorganise to it because B’s blocks remain valid under the old rules. If B has insufficient or intermittent hashrate, its chain may advance slowly or stop. Its users then see long confirmation delays while the ordinary chain continues.

This asymmetry explains both terms in the correct description. The rule change is a soft fork because it narrows validity. The operational event is a chain split because different nodes follow different tips. Calling the proposal a hard fork loses the technical distinction; claiming that a soft fork cannot split the chain loses the operational risk.

The official BIP changelog records a chain split with stalled mining and then closure. It is safer to state exactly that than to invent a permanent alternative coin, a successful activation or a network-wide emergency not established by the primary record.

Mining-pool and operator impact

Block-template compatibility

ASICs receive work derived from a candidate block. The node and pool decide which transactions enter that block and which version bits are set. An operator evaluating BIP-110 therefore needed to trace the entire path: validating node, template generator, pool, Stratum proxy, firmware and ASIC worker.

The BIP specified reduced_data in GetBlockTemplate and required the bit in vbrequired during mandatory signalling. Template consumers that did not understand a required deployment should not attempt to mine the template. A proxy that silently removed or replaced version data could create unexpected behaviour.

Accepted work and payouts

A pool can accept shares while its candidate blocks are rejected by another chain’s nodes. Share acceptance proves that the worker met the pool’s assigned difficulty, not that a block would be accepted by every Bitcoin participant. Operators needed pool-specific statements about node software, signalling, chain selection, payout confirmations and treatment of reorganised rewards.

Confirmation and treasury controls

Mining businesses should increase operational caution when chain views diverge. Coinbases require 100 blocks before they can be spent under Bitcoin consensus, but a payout service may use its own accounting and confirmation rules. Treasury staff should avoid assuming that a dashboard balance is final and should reconcile node tip, pool block status and wallet confirmations.

Failover

Automatic pool failover is useful for outages but dangerous when backup endpoints follow different rule sets. A fleet can switch chains without an operator noticing. Failover groups should therefore include an explicit consensus-policy check, not only latency, fee and uptime.

Operational lessons from BIP-110

• Read the current primary record. Old articles may still call the proposal Draft or Complete. The official status is Closed.
• Separate document status from deployment status. A polished specification and test vectors do not prove economic adoption.
• Map consensus above the ASIC. Hardware hashes. Nodes, pools and templates choose rules and transactions.
• Treat low-threshold activation as a risk input. Measure the possible non-enforcing share and the economic services not represented by miner signalling.
• Verify mandatory rules. A required version bit can split miners before the main transaction restrictions activate.
• Monitor independent chain evidence. Compare trusted nodes, block tips, work, timestamps and pool statements rather than relying on one explorer.
• Write a confirmation policy before an event. Define payout holds, treasury movements, customer credits and incident authority.
• Keep failover policy-aware. Backup pools and proxies must not silently change the chain rule set.
• Avoid categorical language. “Soft fork”, “chain split”, “closed proposal” and “active mainnet rule” describe different things.

The same discipline applies to other consensus proposals. Our SHA-256 mining guide explains the hardware layer, while the Stratum V2 article covers miner-to-pool communication. Neither algorithm choice nor Stratum version alone determines consensus enforcement.

Technical BIP-110 questions

Why did the BIP limit OP_RETURN to 83 bytes?

The proposal sought to restore at consensus level a long-standing small-data convention while retaining compatibility for protocols using compact provably unspendable outputs. The 83-byte figure includes the OP_RETURN output script structure, not simply an arbitrary file allowance.

Could users still place data in Bitcoin?

Yes. The BIP acknowledged that steganography and fragmented data cannot be eliminated completely. It attempted to make large contiguous embedding more difficult and remove several convenient routes.

Would ordinary P2WPKH and Taproot payments stop?

The proposal listed defined witness versions and was intended to preserve known monetary use. However, unusual Taproot scripts, annex use, large control blocks, future-version experiments and certain pre-signed transactions required specific review.

Did 55% signalling represent 55% of all miners?

It represented the share of blocks signalling in a 2,016-block period. Pools construct most block headers, so it did not directly count individual ASIC owners or economic nodes.

What does “stalled mining” mean?

It means the affected chain was not receiving enough continuing block production to progress normally. The official BIP changelog uses that description but does not, by itself, provide a complete pool-by-pool incident report.

Could BIP-110 be proposed again?

A future proposal could reuse ideas, but it would need its own specification, review, implementation and activation evidence. The current BIP-110 record is closed.

Conclusion

BIP-110 explained as a post-mortem is a useful warning against collapsing several questions into one. Its seven rules formed a soft fork because they narrowed block validity. Its 55% threshold and mandatory-signalling mechanism created a credible route to incompatible chain tips. The official record then closed the proposal following a chain split with stalled mining.

For a mining operator, the practical boundary is clear. Do not ask only whether an ASIC supports BIP-110, because an ASIC does not choose consensus. Ask which node validates the template, which pool constructs it, which version bits are required, how proxies handle the work, what the payout policy assumes and how the business responds when independent nodes disagree. That evidence-led approach is more durable than any slogan for or against a contentious fork.