Filecoin official: There is no such thing as "double spending" at all!

This article was originally written by IPFS Force Zone

• Issue Report. Earlier today, the Lotus team received a report that an exchange was incorrectly using the Lotus API to evaluate transfers/deposits in the Filecoin network. This incorrect API usage was reported by a user when their account was incorrectly credited twice for a deposit in the exchange's accounting system. This was later restored in the exchange's accounting - there is no double-spending issue on the Filecoin blockchain itself.

• API abuse by the exchange. The exchange in question did not properly check the chain state to de-duplicate multiple messages with the same sender and receiver. The root cause was incorrect use of the Lotus API (not a bug in the API itself) - which did not work the way they were intended. This accounting error caused the exchange to display incorrect account deposit information. So far, we are only aware of one transaction affected by this API mix-up.

• False reports make headlines: Inaccurate claims about "double spends" on the network spread across social media channels and made headlines. Many of the issues with these claims have been investigated and determined to be false. The team found no issues with the Filecoin network or RPC API code. Many groups and media outlets are correcting their reporting after learning the facts.

• Trading impact. The exchange discovered this incorrect use of the API and took immediate action to halt deposits, withdrawals, and transfers. They have since restored the incorrect transactions in question (so no funds were lost in this incident) and are correcting their use of the Lotus API to match recommended usage.

• Other exchanges. Other exchanges have been alerted and are reviewing their code to ensure they are not affected. Many reviews have been completed - to our knowledge, no other exchanges have yet misused this API in this way.

• The lotus team is actively working on all transactions to ensure this behavior is handled correctly, and improving the API documentation to ensure everyone else can correctly check the state of the Filecoin blockchain.

• Community and media teams. Several organizations are working with the media to clarify details and facts about the alleged incident and help dispel misinformation.

• Community Team. Community members are creating materials to help others report issues accurately and thoughtfully to avoid accidentally spreading misinformation.

• Similar messages. The Lotus team understands that the problem is caused by two messages sharing the same sender/receiver details and the same nonce, but containing different gas parameters in the same tipset. Two similar messages is a common form of message substitution that changes the gas fee associated with a message. The Filecoin network security mechanism correctly handles this situation and does not result in two message executions: one of the two messages is executed and the other is ignored.

• Incorrect API usage. However, depending on how the chain state is checked, this may show that the message is processed twice. Specifically, this transaction uses an incorrect way to process the chain state - calling ChainGetBlockMessages on each block in the tipset, and then calling StateGetReceipt on each message.

• Incorrect API return expectations. The confusion is that when StateGetReceipt is called on two similar messages (one executed, the other skipped), it will provide the same result: both correspond to the message that was executed. This is obviously counter-intuitive, but is intended behavior. The primary use case for the StateGetReceipt method is in event handlers used by the Lotus Miner and the transaction making process. In the case of a replaced message, these modules do not care whether the returned receipt corresponds to the original message, or to the replaced message - they just want to know if the message was successfully executed on-chain. We document this here: https://github.com/filecoin-project/lotus/pull/5838 .

• Use the correct APIs. Most exchanges correctly use ChainGetParentMessages and ChainGetParentReceipts for bookkeeping purposes to determine which messages were executed on-chain and succeeded. These are the APIs used by Lotus itself during state calculations, so the chain state is guaranteed to be correctly reflected in this way. Performing a StateReplay on each message will give you the full result of the call so that you can compare the MsgCid in the returned InvocResult with the CID of the query message. This is the recommended path for exchanges to correctly check chain state and keep their internal reporting systems in sync.