Transaction Replay and Replay Protection With Hard Forks Explained

Understanding Replay and Crypto

When a coin does a hard fork, two identical blockchains exist until changes to one of the chains is made. To avoid transaction replays (transactions made on one chain being broadcast on the other), at least one chain must implement replay protection (developers of one chain must change the format of transactions to make them unique).^[1][2]

If replay protection is not added, then any transaction made on one chain can be “replayed” (re-broadcasted) on the other. After-all, the only difference between the two chains (if nothing is changed by developers) is that there are two copies of the chain and miners are committing transactions to each chain separately. Addresses are the same, keys are the same, the format of transactions are the same, etc… and this leaves an opening for exploits.

When a malicious actor exploits a chain with a lack of “replay protection,” for example by broadcasting a transaction meant for one chain on the other chain, it is called a “replay attack.”

Replay attacks can result in lost funds due to both the original coin and the forked coin being sent to the same address.

In instances where there is a contentious fork (like BCH and BSV) or a hastily implemented fork (like ETH and ETC), replay protection may not be added right away and the user will have to protect themselves.

A user can, in theory, protect themselves against replay attacks by “coin splitting.” However, there is no surefire perfect coin splitting solution I have found that can be recommended with 100% confidence.

Thus, an inexperienced user may want to wait until replay protection is confirmed to send coins after a fork occurs to limit the number things that can go wrong (this is especially important if you already have claimed your forked coins but did not move your original balance after the snapshot block before the MainNet went live).

With all that covered, there are a ton of technical details and specifics I didn’t cover above.

For a complete understanding of everything replay you really have to dig into how blockchains work and work to understand some technical aspects of the code. Said plainly, that is out of the scope of the site.

For the average user, the best protection against replay attacks is 1. using a custodial service that will honor a fork and then not moving it to another wallet until after replay protection is confirmed, or 2. being in control of your private keys, moving your funds after the snapshot but before the new MainNet goes live, claiming the fork, and then waiting to move funds on either chain until after replay protection is confirmed, or 3. being in control of your private keys and simply doing nothing at all until replay protection is confirmed.

The bottom line here is this, you can’t run into replay problems unless you share you broadcast a transaction, so if you don’t broadcast a transaction (send or spend), you won’t be jeopardizing your coins in a fork that lacks replay protection.

TIP: Replay protection isn’t the only thing to safeguard against with forks. To claim a fork you have to import your keys into the forked coin’s wallet. To do that safely you have to move your original balance… if you are doing that after the forked coin’s MainNet is live, you have a catch-22, because you have to send your coins to a new address!

TIP: Replay attacks can also happen if one uses the same keys on a TestNet as they do on a MainNet. In general, a replay attack is taking a transaction on one blockchain, and maliciously or fraudulently repeating it on another blockchain.^[3] It doesn’t have to have anything to do with a hard fork, although hard forks and replay protection is the topic of the page.

Hardfork Without Replay Protection Explained | Bitcoin Cash (11-15-18).

1. What is transaction replay and replay protection?. Bitcoin.StackExchange.com.
2. How to Prevent Replay Attack by Splitting Coins in the Event of a Bitcoin Chain Split. Freedomnode.com.
3. What is a replay attack?. Ethereum.StackExchange.com.