Replay Attack

Replay attack is the name for rebroadcasting a valid, already-signed message so it is accepted a second time somewhere it was not intended. In the blockchain context, the classic case follows a chain split: a transaction valid on one chain is maliciously rebroadcast — "replayed" — on another chain that shares the same transaction format and history. The most common trigger is a contentious hard fork, where one ledger splits into two chains identical up to the fork point. A signature created before or after the split, spending pre-fork coins, is cryptographically valid on both descendant chains, so anyone can copy a victim's transaction from one network and have the same coins move on the other.

How a fork creates the exposure

After a chain split, a user holding pre-fork coins owns the same balance on both chains, controlled by the same keys. Spending on Chain A produces transaction data that is equally valid on Chain B — same inputs, same signatures, same rules. Without protection, sending coins on one chain can silently move the mirrored coins on the other: pay for coffee on the main chain and a relayer replays the transaction to drain your forked balance to the same recipient, or an attacker uses replay to force movements you never intended. The 2016 Ethereum/Ethereum Classic split demonstrated this at scale, with exchanges losing funds to replays; Bitcoin Cash's 2017 fork learned the lesson and shipped protection from day one.

Replay protection

Defenses fall into two camps. Strong replay protection bakes a chain identifier into the signature scheme or transaction format of the new chain — Bitcoin Cash's modified signature-hashing flag is the canonical example — making its transactions structurally invalid on the legacy chain and vice versa, automatically for every user. Opt-in replay protection leaves it to users to differentiate their own transactions, typically by mixing in coins that exist on only one chain (such as freshly mined post-fork outputs) so the transaction cannot validate elsewhere. This manual technique, coin splitting, is why careful users move their balances with chain-exclusive inputs before transacting normally after any split. Strong protection is now considered basic etiquette for any serious fork; a fork that omits it is signaling either carelessness or a deliberate wish to make the split painful.

For ordinary holders, the defensive checklist at any contentious fork is short. Do nothing at first — the safest position during the chaotic early days is unspent coins, since a transaction you never sign can never be replayed. Confirm whether the new chain shipped strong replay protection before transacting on either side; if it did not, split coins deliberately following walkthroughs from wallet developers rather than improvising. And beware of haste manufactured by others: opportunists benefit from users rushing to claim or sell forked coins, which is precisely the window when replay exposure and key-exporting claim tools do their damage.

Beyond forks: replays in protocols generally

The same attack shape appears wherever signed messages can be captured and resent, which is why sound protocols bind every authenticated message to a single-use context. Bitcoin's own design is inherently replay-resistant on a single chain: the UTXO model means a confirmed spend consumes its inputs, so the same transaction can never be mined twice — one of the quiet elegances that also underpins double-spend resistance. Higher up the stack, authentication protocols reject reused challenges: LNURL-auth, for instance, issues a random single-use k1 and refuses any signature over a value it has already seen. The general principle is worth internalizing for any builder: a signature proves who authorized what — only a nonce, chain ID, or consumed input proves when and where it stops being valid.