BIP-110 Keeps Moving Toward Its Flag Day Despite Near-Zero Miner Support

What BIP-110 Would Change in Bitcoin

BIP-110 is a Bitcoin Improvement Proposal authored by a pseudonymous developer who goes by "Dathon Ohm." The proposal was merged into the official bitcoin/bips repository as a Draft on February 7, 2026, via GitHub pull request #2017. A separate implementation pull request, #34930, filed against Bitcoin Core, contains the actual code that full nodes would need to run if the proposal activates.

The core rule is a byte-size cap on transaction output scripts. New output scriptPubKeys — the tiny scripts that lock bitcoin to a receiving address — would be capped at 34 bytes, or 83 bytes when using an OP_RETURN marker. Individual data pushes within those scripts would top out at 256 bytes. Those limits would make it difficult to embed the large data payloads that Ordinals inscriptions and BRC-20 tokens currently require.

BIP-110 does not mention Ordinals, BRC-20, or Runes by name. The limits apply to all script data equally, so any future technique that stores large payloads in transaction outputs would face the same restriction. Reports have surfaced that some Ordinals developers explored fragmentation workarounds, but no organized primary-source response from major developers has been confirmed. The bitcoin/bips repository remains the authoritative record of the proposal's scope.

• New output scriptPubKeys: capped at 34 bytes
• OP_RETURN outputs: allowed up to 83 bytes
• Individual data pushes inside scripts: capped at 256 bytes

How a User-Activated Soft Fork Skips the Miner Vote

A traditional Bitcoin soft fork uses a process called BIP9, in which miners signal readiness by setting a bit in the block header. When 95% of blocks in a two-week window — called a difficulty period — signal yes, the change locks in automatically. That majority vote gives miners effective veto power: if they stay quiet, the proposal simply expires.

BIP-110 uses a modified BIP9 with version bit 4 and a lower threshold of 55%, equal to 1,109 of the 2,016 blocks mined per difficulty period. More importantly, it adds a mandatory-signaling clause. After block 961,632, nodes enforcing BIP-110 rules treat any block that does not set version bit 4 as invalid — regardless of how much hash power built that block. That clause is the mechanism that makes BIP-110 a UASF.

UASF stands for user-activated soft fork. In a UASF, economic nodes — wallets, exchanges, and businesses that accept bitcoin — enforce the new rules even if most miners do not. The precedent comes from 2017, when BIP148 threatened to reject non-SegWit blocks and contributed to SegWit's eventual activation. BIP-110's version is weaker: far fewer nodes and essentially no major exchanges have publicly committed to running the enforcing software.

The Miner Signaling Numbers in Detail

The BGeometrics tracker has logged BIP-110 signaling data daily since March 2026. As of early August 2026, roughly 41 of the approximately 1,674 recent blocks counted were signaling support — about 2.45%. The peak came on June 7, 2026, when four blocks signaled in a single day. The first-ever signaling block was mined on March 1, 2026, by Barefoot Mining through Ocean Pool.

The gap between 2.45% and the 55% threshold is not a matter of rounding. Reaching 55% would require 1,109 signaling blocks in a single 2,016-block difficulty period. At the current run rate, that level is nowhere in sight. Adam Back publicly opposed BIP-110 in February 2026, calling the activation method a dangerous precedent for bypassing consensus, according to multiple independent outlets covering the Bitcoin development debate.

The bitcoin mining dashboard tracks pool-level signaling in near-real time, making the gap between signaling intent and economic weight visible. Mining pools control which version bit their software sets, and the pools representing the vast majority of global hash rate have not adopted the BIP-110 signal. Without pool adoption, there is no organic path to 55% before the proposal's September flag date.

The Block-Height Timeline to September

BIP-110's activation schedule is tied to specific block heights rather than calendar dates, because Bitcoin produces blocks at an average of one every ten minutes but the actual pace varies. The mandatory-signaling window opened around block 961,632, which on-chain data places at approximately August 7–8, 2026. Nodes running the enforcing software treat any block after that height that lacks version bit 4 as invalid.

If enough nodes enforce the rule, the next milestone is lock-in at block 963,648, followed by full activation at block 965,664 — projected for around September 1, 2026. At that point, BIP-110-enforcing nodes would permanently reject transactions that violate the byte caps. The mempool on those nodes would also refuse to relay transactions containing oversized output scripts, so broadcasters would need to find non-enforcing relay paths.

BIP-110 contains an automatic expiry clause. If activation does not happen, the proposal lapses after approximately 52,416 blocks — roughly one year from when signaling opened. That built-in sunset means the proposal cannot linger indefinitely. The outcome depends entirely on which nodes accept which blocks after the mandatory-signaling height, not on bitcoin's price or trading volume at the time.

Why Near-Zero Miner Support Does Not Stop BIP-110 From Reaching Its Flag Day

The UASF mechanism has no automatic kill switch based on miner participation. A traditional soft fork driven by miner votes dies quietly if the threshold is never reached — miners simply stop signaling and the proposal expires. BIP-110's mandatory-signaling clause inverts that dynamic: non-signaling blocks are the ones rejected by enforcing nodes, not the reverse. The proposal's block-height clock keeps advancing regardless of what mining pools choose to signal.

The practical consequence depends on how many economic nodes run the enforcing software. With roughly 2–3% of nodes enforcing and essentially zero hash power voluntarily signaling, the realistic outcome is a transient minority fork rather than a protocol change that touches mainstream bitcoin markets. The majority chain — built by non-enforcing miners — would continue under current rules and carry almost all economic activity.

BIP-110 reaching its flag day is not the same as BIP-110 winning. The UASF design ensures the proposal arrives at its activation block on schedule, but economic gravity determines whether that chain carries any lasting weight. In that sense, near-zero miner support does not stop BIP-110 from reaching its flag day — it just tells you something important about what the network will do after the flag drops.