Protecting From Replay Attacks After Recent BCH Hard Fork

Since the BCH hard fork on 11/16 and splitting into BCH ABC and BCH SV chains, PeckShield has detected huge amount of (small value) transactions replayed on ABC and SV chains. On a single day of 11/18, there were huge 1,409,055 transactions replayed!

Figure 1 shows the hourly replayed transaction numbers on BCH ABC and SV chains after the hard fork. Most of these replayed transactions are valid, but some of them may be related to intentional attacks, and we did notice reports about small scale replay attacks on BCH chains. Till now, ABC and SV chains still don’t provide replay protection mechanism. As exchanges begin to open up for BCH trades and deposits/withdraws, it becomes imperative to protect them (including investors) against possible BCH replay attacks. To this end, PeckShield would like to strongly suggest to follow the “wallet separation” principle, i.e., separating the ABC and SV tokens into different wallet addresses, and to do that, users can take one of three approaches suggested below:

Figure 1: Hourly replayed transaction numbers on hard-forked BCH ABC and BCH SV chains

1. Splitting ABC/SV addresses: Generate two different addresses, one each on ABC and SV chains, then send the ABC and SV tokens separately to these two addresses. Once the two transactions are confirmed, the tokens in the two new addresses are protected against replay attacks. Some anecdotal reports mentioned that there were some SV nodes broadcasting SV transactions to ABC chain, so we suggest starting the ABC transaction first, after it’s confirmed, then start the SV transaction.

2. Adding special input into transactions: When starting an ABC/SV transaction, add a special, small amount ABC/SV UTXO at the input side. Since this UTXO is not valid on the other chain, so this transaction is protected against replay attacks. These special UTXOs can be generated by third party services, or by users themselves.

3. Adding special OP code into transactions: There are OP codes valid only on one of the two chains. By adding them into transaction input, one can also protect the transaction against replay attacks. For example, OP code OP_CHECKDATASIG can be used for ABC transactions, while OP_MUL for SV transactions.

To further improve security, more than one of these approaches can be used at the same time. We’d suggest general users to use the second approach, since it’s simple and straightforward; Exchanges may use the first and second approaches combined (or the first and third approaches combined). Furthermore, pay special attention for their token withdraw addresses. As always, please contact PeckShield if we can be of any help.