Short answer
The answer in plain English
Yes. BIP-110 nodes reject some blocks that ordinary Bitcoin nodes accept, so the two groups can disagree about the valid chain. With miner support far below the proposal's threshold, the likelier result is not two equal Bitcoins but stalled BIP-110 nodes or a small minority chain while the majority-work chain continues under today's rules.
Why it matters
What to understand
BIP-110 is a temporary soft-fork proposal intended to make large arbitrary-data payloads harder to place on Bitcoin. Its software entered mandatory signaling at block 961,632 even though voluntary miner support remained very low. That does not force all miners to adopt the rules. It creates a coordination test among miners, nodes, wallets, exchanges, and Lightning operators—and a possible chain split when they do not agree.
Visual guide
How the pieces fit together
The short answer: a split is possible, but symmetry is unlikely
BIP-110 can split Bitcoin because it makes some blocks invalid for people 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. With signaling far below the proposal’s 55 percent threshold, BIP-110 nodes are more likely to stop advancing or follow a much smaller chain than to displace the chain recognized by most miners, services, and users.
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. On August 9, after that block had passed, the public signaling monitor showed period 477 underway with zero signals among its first 67 blocks. The preceding full period recorded 51 signals, or 2.53 percent.
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.
That leaves the deeper disagreement intact. One side emphasizes neutral access to block space under objective fees and validity rules. The other emphasizes the long-lived burden placed on nodes and Bitcoin’s intended monetary function. BIP-110 turns that philosophical dispute into a live coordination test. Its outcome depends less on the word mandatory than on whether the people producing, validating, and economically using Bitcoin converge on the same rules.