The short answer: a split is possible, but symmetry is unlikely
BIP-110’s design makes some blocks invalid for nodes running its rules while those same blocks remain valid for ordinary Bitcoin nodes. If miners keep building those old-rule blocks, the two sets of nodes no longer share the same chain tip.
That does not automatically create two equally viable versions of Bitcoin. A chain needs continuing proof of work and economic acceptance, not merely computers that reject the majority chain.
As checked on November 1, 2026, the BIP repository marks the proposal Closed. The signaling monitor has stopped updating after block 963,648 and reports divergence by enforcing nodes. The explanation below concerns that proposal and its coordination risk; the monitor is no longer a live measure of Bitcoin support.
What BIP-110 actually restricts
The proposal is formally titled the Reduced Data Temporary Softfork. For roughly one year after activation, it would cap most new output scripts at 34 bytes, retain an 83-byte allowance for OP_RETURN, and limit many pushed data fields and witness items to 256 bytes. It also restricts several Taproot and future-upgrade mechanisms, including annexes, deep control blocks, undefined witness versions, OP_SUCCESS opcodes, and executed OP_IF branches in Tapscript.
These are consensus rules, not recommendations. An enforcing node rejects a whole block if a newly created output or spend violates them. Outputs created before activation are grandfathered, reducing the chance that older coins become unspendable while the temporary rules are active.
The motivation is explicitly anti-data. Ordinals inscriptions and similar techniques can place images, text, or other files in transaction witness data. Supporters argue that miners collect a one-time fee while node operators inherit continuing download, validation, and storage costs. Critics answer that valid, fee-paying transactions should not be judged by their purpose and that a determined user can encode data around the proposed limits.
Why Bitcoin Core 30 matters—but did not change consensus
Bitcoin Core 30 intensified the argument by changing default relay and mining policy for OP_RETURN. Its release notes raise the default data-carrier setting to 100,000 bytes and permit multiple OP_RETURN outputs, with the normal transaction-size ceiling becoming the practical limit.
Policy is a node’s filter for unconfirmed transactions. A node can refuse to relay a transaction, yet still accept a valid block containing it if a miner received it elsewhere. Consensus is the harder boundary: violating it makes the block itself unacceptable. Core 30 changed the first layer. BIP-110 attempts to move several restrictions into the second.
What happened at block 961,632
BIP-110 uses version bit 4 and a threshold of 1,109 signaling blocks within a 2,016-block difficulty period—55 percent. Voluntary signaling never approached that level. Nevertheless, its deployment contains a mandatory-signaling phase beginning at block 961,632.
“Mandatory” describes what BIP-110 software demands, not a switch inside Bitcoin that commands every miner. The public signaling monitor’s final record gives period 477 as zero signaling blocks out of 2,016. The preceding period recorded 51 signals, or 2.53 percent. Its closing notice says enforcing nodes diverged from the chain it tracked; it does not provide a continuing record of any enforcing branch.
If a non-signaling block arrives, standard Bitcoin Core nodes can accept it. BIP-110 nodes reject it. Without miners building an alternative from the last shared block, the stricter nodes simply appear stuck. With a small amount of supporting hash power, they can advance on a minority branch, but blocks would arrive slowly until mining difficulty adjusted—and economic services would still have to choose whether that branch represents Bitcoin to them.
Why a “soft” fork can still split a chain
A soft fork narrows the set of valid blocks. When adoption is coordinated, old nodes accept the stricter chain because every new-rule block also satisfies the old rules. Compatibility only runs one way: new nodes reject some old-rule blocks.
That asymmetry is exactly where a split can form. If most miners keep producing old-rule blocks, enforcing nodes separate themselves. The word soft describes compatibility under successful adoption; it does not guarantee a peaceful activation or broad support.
Signaling is also not the same as enforcement. A miner can set bit 4 without validating transactions under BIP-110. That could postpone visible disagreement until the data restrictions activate. Bitcoin governance therefore cannot be reduced to a miner poll: node operators choose validation software, miners construct blocks, and exchanges, wallets, merchants, and users decide which chain they recognize.
Wallet and Lightning risks come from chain disagreement
Ordinary payment outputs generally fit within BIP-110’s limits, and grandfathering protects older outputs from the new spending restrictions. The proposal is not designed to invalidate a normal person-to-person payment simply because it transfers bitcoin.
Lightning’s standard channel transactions also fit the proposed sizes, according to Amboss’s transaction-level review. The greater danger is visibility. A Lightning node watches the base chain for channel closures and outdated states. If its Bitcoin backend stalls or follows a losing branch, it may not see an action on the economically dominant chain within the available response window. Wallets and exchanges face related uncertainty over deposits, confirmations, and possible replays.
This is why operators treat a contested fork as an operational event even when they expect the minority branch to fade. More confirmations, temporary pauses, and explicit software choices are responses to uncertainty, not proof that both chains have equal standing.
BIP-110 raises the cost of data; it cannot erase steganography
BIP-110 blocks several convenient routes for contiguous payloads, including the large witness items used by many inscriptions. It does not make information impossible to hide. Data can be divided into smaller pieces or encoded inside structures that also have a script-like meaning.
The specification acknowledges this limitation. Supporters see higher cost and inconvenience as useful: Bitcoin would stop presenting easy arbitrary-data storage as a supported use. Critics see an unfavorable trade—consensus risk and constrained script experimentation without a complete technical ban.
The deeper disagreement remains: neutral access to block space under fee and validity rules versus the long-lived storage burden and Bitcoin’s intended monetary function. BIP-110 made that dispute concrete by asking nodes to reject blocks other participants could accept. Its completed monitor establishes very low signaling on the tracked chain; it does not measure the viability of a separate branch. The general lesson is about rule agreement, not the reassuring sound of the word soft or the commanding sound of mandatory.
Visual guide
How the pieces fit together
