Jeff Garzik merged in an opt-in replay protection scheme for Segwit2x yesterday. In this post, I’m going to explain how it works, what you…
What is Replay Protection, anyway?
Before explaining the exact scheme of Replay Protection, it’s important to understand what replay attacks are first. In the event of a hard fork without replay protection, transactions that spend pre-fork coins are valid on both chains. That is, if Alice sends Bob 1 coin on chain X, the same transaction will be valid on chain Y.
Alice may be intending to send Bob 1 XCoin and 1 YCoin, in which case she’d be broadcasting the transaction on both chains and have no vulnerability. However, if she wanted to send Bob only 1 XCoin and not 1 YCoin, we have a problem. Alice will, of course, broadcast the transaction on chain X, but the transaction is now public and that opens up a security vulnerability.
An attacker can take the public transaction sending 1Xcoin from Alice to Bob from chain X and replay it on chain Y. This would cause Bob to get the 1 YCoin. This is called a replay attack and causes a lot of unintended transactions.
Replay Protection is the generalized term for how you can prevent an attacker from executing replay attacks. In other words, make transactions from chain X not valid on chain Y and vice versa.
More: How Segwit2x Replay Protection Works – Bitcoin Tech Talk
