Cross-Chain Replay Attacks

Chain-hopping Contract Inputs

The biggest problem with cross-chain attacks involve smart contracts.

Imagine a non-trivial multiplayer card game, being played on chain A. Because every action on chain A is also a legal action on chain B, the same sequence can be trivially instantiated and replayed on chain B. True, the actions from each player can only be played in sequence. One cannot mix and match and reorder transactions issued by a single player; nor can one make up actions for players that did not take place. But in turn-based games where each player submits inputs, one can replay those inputs in order, changing one's own reaction to them, on chain B.

Since the outcome of a game will depend on the sequence of actions taken by players, a player with the benefit of hindsight from chain A might be able to devise an interleaving of transactions from chain A that allow that player to decidedly win on chain B.

Is this possible for every game? No. But it may be trivial to win at a game such as tic-tac-toe. And a game such as multiplayer poker may be vulnerable if it is written in a way that admits omission of a player's inputs.

Effects of the Attack

From least bad to worse:

Chain-hopping will certainly make it difficult, if not impossible, for participants to later switch from chain A to chain B. The coins you earned on chain A may not be there on chain B. This is, actually, to be expected; there is no reason why the transaction history from chain A should be replayable in its entirety on chain B -- transactions may well be dependent on block number. So, this problem is not as dire as it may seem, because it does not modify the implicit contract.

Undeserving parties might be able to drain value from one of the chains. Cross-chain replay attacker can selectively replay events to win coins and cash out of chain B, creating a pump that discovers transactions on chain A and extracts value out of chain B. This would work until the replayable transactions, directing pre-fork ether, are exhausted. Coalitions might be able to drain services that hold large pre-fork coins.

The Real Effects

Cross-chain replay attacks will force people to either defend themselves against such attacks (as outlined in the next paragraph), or to select one of the chains and stick with that selection. If you don't employ any defenses, you should interact with smart contracts only on the chain where you think the economic majority will be. The fact that the minority chain can be abused via chain hopping provides an incentive to quickly converge to a single unified chain. This is not a bad thing -- it's known as a Schelling point and we should all converge to it.

And the easiest defense against replay attacks is to perform a block hash dependent fork that will send your coins to different wallets on the two chains. Tjaden Hess, who has guest-blogged here before on the dangers of the soft fork, has some code that will split the coins into different wallet addresses on the two chains, stemming subsequent replays (note that the scheme is probabilistic, so please call with sufficiently many arguments and ensure that the outcomes are different on the two chains).

What if I Change My Mind?

Long answer: It's completely fine to change your mind about which side of the fork you want to adopt, as long as you do not engage in activities on one fork that are vulnerable to cross-chain attacks. If you employ the defense strategy above, you'll reserve the option to switch to the other chain later on, though, when you switch, you may have to forego some or all of the transactions that took place on the chain you are abandoning.

Short answer: Don't. Not everything is undoable in life, and undoing The DAO hack is hard enough without having to also provide infinitely many options for all time to all users. And there's great value in making the fork choice sticky. Let's converge quickly to the outcome where we are all on one major winning chain.