How Segwit2x Replay Protection Works

Note: This replay protection scheme has since been reverted! Please make sure you DO NOT use the protection scheme from this article for anything as you WILL NOT be protected before or after the 2x hard fork.

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’ll need to do and why they did it this way.

• Save

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.

Strong 2-way Replay Protection vs Opt-in Replay Protection

Strong 2-way replay protection means that transactions from chain X are never valid on chain Y after the hard fork and vice-versa. That is, all transactions have some marker that makes it clear what chain they were intended for.

Bitcoin Cash achieved this through marking the signatures, which every transaction requires. This made transactions on their chain invalid on Bitcoin and vice-versa. This is called “strong” replay protection because there is no way for anyone to accidentally be exposed to replay attacks. Strong replay protection is a lot like an automatically locking door that prevents the transaction from escaping chain X.

Opt-in replay protection means that transactions from chain X need to do something special to be invalid on chain Y. That is, by default, transactions are exposed to replay attacks, but if you manipulate your transaction in a certain way, the transaction won’t be valid on chain Y. Opt-in replay protection is more like a door you have to remember to lock, because otherwise the transaction may escape chain X and get into chain Y.

What did the Segwit2x Developers do?

The Segwit2x developers decided on a particular Opt-in replay protection scheme as in the pull request above. Alice, when sending coins on the Legacy chain to Bob, will have to send a small amount to 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi in order for the transaction to be invalid on the 2x chain. This address was chosen because it’s somewhat easy to see visually (starts 3Bit) and is easy enough to spend since the private key is well known.

Other opt-in replay protection schemes are being considered, such as putting a special string in OP_RETURN, making a magic nSequence value or ignoring transactions with certain version bits (this one may still happen), but this scheme was chosen, most likely, because it’s relatively easy to do, even with wallets that aren’t aware of the hard fork.

Now before you start trying to send coins to the address above, I have one caveat. This replay protection scheme only activates after the chain split. That is, it’s useless to send a small amount to the address above until November 18 or so when block 494784 gets mined. At that point, sending a transaction that includes a small amount to the address above on the Legacy chain will not be replayable on the 2x chain.

Why didn’t Segwit2x add Strong Replay Protection like BCH?

Segwit2x developers feel that they are going to be the majority chain after the hard fork. As such, they want all current wallets that exist in the Bitcoin ecosystem to be compatible with 2x and not require upgrades. That is, wallets and services won’t need to upgrade their software with opt-in replay protection. Their view is that strong replay protection would then cause a bigger split in the ecosystem than needs to be.

When BCH forked on August 1, there were almost no wallets that supported BCH specifically because their replay protection scheme was strong and because wallet developers hadn’t had a chance to code in the adjustments required to make transactions valid on BCH. It looks like Segwit2x is trying to avoid this by making transactions work with current Bitcoin wallets, merchants and services that exist.

What would it take for Core to implement Strong Replay Protection?

Unfortunately, any strong replay protection scheme requires a hard fork. Many Core developers view hard forks as requiring a lot of lead time and community consensus to do, which is a large reason for the current debate with the 2x folks. As such, a strong replay protection scheme looks unlikely going forward.

What do I need to do to split my coins after the hard fork?

You will want to move your Legacy coins first to new addresses (your Legacy wallet), but each of these transactions will have to send a small amount to 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi. If you don’t care much about privacy, you can make one giant transaction that sends all your current bitcoins to another address or set of addresses. Just make sure a small amount is also sent to 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi in the same transaction.

After that, you can send your 2x coins to different addresses and that would be your 2x wallet.

Conclusion

Hard forks bring up a lot of issues that the Bitcoin community hasn’t had to deal with before. Replay attacks is one of them. As always, be very careful when making Bitcoin transactions and keep yourself informed of hard forks like this before sending any Bitcoins anywhere.

Want to get curated Technical Bitcoin News? Sign up for the Bitcoin Tech Talk newsletter!

Are you a developer that wants to get into Bitcoin and blockchain? Sign up for Programming Blockchain Seminar in Stanford, London or Seoul!