Beware of replay attacks! PoC2 + Hard Fork Upgrade Risk Tips

What is a replay attack?

Replay Attack is a common and ancient attack method in computer networks. In the blockchain, replay attacks specifically refer to hard forks, in which an attacker takes transactions on one chain and “replays (replays)” on another chain to gain improper benefits. Means of attack. After all, this is a technical concept. Xiaobai may not be easy to understand. In order to explain clearly, we use a real case to explain how a replay attack is implemented. This real case comes from the well-known Ethereum The DAO fork event .

The DAO is a crowdfunding project launched on Ethereum, which runs on smart contracts. Because of some sort of loopholes in the smart contract, the hacker transferred away tens of millions of dollars of Ethereum managed in the contract. In order to recover the losses, most of the community led by Vitalik supported the fork to achieve transaction rollback (which invalidated the hacking attack), so a new chain was launched through a hard fork. However, some other community opinions believe that it should not be rolled back and still maintain the original blockchain. This caused Ethereum to split into two different blockchains: the new chain (Ethereum, ETH) and the original chain (Ethereum Classic, ETC).

So how does a replay attack work? We assume that Xiaoming holds 500 ETH before the fork. After the fork, Xiaoming's address (tentatively called A address) holds 500 ETH and 500 ETC at the same time, because this A address exists on both chains. As Xiao Ming is a staunch supporter of the fork, Xiao Ming is only optimistic about the future development of ETH and feels that ETC will definitely return to zero. At this time, Xiaogang found Xiaoming and proposed to buy ETC in Xiaoming's hands at a low price . Xiaoming transferred all 500 ETCs in his hand to Xiaogang's address (tentatively called B address).

It sounds right, but what Xiaoming didn't expect is that Xiaogang sent this ETC transfer transaction to the ETH network . Because ETH and ETC are fork products, the transaction structure and cryptography system of both are consistent. Transactions on the ETC chain can also be identified on the ETH chain, so this transaction will be verified on the chain. The end result is that the A address on the ETH chain also transferred 500 ETH to the B address . Xiaogang pretends to buy ETC at a low price, but successfully defrauds all of Xiaoming's ETH. Xiaoming naturally loses money!

• Xiaomi establishes industry-finance big data company to continue expanding blockchain and other businesses
• HNA Group encountered the most severe moment in 27 years, blockchain could not save HNA
• With the reduction of Bitcoin production and the surge of computing power, the "year of mining disaster" of the 16nm mining machine is bound to come?

How to prevent replay attacks?

We can see that Xiaogang asked Xiaoming about the acquisition of ETC, and there was no problem in it; Xiaoming transferred ETC in his hand to Xiaogang, and there was no problem. The real problem is that because the two chains of ETH and ETC use exactly the same transaction structure and cryptography, the transactions that are valid on ETC are also valid on ETH. This gives attackers a chance. An attacker can "replay" an effective transaction on the ETC to the ETH chain and still form an effective transaction. However, this replayed transaction is not the true will of the trader himself, so it is easy Exploited by an attacker resulting in asset loss.

Everyone may have a question: Isn't it possible that all transactions made between the forked chains, such as between ETH and ETC, and between BTC and BCH, can be "replayed"? In fact, the implementation of replay attacks requires a series of severe conditions. Only within a period of time after the fork is completed , the two chains can maintain the state of sharing almost the same data on the chain (because the historical data before the fork height are exactly the same), and the replay attack is most likely to occur ; Once running for a period of time, there are new data inputs on the two chains, and the feasibility of replaying transactions from one chain to the other is greatly diminished.

From the perspective of preventing replay attacks, we can summarize some rules. First of all, everyone must realize that replay transactions are not a bug in themselves and cannot steal your assets directly. Replay attacks must be carried out in conjunction with or combined with other malicious behaviors . It is as if in the Xiaoming ETC case we mentioned earlier, there must be a role like Xiaogang who has carried out the fraudulent purchase of ETC at a deliberately low price and ETH in fact. If you remain vigilant for a period of time after the fork and always realize that your transactions on the new chain may be replayed to the original chain (or vice versa), you can eliminate most of the fraud related to it.

We introduce two specific precautions. The first is to purchase a very small amount of "fresh coins" into your address after the fork . The so-called "fresh coins" refer to those coins that are mined after the fork height. These coins do not exist on another chain, so when the input of the transaction refers to them, this transaction cannot be used by another one. Chain verification. The second is to reconcile the coins in all your addresses to a newly generated address after the fork . This is the so-called "cage exchange for birds", which can reduce the feasibility of attackers replaying transactions on another chain; if you combine the two methods in order, you can basically avoid the possibility of replay attacks.

Lava team's risk tips and related suggestions during the fork

First of all, we specially remind that this PoC2 + upgrade uses a hard fork method, which may form two chains, namely a "new chain" after the upgrade agreement and an "original chain" that still runs the old protocol. This is due to the characteristics of the blockchain. As long as the original protocol has the power to maintain it, the original chain can also be retained (or, if it is not maintained, it will gradually die out). The Lava technical team stated that after the upgrade is complete, we will not perform any maintenance and development work on the original chain running the old protocol.

Therefore, we first recommend community users to update all full node or wallet software versions in your hands before the fork . You can go to the official website ( https://www.lavatech.org/en/ ) to download the latest version of the software and check if your software version is on the upgrade guide page ( https://www.lavatech.org/en/poc2Upgrade ) For the latest. If you do n’t update in time and still use the old version of the wallet, it may cause confusion and misuse.

Secondly, we recommend that you be cautious to carry out transfer activities with third parties in the short term after the fork if you are not sure . After the fork, someone may propose to acquire your LV assets in the original chain (or the new chain), and you need to be particularly aware of the risk of the transaction being replayed.

Lava's technical team may plan to transfer a small amount of "fresh LV" to all addresses with a large LV balance after the fork is completed to reduce the feasibility of an attacker implementing a replay attack. We recommend that all users who hold large amounts of LV assets, after receiving "fresh LV" transfers, group their held LVs to a new address . (The specific method is to transfer all LV balances in your wallet to another new address under your wallet by initiating a transfer transaction. Please refer to the following tutorial. All solutions are suggested solutions, and you can do it yourself .)

Teaching: How to do centralized trading

Aggregated transactions (or structured transactions) are transactions that send funds in your wallet scattered under various addresses to a single address. The address should be an address that is controlled by your wallet, preferably unused. Performing a fund collection after the fork can reduce the possibility of being replayed.

(1) If you use a wallet with an interface, such as a light wallet, a GUI wallet: The GUI wallet is taken as an example here. The operation methods of other wallets with interfaces are similar. Click "Request Payment" in the "Receive" interface, the wallet will automatically display a payment address, as shown in the figure below. Copy the address, go to the "Send" interface, and send all funds in the wallet to the address. You can browse your wallet balance in advance and fill in the amount of funds you need to send, or directly check "Send full balance" when sending transactions (or select the "Max" option when filling in the amount, depending on the wallet) to guarantee all balance All get collected.

(2) If you use a full node wallet (command line mode): · Use getbalance to check the total balance in the wallet; · Use getnewaddress to generate a new address; · Use sendtoaddress to transfer all balances in the wallet to the new address. Note: It is necessary to consider setting aside transaction fees, so you can set up settxfee 0.001 before transferring, and then transfer the remaining balance to the collection address through sendtoaddress.

Lava official website link: www.lavatech.org Github: https://www.github.com/lavaio

We will continue to update Blocking; if you have any questions or suggestions, please contact us!