Because a possible change to the bitcoin protocol this November, Segwit2x or New York Agreement, will not take place with full consensus, there is a chance that the bitcoin network will split. To prevent these two networks from becoming entangled, ‘replay protection’ must be applied.

Bitcoin Transactions

To understand what a replay attack is, you must first understand how a bitcoin transaction works.

Bitcoin can be seen as a global ledger and bitcoin transactions as bank checks, as explained in a previous article. Because the ledger is digital with Bitcoin, anyone can download the blockchain and then check it themselves. As a result, there is no need to rely on third parties.

This means that all written checks, the bitcoin transactions, are public and can be viewed by everyone.

Hard Fork

A hard fork can be seen as a change in the way the general ledger is maintained. If everyone participates in the change, this will not cause any problems. If this is not the case, a splitting of the network may occur; both have their own version with specific rules of the protocol. You then have the network with the original rules, and one with the new rules that went into effect after the change was rolled out. This also happened last August 1, the birth of Bitcoin Cash.

Until the moment of the split, the two versions were therefore one. They have the same history (after all, it was only one ledger), and now build on their own rules with accompanying ledger. Addresses with associated balances are therefore present on both blockchains until the moment of the split. This is where the importance of replay protection comes into play.

Replay Attack

If you own bitcoins on one blockchain (1) before the split, you will also have the same amount of bitcoins on the other blockchain (2), after the split. But what if you want to send bitcoins on one of the two blockchains, without endangering the bitcoins of the other blockchain?

Here too we use the aforementioned analogy of a bank draft with signature. Because all transactions must be approved based on the information contained in the transaction, the signature used and the fingerprint that is created, this information is all publicly available in the public ledger. Because the forked-off blockchain (2) can use the same rules for creating transactions, the information from the transaction on the other blockchain (1) can be used to imitate that same transaction on the forked-off blockchain (2). After all, the transaction turned out to be correct, so there is no reason to refuse it. For example, without replay protection, someone else who watches with blockchain (1) can reproduce the transaction and send it again, repeated (replay), on blockchain (2).

Such an attack can be prevented by adding a unique identifier to the check. Think of a digital watermark. When checking a transaction, it is checked whether a watermark is present. If this is the case, then this transaction is destined for blockchain (2) and is not valid on the original blockchain (1), and vice versa.

In conclusion

For anyone who does not want to send transactions, a possible split is no problem. You can wait patiently until a secure version is made available that makes these replay attacks impossible.

If it is necessary to send transactions after the possible split in November, you may be in for a nasty surprise. To date, no replay protection has been included in the Segwit2x protocol. It remains to be seen whether, and if so when, possible protection will be implemented. Until then, you should in any case be very careful, so that you do not make a mistake after the possible split.

This article was written based on articles published by Jimmy Song. Jimmy Song is a Bitcoin developer, entrepreneur and former developer for bitcoinwallet Armory. In his Bitcoin Tech Talk series, he lets the reader watch the developments surrounding the technical aspects of Bitcoin.