A few days ago, I watched a friend meticulously prepare to claim a hypothetical Bitcoin fork. He had split his UTXOs, dusted his addresses, and was about to sign a transaction on a chain that didn’t exist yet. When I asked him why, he said, “Because it’s a new BIP, and Ledger said it’s possible.” That sentence is a perfect storm of misunderstanding—and exactly the kind of narrative that can lead to a very expensive lesson in cryptography.
This is not a story about a new protocol. It’s a story about the ghost of a number—BIP-110—and how a hardware wallet’s responsible warning has inadvertently become a beacon for a fork that may never have economic legs, but could still steal your Bitcoin.
The Context: A Number That Already Exists
Let’s clear the air. BIP-110, in the historical record of Bitcoin, is CHECKSEQUENCEVERIFY (CSV). It was activated in 2016 as part of a soft fork bundle that included BIP-68 (relative lock-time) and BIP-112 (CHECKSEQUENCEVERIFY). It’s not a new proposal. It’s not a draft sitting on a GitHub repository waiting for consensus. It’s live code that has been running on the main chain for almost a decade.
So when a group of miners or community members threaten to “run a node without BIP-110” or “create a chain that reverts the CSV change,” they are not proposing a new standard. They are proposing a rollback fork—a backwards step that removes a feature already in use. This is fundamentally different from a BIP-driven upgrade. It’s a political act disguised as a technical one.
Ledger’s warning, which I reviewed in detail, correctly states that their devices can technically sign transactions on such a fork. But the real story is not about capability—it’s about the absence of replay protection and the naming confusion that could lead users to believe they are participating in a legitimate upgrade.
The Core: Replay Attacks Are the Silent Killer
Based on my experience auditing wallet implementations and analyzing fork dynamics since 2017, I can tell you that the replay attack risk is not hypothetical—it’s a deterministic consequence of shared history. When two chains share the same genesis block and the same transaction format, a signature valid on one chain is valid on the other. The only defense is a protocol-level divergence, such as BCH’s SIGHASH_FORKID or a mandatory OP_RETURN chain identifier.
This fork, as described, has no such protection. That means:
- If you sign a transaction to send your BTC on the main chain, an attacker can rebroadcast that same transaction on the fork chain, transferring your fork coins out of your control.
- Conversely, if you sign a transaction on the fork chain (e.g., to claim or trade the fork token), the same signature can be used to move your main chain BTC if the transaction format is identical.
The risk is bidirectional. And because the fork chain is likely to have low hashrate and low liquidity, the window for such attacks is wide open.
Let’s look at the technical maturity. The fork’s activation mechanism is unclear: is it block height, timestamp, or miner signaling? The node implementation is unknown. There is no testnet, no audit, no public repository with a clear commit history. In contrast, every major Bitcoin soft fork in the last decade has gone through a rigorous BIP process, community review, and a signaling period. This “BIP-110” fork has none of that.
Worse, the naming itself is a trap. A user who searches for “BIP-110” will find the CSV proposal, assume it’s a legitimate upgrade, and treat the fork as a credible event. But the CSV proposal is already active. The fork is actually about removing CSV, not adding it. This misdirection is dangerous.
The Contrarian Angle: The Fork Might Be a Distraction, Not a Threat
Here’s where I disagree with the alarmist interpretation. The real risk is not that the fork will succeed and drain your BTC—it’s that the fork will fail, and the attempt to claim it will drain your BTC due to replay.
Let’s be pragmatic. The market has moved on from Bitcoin forks. The narrative of “free money” from airdropped fork coins has been dead since 2018, when BSV, BTG, and others collapsed in value and liquidity. The only forks that survive are those with strong community consensus and economic backing—like Bitcoin Cash, which still has a market cap of billions. This unnamed fork has no such backing.
From an economic perspective, the fork token’s value capture is near zero. Without a DeFi ecosystem, without exchange support (most exchanges will refuse to list a fork without replay protection), and without a clear use case, the token exists only as a speculative vehicle. But the cost of claiming it is potentially losing your entire BTC balance. The asymmetry is extreme.
The most rational economic decision is to not claim the fork at all. Yet, the human tendency to chase “free” value, combined with the confusion around BIP-110, will lead many to try. That’s where the real damage occurs.
The Takeaway: We Do Not Follow Trends; We Architect Ecosystems
This event is a stress test for the Bitcoin ecosystem’s security hygiene. Ledger did the right thing by issuing a warning. But the deeper lesson is about information integrity in open source communities.
The code is open, but the vision is ours to build. A fork that misuses a historical BIP number, lacks replay protection, and provides no public technical specification is not a credible ecosystem—it’s a trap. Volatility is the tax we pay for freedom, but we should not pay it with our principal.
If you hold Bitcoin in a hardware wallet, do not sign any transaction from an unknown fork. Do not split your coins. Do not even look at the fork’s block explorer. The safest action is to wait until the fork either dies or implements proper replay protection—and even then, the economic value is likely to be negligible.
Trust is not given; it is compiled, line by line. This fork has not earned that trust. Let it remain a footnote in the history of Bitcoin’s resilience, not a chapter in your personal loss story.
