On August 9, a hardware wallet manufacturer told its users not to claim the BIP-110 fork coins. Not 'wait for instructions.' Not 'exercise caution.' Don't claim. Don't transact. Don't touch. That is not a warning. That is a confession. The code whispered secrets the whitepaper buried: the proposal had no replay protection, and the hardware wallet could not protect you from Bitcoin's mainnet. It could only sign the transaction that would destroy you.
I have spent years dissecting fork claims and financial infrastructure. The pattern keeps repeating: the whitepaper promises optionality, and the code delivers exposure. BIP-110 is not a malicious proposal, at least not by evidence. It is an incomplete one. And in Bitcoin, incompleteness at the consensus layer is a security vulnerability, not a development milestone.
The Proposal and the Responsibility Vacuum
BIP-110 is a Bitcoin Improvement Proposal. It is a soft fork, meaning it was designed to be backward-compatible with existing Bitcoin rules. In theory, a soft fork is the polite way to change a protocol: old nodes still see new blocks as valid, and miners who do not upgrade are not immediately orphaned. But a soft fork still changes what a transaction means. And when a fork shares history with Bitcoin, it shares something much more dangerous: signatures.
Both chains, after a fork, contain the same addresses, the same private keys, and the same UTXOs. A transaction signed on the BIP-110 chain is not automatically invalid on Bitcoin. Without an explicit mechanism to make signatures chain-specific, the same raw transaction bytes can be accepted by both networks. That mechanism is replay protection. BIP-110 did not have it. Ledger's announcement was not a review; it was a confession, coming from a company users trust to produce the correct signature. If the hardware wallet says 'do not touch,' it is not being conservative. It is being honest about the absence of a fundamental safety feature.
Ledger is not an anonymous crypto account. It is a French company, a market leader in hardware wallets, with a commercial interest in making users feel safe. When it warns against touching a fork, it is willing to alienate a group of speculators who wanted to claim free coins. That alone tells you the risk is not hypothetical. The date is August 9; the year is not stated. It does not matter. The failure mode is timeless.
The Anatomy of a Replay Attack
Let's walk through the attack, because the abstraction hides a simple process. A user holds BTC at address X. After the fork, address X also holds the same amount of BIP-110 fork coin. The user wants to sell the fork coin. They create a transaction spending from X to an exchange deposit address. They sign it with their Ledger. The transaction is valid on the BIP-110 chain. But the signature does not include a chain ID, a unique sighash flag, or any fork-specific commitment. An observer picks the transaction from the BIP-110 mempool and rebroadcasts it verbatim to Bitcoin's mainnet. The Bitcoin nodes check the signature, the UTXO, the amount. All checks pass. The user just transferred the BTC they never intended to transfer. The attacker did not crack a private key. The attacker did not exploit an overflow. The attacker simply reused a signature. The loop didn't loop. It drained.
A replay attack does not require a custom script. It does not require the attacker to control any node. It only requires observing one transaction on the fork chain and submitting it to the Bitcoin network. In 2017, after the Bitcoin Cash split, the same class of attack was discussed extensively. The BCH community added a unique sighash flag called FORKID. That flag became the industry standard. BIP-110 lacks it. This is not a philosophical disagreement. It is a concrete missing variable.
Ledger said the device can technically sign such a transaction. That should be read as a technical fact, not comfort. A hardware wallet is an application-layer instrument. It stores keys. It signs what the user asks. It does not have the authority to enforce consensus-level replay protection. It cannot know whether a transaction built for BIP-110 will be copied to the mainnet five seconds later. It can only display a warning. That is why Ledger's advice is so blunt: there is no safe way to touch a fork coin that lacks replay protection. Technically can sign is the opposite of you should sign. It is the software equivalent of a car that starts with a broken engine. The machine will move. The movement will cost you.
In my audit work, I always ask the same question first: does this system have a unique identity per chain? For BIP-110, the answer is no. That is not an implementation bug. It is an absent security primitive. Read the function calls, not the press release. A press release says 'free coins.' The function calls say 'no chain identifier.' One of those statements is true.
The Standard That Already Exists
The industry learned this lesson in 2017. Bitcoin Cash and Bitcoin added replay protection on both sides of the split. The two chains used distinct signature hashes, so a transaction crafted for one was invalid on the other. That separation was not a courtesy. It was the minimum viable condition for a fork to exist without turning users into targets. BIP-110's design, with no replay protection, is a regression to a pre-2017 standard. A soft fork may remain compatible. It does not automatically become safe. Compatibility and replay resistance are orthogonal properties. The proposal got the first. It omitted the second.
A proper fork would modify the signature hash to include a chain identifier. That can be done by adding a value to the sighash preimage, by using a different algorithm, or by changing the transaction version. The point is to make the set of valid signatures disjoint. Without that, the two networks are not two markets; they are two gateways to the same exploit.
What the Bulls Get Right
Now the annoying part: the bulls are not entirely wrong. BIP-110 does not need to be a scam. A soft fork can be a legitimate tool for protocol evolution, and replay protection can be added afterward. The 2017 fork proved that. If the BIP-110 community adds a unique sighash before any substantial adoption, the vulnerability could be closed. Bitcoin itself remains sound. The mainnet's monetary properties are not broken by an incomplete side proposal. Users who follow Ledger's advice lose nothing. The fork coin may be worthless. The BTC remains intact. Logic does not lie, but architects often do — and the logic is the only trustworthy voice in this argument.
But 'we will fix it later' has a cost. During the window between a fork announcement and the addition of replay protection, every transaction is a live grenade. Users are asked to do nothing. That is not a free option. That is a system in quarantine. The existence of the window is itself a failure of engineering. A proposal that asks users to surrender the utility of their assets is not a proposal ready for deployment.
What This Tells Us About Infrastructure Risk
Ledger's warning is not just about BIP-110. It is a marker of how the ecosystem handles structural risk. When a protocol fails, the wallet vendor publishes a press release. The exchange waits. The depositors react. The attackers collect. I saw the same anatomy during the Terra-Luna collapse: the architecture had no internal brake, and the market treated the warning signs as noise. The forty billion dollar loss was a design flaw masked by narrative. BIP-110 is smaller in scale, but the lesson is identical. The absence of a security feature is a decision. It has consequences. Those consequences should be priced into every interaction.
The human cost is also easy to quantify in advance. Every user who misunderstood replay risk could lose the entire balance. The expected loss is not a fraction of the UTXO; it is the whole UTXO. That is the price of a missing chain identifier. It is not a market risk. It is a structural tax on technical ignorance.
Takeaway
The industry needs a standard. Any chain that shares Bitcoin's transaction history must implement replay protection in its consensus code, not in a customer-support email. Exchanges should refuse to list fork coins that lack it. Wallet vendors should refuse to sign transactions for chains that lack it. Regulators, if they ever find the courage to care, should treat missing replay protection as a disclosure failure. Not because blockchain needs permission, but because users need honest risk labels. Until then, the rational response is inactivity. Don't claim. Don't transact. Don't touch. The code whispered secrets the whitepaper buried. This time, Ledger read them aloud. Next time, don't wait for a hardware wallet to translate the truth. Read the function calls, not the press release.