BIP-110, RDTS, and the Bitcoin Fork Drama: What Happened and What It Means for Nodes
Bitcoin never really has boring days for long.
Over the past weeks, BIP-110 and RDTS sparked one of the more unusual Bitcoin governance and consensus debates in recent memory. What started as a proposal to limit arbitrary data storage on Bitcoin turned into a failed activation attempt, a minority chain split, and eventually a separate proof-of-work fork experiment.
For anyone following Bitcoin only casually, this all looked chaotic. For node operators, however, it raised a very important question: what actually happens when part of the network tries to go one way while the economic majority keeps going straight ahead?
Let’s break it down.
What is BIP-110?
BIP-110, also known as Reduced Data Temporary Softfork (RDTS), was proposed as a way to limit the amount of non-financial data stored in Bitcoin transactions.
The core idea behind it was simple:
- reduce the ability to embed arbitrary data into Bitcoin transactions
- discourage spam-like or inscription-heavy use of blockspace
- make Bitcoin more focused on monetary use cases
- reduce some of the long-term burden on nodes and the chain itself
Supporters argued that Bitcoin should prioritize money and payments, not become a general-purpose data host. In their view, the network was drifting too far toward storing non-monetary content.
Critics, on the other hand, argued that Bitcoin’s blockspace should remain neutral. If a transaction is valid under the rules and the sender pays the fee, then miners and nodes should not be making policy judgments about which valid uses of blockspace are “good” or “bad.”
So from the beginning, BIP-110 was not just about data. It was really about what Bitcoin is for and who gets to decide.
Why did it become so controversial?
Because BIP-110 was not merely a theoretical discussion.
It included an activation path that depended on miner signaling and, later, a more aggressive mandatory-signaling phase. In practice, that meant the proposal could potentially create a split between nodes enforcing the BIP-110 rules and nodes continuing to follow the standard Bitcoin Core rules.
That possibility immediately changed the debate.
At that point, the question was no longer just:
“Should Bitcoin limit embedded data?”
It became:
“What happens if different parts of the network disagree strongly enough to follow different chains?”
And that is where things got spicy.
What actually happened?
In short: BIP-110 failed to gain anywhere close to the needed support on the dominant Bitcoin chain.
Miner signaling remained very low. When the critical phase arrived, the overwhelming majority of hashpower stayed on the normal Bitcoin chain. A small minority chain enforcing BIP-110 did emerge, but it quickly stalled because it inherited Bitcoin’s normal difficulty while only having a tiny fraction of the total hashpower.
That meant the chain technically existed, but it was barely producing blocks. Instead of becoming a viable alternative Bitcoin chain, it mostly demonstrated how hard it is to challenge the economic and mining majority.
In other words, the fork existed, but it never became a serious competitor to Bitcoin’s main chain.
Why this matters for nodes
This is where the story becomes especially interesting for node operators.
A full node does not care about social media arguments, memes, or who shouted the loudest on Nostr. It follows the rules of the software it runs.
That means when a controversial change appears, nodes matter a lot.
1. Full nodes enforce rules
A node operator decides which software and which rules to run.
If different software implementations enforce different consensus rules, the network can split into separate realities:
- one set of nodes sees Chain A as valid
- another set sees Chain B as valid
That is exactly why chain splits are not only “miner drama.” Nodes are part of the story too.
2. Economic nodes matter more than loud opinions
One of the biggest lessons from the BIP-110 episode is that not all nodes are equal in economic influence.
A hobby node, a routing node, an exchange node, and a custody provider node all count as nodes, but they do not carry the same economic weight.
What became very clear is that economic consensus still matters massively. If major exchanges, wallets, businesses, and users do not move with a fork, the fork may survive technically, but it struggles to become relevant economically.
3. Running a node means understanding chain risk
Many people think running a node is just about privacy, sovereignty, and verification. That is true, but episodes like this show something else:
Running a node also means understanding which chain your software will follow if consensus breaks down.
Most of the time, that question feels theoretical.
Then one day, it isn’t.
What about Lightning nodes?
This was one of the biggest concerns during the entire BIP-110 debate.
The good news is that BIP-110 did not directly invalidate normal Lightning channel structures. Standard channel transactions, commitment transactions, and closes were not suddenly broken just because BIP-110 existed.
The real concern came from a different direction:
Chain divergence risk
A Lightning node depends on its Bitcoin backend.
If two chains exist and different participants observe different ones, then problems can appear around:
- force closes
- commitment transaction monitoring
- justice transactions
- replay behavior
- general certainty about where a channel state is being enforced
That does not mean Lightning suddenly explodes the moment a fork exists. But it does mean that a meaningful chain split can create extra operational risk, especially if two chains remain economically relevant at the same time.
In the BIP-110 case, that danger stayed limited because the minority chain never became a truly competitive rival to the main chain.
Still, the episode was a valuable reminder: Lightning is fast and clever, but it is still anchored to Bitcoin consensus underneath.
No solid base layer, no cozy Lightning magic.
Replay risk and fork complexity
Another important issue around the fork environment was replay risk.
When a chain splits without clean replay protection, a transaction valid on one chain may also be valid on the other chain. That creates confusion and risk if users try to move coins on both sides without carefully splitting them first.
For ordinary users, that is annoying.
For operators, services, and anyone handling larger flows of funds, that becomes a serious operational concern.
This is one reason why many node and infrastructure operators tend to be conservative during controversial forks. Even when a new chain looks “interesting,” the actual risks of interacting with it can be far messier than the online debate suggests.
The strange afterlife of BIP-110
Although the original BIP-110 path effectively failed, the story did not end there.
The movement around it evolved into follow-up fork experiments, including alternative proof-of-work and separate chain efforts. That shifted the situation from “a contested Bitcoin softfork attempt” toward “an independent fork ecosystem.”
And that is a major distinction.
Trying to change Bitcoin from within is one thing.
Launching a separate chain with its own rules, mining assumptions, or economic model is something else entirely.
At that point, the debate is no longer “Will Bitcoin adopt this?”
It becomes:
“Can this new chain attract enough miners, users, liquidity, and infrastructure to matter?”
That is a much tougher challenge.
The big lessons from the BIP-110 saga
Here is what I think this episode taught us most clearly:
Bitcoin governance is messy but resilient
There is no central authority that can simply declare victory. That can be frustrating, but it is also a strength.
Economic consensus beats narrative momentum
A lot of noise does not automatically translate into adoption. Support from the broader ecosystem matters.
Nodes are not passive spectators
Node operators help determine which rules are enforced and which chain is considered valid.
Lightning depends on base-layer clarity
Lightning can handle a lot, but it still needs a reliable Bitcoin chain underneath.
Forks are easy to announce and hard to sustain
It is one thing to launch a fork.
It is another thing to keep it alive, secure, liquid, and relevant.
Final thoughts
BIP-110 began as a debate over whether Bitcoin should reduce arbitrary data usage. It turned into a live demonstration of how Bitcoin handles contested rule changes in the real world.
The result was not a successful takeover of the main chain.
Instead, it became a lesson in the power of economic consensus, the importance of nodes, and the difficulty of maintaining a minority fork.
For node operators, this was a reminder that the software you run matters.
For Lightning operators, it was a reminder that every channel ultimately lives on top of Bitcoin consensus.
And for the broader community, it was yet another sign that Bitcoin governance is messy, slow, and occasionally dramatic — but also remarkably resistant to sudden capture.
Or, to put it a little less academically:
Bitcoin looked at the fork in the tracks, adjusted its conductor hat, and kept rolling down the main line.
What do you think?
Was BIP-110 a reasonable attempt to protect Bitcoin’s monetary focus, or was it a step too far in trying to police valid blockspace usage?
I’d be curious to hear how other node operators, Lightning users, and Bitcoiners see it.
Images and screenshots are from me or AI generated