BIP-110 enforcement has pushed a subset of Bitcoin nodes onto a minority chain after they rejected a block that did not signal support, exposing a very old fight in a fresh wrapper: who actually decides what counts as valid Bitcoin?
- Mandatory signaling: enforcement began at block 961, 632
- Low miner support: reported at 2.53%, with support rarely above 2.5%
- Chain split: enforcing nodes rejected non-signaling blocks and followed a minority chain
- Core dispute: reducing non-monetary data versus preserving open block space
According to reporting from CoinDesk and The Cryptonomist, BIP-110 is being treated as a user-activated soft fork, or UASF. In plain English, that means node operators can enforce new rules even if miners are not on board. If miners keep producing blocks that do not meet the new requirement, upgraded nodes simply say those blocks are invalid and move on. Bitcoin, as ever, does not care about feelings.
The enforcement rule described in the reporting hinges on version bit 4. Nodes running the BIP-110 rules reject blocks that do not set that signal. CoinDesk says mandatory signaling started at block 961, 632, with the signaling window running to block 965, 664. The Cryptonomist reports miner support at 2.53%, based on 51 of the last 2, 016 blocks, which is far short of a clean rollout.
That low support matters because it tells you this was never a broad, boring consensus upgrade. It was a pressure play. When the people making blocks mostly do not signal, and a subset of nodes refuses to accept those blocks, a split is the obvious result. The dominant chain keeps moving. The enforcing nodes peel off and follow their own rules.
The term fork gets thrown around a lot in crypto, usually with all the subtlety of a fire alarm. Here it means a divergence in chain history caused by different validity rules. It does not automatically mean a brand-new coin, and it does not always mean a permanent break. In this case, The Cryptonomist describes a minority chain splitting from the dominant Bitcoin network, but also says the breakaway chain is weak because it lacks hash power.
Nodes are the computers running Bitcoin software that verify blocks and transactions. Signaling is how miners indicate support for a proposed rule change, usually by flipping a version bit in blocks. A soft fork makes rules stricter, not looser. And a UASF is the blunt version of Bitcoin governance: users and node operators enforce the change first, then ask miners to catch up.
What is BIP-110 trying to do? The available reporting describes it as a proposal to reduce non-financial or non-monetary data on Bitcoin. The Cryptonomist says the broader goal is to curb data-heavy uses associated with things like inscriptions and other non-payment payloads. Supporters argue that block space is scarce and should not be turned into a public dump for random data. That view is not exactly crazy. Bitcoin is supposed to settle value, not moonlight as a global filing cabinet.
The proposal has a more specific technical shape as well. Research notes tied to The Cryptonomist say BIP-110, also referred to as RDTS, is the Reduced Data Temporary Softfork, attributed to pseudonymous developer Dathon Ohm with input from Luke Dashjr. The proposal is described as temporary, lasting roughly one year, or about 52, 416 blocks. It reportedly restricts many fresh output scripts to 34 bytes, caps OP_RETURN outputs at 83 bytes, limits certain data pushes and witness elements to 256 bytes, and temporarily constrains some Taproot functionality.
That is the kind of proposal that instantly lights a match under Bitcoin’s perennial culture war. Critics see anti-spam logic. Supporters see rule creep and a slippery slope toward censorship. Both sides have a point, which is exactly why this keeps happening.
The anti-spam case is straightforward: every byte used for non-monetary baggage increases storage and bandwidth costs for full nodes. If enough people start stuffing the chain with junk, the network becomes more expensive to run, which is bad news for decentralization. The freedom argument is just as straightforward: once people start deciding which valid data is acceptable, the line between policy and censorship gets blurry fast.
The names attached to the criticism are not subtle either. The material reviewed says Michael Saylor and Adam Back warned the move could split Bitcoin and cause nodes to reject transactions that are valid under the current rules. The point of that objection is simple: tightening validity rules can protect the network, but it can also carve off legitimate use cases and fracture consensus. That is not theory. That is Bitcoin governance doing what Bitcoin governance does best: making everyone slightly miserable.
The practical risk of a long-lived breakaway chain looks limited, at least from the reporting cited. With miner support hovering around 2.53%, the minority chain lacks the hash power needed for stable, economically meaningful block production. That means slower confirmations, poor user experience, and little reason for exchanges, wallets, or merchants to treat it as the real chain. A fork without enough mining muscle is usually just a very determined headache.
Still, even a weak split can create real operational mess. Wallet operators have to decide which chain to support. Exchanges have to manage replay risk and chain selection. Block explorers can get confused. Node software may need special handling if verdicts on prior blocks are stored in a way that pins a node to one side of the split. The StartOS and Bitcoin Knots documentation referenced in the research even describes a dedicated “Activate RDTS” task and a pre-RDTS option, which suggests the split behavior is not just theoretical hand-waving. It is something software maintainers are preparing for.
That brings the bigger lesson back into focus. Bitcoin is not governed by slogans, speeches, or Twitter threads. It is governed by what people run. Miners matter. Developers matter. But node operators decide what they personally accept as valid, and if enough economic participants adopt a rule set, the network bends around that reality. That is decentralization in the raw: messy, resistant to authority, and occasionally a complete pain in the neck.
BIP-110 also lands in a broader debate about what Bitcoin block space is for. Is it for nearly pure monetary settlement, with every unnecessary byte treated as a threat? Or is it a permissionless system where even unpopular uses should survive unless they break the actual rules? Bitcoin maximalists tend to favor hard limits and a narrow money-only mission. Free-speech and freedom-first advocates worry that once block inclusion becomes an ideological test, the protocol stops being neutral.
There is no clean moral victory here. Bitcoin does not need to become a junk drawer. It also does not improve when a small set of actors starts drawing bright lines around what counts as acceptable data. The tension between those views is not a bug in Bitcoin. It is one of the main things that makes Bitcoin worth paying attention to in the first place.
For readers who want the raw reference points behind the proposal, the current spec is available in bips/bip-0110.mediawiki at master, while operators looking at deployment details can also consult the Bitcoin Knots: Setup and Configuration Guide for StartOS. If you want the governance context, the old-school concept of a User Activated Soft Fork is exactly what is being invoked here.
That governance fight is why Bitcoin BIP-110 Enters Signaling Phase With Miner Support and the warning that Adam Back Warns BIP-110 Could Split Bitcoin Into a Minority matter beyond one policy battle. The same theme also shows up in broader analysis like BIP 110 and the Custody Implications of a Bitcoin Chain, because chain splits are not just ideological drama, they are custody, wallet, and exchange headaches in the real world.
And while BIP-110 is the immediate flashpoint, Bitcoin infrastructure has plenty of other landmines. If you are running nodes, you probably also want to keep an eye on Bitcoin Core Reveals CVE-2024-52911 Bug That Could Crash some Bitcoin nodes. Because apparently the universe decided Bitcoin users deserved both governance drama and software bugs at the same time. Charming.
Key questions and takeaways
-
What triggered the chain split?
Nodes enforcing BIP-110 rejected a block that did not signal support with version bit 4, which pushed them onto a minority chain. -
How much miner support did BIP-110 have?
Reported support was 2.53%, with support seldom exceeding 2.5%, which is far too low for a smooth rollout. -
What is BIP-110 trying to change?
It is aimed at reducing non-monetary data on Bitcoin by tightening rules around data-heavy transaction behavior. -
Is this a permanent fork?
The reporting points to a minority chain with weak hash power, so it looks economically fragile rather than durable. -
Why does this matter beyond one proposal?
It shows the core Bitcoin governance fight again: miners, node operators, and users still disagree on what should be valid block space. -
Why are critics worried?
Critics fear the proposal could reject transactions that are valid under current rules and set a precedent for tighter control over Bitcoin usage.
BIP-110 is less a neat technical upgrade than a reminder that consensus in Bitcoin is never tidy. When the rules are contested, the network does not settle the argument with speeches. It settles it with software, incentives, and hash power.
Further reading
For a tighter look at the signaling numbers behind this mess, start here:
