A major issue highlighted on the world wide web today, which is termed extremely important whenever we speak about ‘Bitcoin Forks‘ is the likelihood of ‘Replay Attacks‘. When Bitcoin forked on August 1, 2017 and ‘Bitcoin Cash’ was born, replay protection was a hot topic. When Bitcoin forked to ‘Bitcoin Gold‘ on October 25, the hype around replay protection grew as the core will be released only on November 1. On November 16, when the fork takes place, the community will stand divided, staunchly on the replay protection aspect, as this new forked blockchain core is not expected to have replay protection.
Let’s understand why replay protection is required, and before that, the concept of how two bitcoins come into existence in the first place. This is important to understand before we discuss transaction replay. Whenever Bitcoin forks, the Bitcoin chain upto the predetermined block level is split into two. From the next block onwards, two parallel but entirely different blockchains come alive. The reason we get two bitcoins is because the same address containing the bitcoin from the original chain can now be spent in both the blockchains. For example, let’s say that bitcoin cash was forked after block number 478558; so if 1 bitcoin were held in an address that was part of block number 478558, or any block before that, it can be considered that your bitcoin can be spent twice, once on the original bitcoin blockchain, and then again on bitcoin cash blockchain.
Now, if a bitcoin is spent on the main Bitcoin blockchain, we still are left with bitcoin cash, and vice versa. However, if, at the time a wallet was used to spend a bitcoin on one of the blockchains, and someone uses the same transaction on the other blockchain, the other coin is also spent. Hence, while you intended to spend (or transfer) one of the bitcoins, you have transferred the other bitcoin too.
Since such incidents can easily happen, as some users are not careful, or are not technically aware enough to ensure that either they or a program does not spend the transaction twice. Thus when a blockchain is forked, we expect that one of the blockchains will implement a protocol (or embed a software) which will not allow the transaction created by one blockchain to be replayed over the other blockchain. One of the methods this can be implemented is by changing the transaction or the signature format through a new hashing mechanism. We are aware that hashing a variable is a one way street, while anyone can confirm that the hashed value is correct, you cannot reconstruct the value before hashing by calculating backwards from the hash.
So the threat of Replay is real where no replay protection is built in. But do consider the following:
1. Bitcoin definitely cannot be spent without your knowledge if you have your private key. So, replaying is a risk only when you try spending any one of the bitcoins out of the fork. If you just sit on both of your bitcoins with your private keys in your secure custody, then there is no replay risk as there is no transaction in the first place.
2. Even if the bitcoin is replayed, it can still be sent to the same address only where you have sent the other bitcoin. Hence, if you send your bitcoin to an address which is owned by your friend on the main blockchain, then anyone who replays that transaction on the other blockchain ends up sending your bitcoin to this friend of yours. Just that your friend now owns both your bitcoins. However, if you accidentally replay or someone else replays your transaction, this still does not go to anyone else except the friend of yours. If you replay it to a merchant, or you replay it to an exchange, they should always be able to return it back to you if they don’t intend to keep it.
3. If you hold both bitcoins and the bitcoins out of fork(s), you can send them to new addresses you own. The probability of creating the same address for both blockchains even as they have the same address format is similar to two users creating the same address, which is infinitesimally small.
So while there is a distinct risk of Replay, and we welcome a Replay Protection, we still don’t believe it is a dealbreaker for a user who is careful and/or has access to good technical support/advice.
You may write to the author at email@example.com for further queries