BIP-110 Has No Replay Protection: Ledger Just Confirmed That Claiming Is a Loss Function

On August 9, Ledger, the hardware wallet maker, issued an advisory that read like a bomb-disposal memo. Do not claim the BIP-110 fork coin. Do not move it. Do not interact with it. The reason is not market timing. The reason is a missing consensus primitive called replay protection. BIP-110, a Bitcoin soft fork proposal with roots in the pre-2017 chain-split era, did not include it. I do not read the whitepaper; I read the bytecode. The signature format behind BIP-110 is valid on both the fork chain and the Bitcoin mainnet. That is not a design footnote. It is an exploit architecture. To be precise, BIP-110 is not an altcoin project. It is a consensus-level proposal that inherits Bitcoin's UTXO set. If it becomes a live chain, every Bitcoin balance at the fork block is mirrored onto a new coin. The fork coin costs nothing to obtain; it appears as a duplicate balance. That sounds like an airdrop. In engineering terms, it is shared state without a chain boundary. Ledger's advisory is therefore not a policy statement. It is a technical disclosure. The company explicitly said its device is technically able to sign transactions on the BIP-110 chain. That single sentence contains the entire problem. A signature is valid in both worlds. The wallet is not broken. The protocol is. Replay attacks are not hacks in the usual sense. They are validity collisions. After a split, both chains share the same pre-fork ledger. A transaction signed on the fork chain references the same previous transaction hashes that exist on Bitcoin. Without a chain ID or a modified sighash commitment, the signature does not contain any information binding it to one network. An attacker can copy the transaction and broadcast it on Bitcoin. The Bitcoin nodes validate it as a normal transaction. The coins move. The user can be sitting in a perfectly secure hardware environment and still lose control of the mirrored BTC balance. Ledger's warning is not a protection mechanism. It is a confession that protection does not exist at the wallet layer. The 2017 Bitcoin Cash split showed what the industry should have learned. Both sides modified their signatures or added constraints to prevent transaction replay. The result was an imperfect but mostly functional boundary. That standard is now the baseline for any serious fork. BIP-110 does not reach that baseline. Based on my audit experience, I treat a missing replay-protection flag as a terminal condition for any fork proposal. It is not a cosmetic issue that can be fixed with a community vote. It has to be fixed in consensus code, and until it is fixed, every transaction on that chain is a liability. The quantitative side is even more brutal. Let V be the value of a user's BTC balance that is exposed by a single signed transaction. Let v be the value of the fork coin that the claim is designed to capture. The cost of claiming is not zero; it is V times the probability of replay. Since any transaction with economic value will be visible to arbitrage bots, P(replay) is close to 1 for any fork coin that has exchange value. The expected value of claiming is v minus V times P(replay). For any realistic fork coin, V dominates. The only rational choice is non-participation. This is why the fork coin's tokenomics are unimportant. The actual distribution event is a risk transfer from the user to the attacker. Here is the part most market commentary misses. The fork coin is not free. It is a contingent liability. A user who follows the standard claiming manual, receive coin, move coin, sell coin, will broadcast multiple transactions. Each one is a replay vector. Each one can be copied onto Bitcoin. The more actively the fork coin is traded, the more attacks become available. There is no way for an exchange to protect against this without implementing replay protection inside its own backend, and if the protocol lacks replay protection, an exchange's wrapper is only a temporary patch. The secure design has to live in the consensus layer. In my own audits, I have seen this exact structure before. A team builds a chain, writes a polished roadmap, and assumes users will behave the way the team wants them to behave. But the chain is a state machine, not a trust agreement. It does not care whether a user understood the warning. If the transaction is valid, it executes. That is why I do not read announcements. I derive the security boundary from the transaction format, and I tell the operator to add a unique sighash prefix before they ask anyone to sign. The market context makes this worse. In a sideways market, capital preservation is the dominant variable. Institutional investors are not looking for a speculative fork coin; they are looking for a clean risk surface. A proposal that introduces replay risk adds a tail event to the base asset itself. That is precisely the kind of structural weakness that should be priced as a discount, not an opportunity. Ledger's announcement will push BTC holders into defensive mode. They will stop moving coins. They will wait for the split to die or for a corrected proposal. That behavior is rational. One more point should concern the exchange layer. If a fork coin without replay protection is listed, the exchange must be extremely careful not to accept deposits from addresses that have also been submitted as transactions on the other chain. In practice, this means the exchange will need to implement its own replay filters. That is possible, but it is also fragile. A listing does not cure the protocol defect; it displaces it. The exchange's internal bookkeeping becomes the security layer instead of the consensus rules. That is not an acceptable design. Now the contrarian part. The bulls are not entirely wrong. BIP-110 is still a proposal. It can be amended. Replay protection can be added before activation. If that happens, the fork coin becomes safer to claim, and Ledger's warning may look over-cautious. I will not call that scenario impossible. Bitcoin's BIP framework has absorbed technical criticism before, and a competent developer can modify the sighash commitment. But saying a proposal can be corrected is not the same as saying it is safe today. A corrected BIP-110 would be a different transaction format. It would require re-signing, re-auditing, and a new deployment timeline. The current code state remains broken. There is also a defensible point in Ledger's favor. The company sells hardware wallets. It could easily stay silent and let users discover the problem after their BTC disappears. Instead, it issued a warning that tells users not to touch an asset. That is not a marketing move; it is a risk-management move. The warning does not increase Ledger's revenue today. It reduces the probability that a user loses the base asset and blames the wallet vendor tomorrow. In a market full of anonymous token creators, this is the rare moment when a for-profit infrastructure firm is acting as an honest gatekeeper. The more uncomfortable question is why the protocol layer did not solve this before Ledger had to speak. Replay protection is not a novel concept. It has been a mandatory feature of serious forks since 2017. A proposal that lacks it should not reach the point where a wallet vendor has to issue a public safety notice. That failure is a governance failure. It means the people proposing the split did not consider the user's worst-case behavior, or they did not consider it enough. Either way, the user is the one paying for the omission. No replay protection, no fork. This should be the standard, and it should be enforced before a proposal is activated. Not by exchanges, not by wallet companies, but by the consensus rules themselves. The next fork proposal must be judged by one test: does the transaction format commit to exactly one chain? If not, it should be rejected at the protocol layer. The code will not care about conviction. The chain will not reward bravery. A transaction is not a promise; it is a state transition. Before you sign anything on a split chain, ask the only question that matters. Is this signature valid in exactly one world? If the answer is no, the rational position is the void. Do not sign. Do not claim. Let the chain keep what it has already recorded.