At 2:16 am on November 16th, BCH had a hard fork at block 556767. The fork war came to an end and it was divided into two camps: BCH ABC and BCH SV.
In this hard fork, neither BCH ABC nor BCH SV has implemented "replay protection". That is to say, after this fork, theoretically, replay attacks may lead to the collapse of consensus and zero computing power of any party.
What is a "replay attack"
In traditional computer terminology, replay attacks, also known as replay attacks or replay attacks, refer to the attacker sending a data packet that has been received by the destination host to achieve the purpose of deceiving the system. Replay attacks can occur in any network communication process, and are one of the common attack methods used by hackers in the computer world. Mainly used in the authentication process.
In the field of blockchain, replay attacks (Replay Attacks) usually appear when the blockchain is hard forked, referring to "transactions on one chain are often legal on another chain."
There is an example that can simply illustrate what is a "replay attack" in the blockchain:
Little A buys beer from a brewery that cannot effectively identify the payment (here, it is impossible to determine which payment it is). When he shows the payment information of the successful payment with Alipay to the salesperson, the salesperson gives him the beer. Then Xiao A showed the last payment information to another salesman, and the salesman gave him another beer. As long as Little A repeatedly shows his payment information, he can continuously cheat beer. For the brewery, it is a replay attack and lost countless beers.
As far as this BCH hard fork is concerned, BCH has changed from one chain to two chains. When both chains are supported and continue to operate, the other forked chain has produced the asset BSV , that is, both BCH ABC and BCH SV exist. Since there is no replay protection, if you leave it alone after the fork and let it grow naturally, this will happen at this time: When you trade on the SV chain, due to the same address, algorithm and transaction format, you get If the ABC chain rebroadcasts, it may be recognized as valid by the ABC chain, so that the same transaction operation can be performed. Once the attacker takes advantage of this vulnerability and continuously deposits and withdraws (BCH SV) on the exchange, he can obtain additional BCH ABC.
This means that BCH user assets without replay protection have been exposed to risks, and more seriously, it will lead to the collapse of consensus and zero computing power.
The origin of "replay attack": Ethereum hard fork
On the evening of July 20, 2016, Ethereum had a hard fork at block 1.92 million, resulting in two chains called ETH chain and ETH Classic chain, and the above tokens were called ETH and ETC .
The addresses and private key algorithms on these two chains are the same, and the transaction formats are also exactly the same, so transactions on one of the chains are likely to be completely legal on the other chain. So if you initiate a transaction on one of the chains and rebroadcast it on another chain, it may also be confirmed.
Because there is no plan in advance, many people take advantage of this loophole to continuously deposit and withdraw ETH on the exchange to obtain additional ETC. "Replay attack" has been redefined in the blockchain world.
Affected by replay attacks, the current problems of Ethereum exist for users. Because both ETH and ETC have a good economic volume, and if the user cannot solve the possibility of his operation being replayed, he wants to sell one of the assets while keeping the other asset, or he must separate it himself, or he can only do it in It can only be realized with the assistance of the exchange.
Response: Separation before trading
Since BCH has been forked without replay protection, replay cannot be avoided. In order to avoid losses, it is necessary for exchanges and users to check the BCH ABC/ BCH SV for separation.
Let's look back at the two upgraded versions of BCH: bitcoin abc 0.18.2 and bitcoin sv 0.1.
The main modification of the Abc0.18.2 protocol version is to add two opcodes OPcode, OP_CHECKDATASIG (CDS) and OP_CHECKDATASIGVERIFY (DSV); change the ordering rules of transactions in the block from topological sorting (TTOR) to canonical sorting (CTOR).
The main modification of the SV0.1 protocol version is to restore the four early Bitcoin opcodes OPCode, OP_MUL, OP_LSHIFT, OP_RSHIFT, OP_INVERT; delete the limit of 201 opcodes for each script; increase the upper limit of the block size to 128MB.
Since both versions have updated the operation code, for users who already hold BCH, it is safer to use the new OP code for transaction operations, it should be separated before operating the account.
The easiest and most effective way to split is to buy a little UTXO of coinbase transactions from the mining pool 100 blocks after the split point, send it to your BCH wallet, and then transfer all the balance to a new address at once. You only need to do this once on a chain, and you can completely separate it.
After separating the two assets, you can use the new OPCode, and there will be no safety hazards in the new OPCode on the BCH chain due to being replayed.
Here, SECBIT Lab reminds BCH holders and exchanges that support ABC/BSV to use the new OPCode carefully in transactions before separating your/your user’s BSV to avoid losses caused by replay.
