Anatomy of a Replay Attack
Replay attacks can occur when a single transaction is considered to be valid on both chains. To understand fully how this happens, let’s take a step back.
Nodes on a blockchain network learn of new transactions by connecting to a number of other nodes on the same network. All nodes both listen for new transactions from their peers and tell their peers of new transactions they hear about. When a node learns of a new transaction it performs some mathematical computation to ensure that the transaction is valid. If it deems the transaction to be valid, then it propagates the transactions to its peers and places the transaction into a pool of transactions to be considered for the next block, called the mempool.
Transaction propagation gets messy when nodes from both sides of a hard fork are running different versions of software, but still communicating with each other. When BSV forked from BCH, BSV nodes were still able to connect to BCH nodes, and vice versa. As a result, any transaction valid on the BCH chain was shared with BSV nodes, and any transaction valid on the BSV chain was shared with BCH nodes.
Without replay protection of any kind, BSV and BCH nodes run the same process to determine if new transactions are valid and ought to be added to their mempool. As a result, both BSV and BCH nodes are connecting to each other, propagating transactions from both chains, and adding transactions from both chains to their respective mempools to potentially be included in blocks on both chains.
Alice has 1 BCH she wants to send Bob. Alice signs a transaction sending Bob 1 BCH. Her transaction is broadcast to a BCH node and quickly propagated to all BCH nodes. Due to the fact that BCH and BSV nodes are still able to connect to each other, her transaction is also propagated to at least one BSV node, eventually being propagated to the entire BSV network. Eventually, the transaction is included in a valid block in each of the two chains, meaning that Alice sent to Bob not only 1 BCH, but also 1 BSV.
Replay attacks are especially dangerous for exchange operators. Without replay protection, a savvy attacker could use replay attacks to drain funds from an exchange’s hot wallet. The attack works like this:
After the fork, Alice creates an exchange account and buys BCH. She then sends the BCH from the exchange to another address off exchange. If the exchange is not protecting sends against replay, Alice’s “send” not only sends BCH to the external address, but also sends BSV to the same external address, although Alice paid only for the BCH.