In the early morning of March 19th, some community users reported that there is a risk of double spending on the Filecoin mainnet. Exchanges such as Binance and OKex have closed the recharge function of the Filecoin mainnet token FIL. Cobo Custody also immediately suspended the recharge and Withdraw coins.
secondary title
Filecoin "double spend" story
According to the feedback from the Filecoin miners of Filfox and FileStar, on Wednesday, Binance encountered a multi-million dollar FIL double-spend recharge attack.
The reason was that it took too long for a transaction of 61,000 FIL (about 4.6 million U.S. dollars) to be recorded, so Filfox and FileStar miners initiated an RBF transaction to speed up. The RBF transaction resulted in two deposits into the Binance account, and finally 120,000 FIL was credited. Afterwards, the developers of Filfox and FileStar responded that there were "serious loopholes" in Filecoin's RPC code. The vulnerability caused Binance to choose to deposit at the same time after seeing two conflicting transactions.
FilFox and FileStar developers have contacted Binance as soon as possible, and notified the Filecoin official as soon as possible.
secondary title
Review of technical details
Centralized custodian institutions such as exchanges and centralized wallets will credit users according to the transfer behavior on the chain, so how to efficiently, accurately and timely analyze the transfer behavior on the chain is very critical. All transaction IDs in the block, and then obtain the corresponding transaction content and transaction execution results based on the transaction ID.
The Filecoin lotus node provides multiple APIs for obtaining transactions on the chain. For example, ChainGetBlockMessages can obtain all transaction content in a specified block, and StateGetReceipt can obtain the execution result corresponding to a specified transaction ID. The exchange attacked this time adopted this method. Two APIs are used to analyze the transfer behavior on the chain, and based on this, enter the account for the user.
However, they did not notice that the StateGetReceipt interface has a design that does not conform to conventional logical thinking, that is, when obtaining the execution result of the specified transaction ID, if the transaction has been replaced by RBF (replace by fee), it will return the final RBF success The execution result of that transaction, and there is no indication in the return value that this is the execution result of the transaction after RBF.
Suppose the attacker first sends TX1, the corresponding transaction ID is TXID1, then the attacker performs RBF on TX1 to generate TX2, the corresponding transaction ID is TXID2, and finally TX2 is successfully uploaded to the chain. At this time, query TXID1 and TXID2 respectively through StateGetReceipt, and both can get correct execution results.
After the attack occurred, the official Filecoin developer made a supplementary explanation to the API, clarified the return logic of StateGetReceipt, and will discard this API after the v1 version
https://github.com/filecoin-project/lotus/pull/5838/files
The Cobo Custody technical team has discovered the above problems in the process of connecting to Filecoin, so instead of using ChainGetBlockMessages and StateGetReceipt to obtain the transfer behavior on the chain, it uses ChainGetParentMessages and ChainGetParentReceipts to obtain transactions that have been successfully uploaded to the chain, thereby fundamentally avoiding The risk of being double-spend recharge is avoided, so it is not affected by this double-spend recharge attack.
In the process of using ChainGetParentMessages and ChainGetParentReceipts, the Cobo Custody technical team found that some return values of lotus nodes are not very consistent with conventional logic thinking, for example, there are some problems with the processing of empty blocks. The Cobo Custody technical team has properly handled this, and hereby reminds other centralized custody institutions to check the relevant docking code carefully to avoid other double-spending recharge attacks.
Double-spending is to use the tokens of the previous transaction to conduct transactions again, resulting in false transactions.
In 2018, Bitcoin Gold (BTG) was maliciously attacked by a miner. The miner temporarily controlled the BTG blockchain, quickly withdrew coins after recharging to the exchange, and then reversed the block, successfully implementing a double-spend attack. The attacker stole more than 388,200 BTG, worth as much as $18.6 million, and it was also one of the most famous double-spending attacks in the history of the blockchain.
