Automatic replay protection is a mechanism built into a blockchain fork that makes every transaction valid on only one of the resulting chains. Once it is in place, users do not need special tools or techniques to keep their coins safe: a transaction signed with the new software simply cannot be copied onto the other chain, and transactions from the other chain cannot be copied onto it.
It exists to stop the replay attack, the main hazard of a contested hard fork. The two best-known implementations are the SIGHASH_FORKID signature flag used by Bitcoin Cash (BCH) since its split from Bitcoin in August 2017, and the chain identifier added to Ethereum signatures by EIP-155 in November 2016. The term "automatic" distinguishes it from opt-in protection, where users must take extra steps to separate their coins.
Automatic replay protection in plain terms
Imagine two branches of a bank that split into separate companies but kept the same customer list and the same cheque books. A cheque written for one could be cashed at the other. The sensible fix is to print new cheques with the name of the company on them and tell both tellers to refuse cheques with the wrong name.
Automatic replay protection is that new printing. Every transaction carries a mark, built into the signature itself, that says which chain it belongs to. The other chain's software sees the wrong mark and refuses it. Customers do nothing differently; their software adds the mark for them.
How it works
A transaction is authorised by a digital signature over a hash of the transaction data. Replay protection changes what goes into that signed data so it differs between chains:
- A chain identifier. EIP-155 adds a chain ID into the data that is signed. Ethereum mainnet uses chain ID 1 and Ethereum Classic (ETC) uses 61, so a signature made for one fails on the other.
- A fork-specific signature flag. Bitcoin Cash requires the SIGHASH_FORKID bit to be set in each signature's hash type and uses a different signature-hash algorithm. Full nodes on Bitcoin do not accept that form, and Bitcoin Cash nodes reject signatures without it.
- A unique marker or rule. Some forks add a special output or opcode that only one side accepts, making every transaction that carries it invalid on the other chain.
Strong protection is two-way: transactions from the old chain are invalid on the new one and the reverse. One-way or opt-in schemes leave room for mistakes by users who do not know the rules.
Opt-in protection and coin splitting
Where a fork did not include automatic protection, users had to separate coins themselves. A common method was to send funds in a transaction that would only confirm on one chain, for example by combining them with a tiny amount of a coin that exists only after the fork, then moving the coins on each chain to fresh addresses. Exchanges did the same for customer funds before allowing withdrawals. These techniques work but are error-prone, which is why most developers now treat automatic protection as a basic courtesy of any deliberate chain split.
Examples
- Ethereum and Ethereum Classic. The DAO fork of July 2016 had no replay protection, and transactions were replayed between the two chains. EIP-155 was activated on Ethereum in the Spurious Dragon upgrade at block 2,675,000 in November 2016, and Ethereum Classic later adopted chain-ID signing as well. Its rules are set out in an Ethereum Improvement Proposal.
- Bitcoin Cash. The Bitcoin ABC specification published in July 2017 required SIGHASH_FORKID from the fork block on 1 August 2017, so Bitcoin and Bitcoin Cash transactions could not be replayed on each other.
- Bitcoin Gold. Bitcoin Gold (BTG) also used a fork ID in its signatures when it split from Bitcoin in October 2017.
Limits and debate
Replay protection only helps if the forking side adds it, and the decision is political as much as technical. Supporters of a fork that hopes to become "the real chain" sometimes resist protection, because protection makes the split explicit and forces every wallet, exchange and node operator to treat the new coin as separate. That argument surrounded the abandoned SegWit2x proposal in 2017.
Protection also needs wallet support. Software that does not know about a new signature format cannot sign valid transactions for the forked chain, which is why users of hardware wallets sometimes wait weeks after a fork before they can move forked coins. It does nothing about other fork risks, such as a minority chain becoming vulnerable to a 51% attack, or double spending while confirmations are unstable. A soft fork does not normally need replay protection at all, because it does not create a second chain.