Protocol Labs, the team behind the Filecoin network, has denied any bugs from their end causing the FIL double deposit issue, which drew wide attention on Thursday.
The San Francisco-based Protocol Labs published a blog post late Thursday that said reports of a Filecoin “double-spend due to a serious bug” in the network’s code are “incorrect and misleading.”
“The Lotus team has investigated the report thoroughly and have found no issues with the Filecoin network or the remote procedure call code (RPC) API. There is no double-spend on the blockchain itself, and no bug in the API code,” the project team claimed in the post.
Protocol Labs’ post was in response to reports that first emerged early Thursday PST. Some China-based Filecoin miners notified crypto exchanges that there was a potential double spend loophole on the Filecoin network.
Word of a potential double spend quickly spread across social media. To be sure, there was no on-chain double-spend. But the actual issue in question has now triggered a tug-of-war over who is to blame.
For its part, Protocol Labs said there are no bugs in its API, contending instead that exchanges “misused” its APIs.
Wallet and custody startup Cobo, co-founded by F2Pool co-founder Discus Fish, posted a follow-up article on Friday in an effort to explain the technical process behind the issue.
Cobo didn’t explicitly use the word “bug” in Filecoin’s API code, but called some of the code’s designs “illogical.”
Some users did get double-credited for their Filecoin deposits worth some $4 million. According to Protocol Labs, the affected exchange has already reverted those off-chain transactions in their internal bookkeeping system.
So what happened?
Around Friday midnight China time, developers behind the Filecoin blockchain explorer Filfox and a Filecoin hard-fork project Filestar, spotted that some FIL deposits with $4.6 million to Binance got double-credited, and subsequently notified exchanges and also Protocol Labs.
It appears that they also immediately notified Chinese media about a potential but unconfirmed on-chain double-spending, which triggered news headlines that spread across social media.
6Block, a China-based Filecoin mining firm, is the team behind the development of both Filfox and Filestar. In fact, 6Block also effectively shares the same team with Chinese public blockchain project QTUM.
As a precaution, crypto exchanges like Binance and OKEx suspended deposits in the wake of the news.
Protocol Labs initially responded to some of the Chinese media reports that it found no double spend occurred, explaining that it was a front-end issue with Filfox’s blockchain explorer.
The team behind Filfox and Filestar quickly pushed back, saying that after a thorough investigation, they found a serious bug inside the Filecoin API that Protocol Labs recommended to crypto exchanges for communicating with the network when crediting user deposits.
It was through this loophole, some users managed to get their FIL deposits credited twice, Filfox and Filestar developers said.
Hours later, Protocol Labs put out its review that there is no bug in the API itself but one unnamed exchange – effectively Binance – used it incorrectly.
“The exchange in question caught this API misuse and has taken immediate action to halt deposits, withdrawals, and transfers. They have reverted the incorrect transaction in question (so no funds were lost in this incident), and are correcting their use of lotus APIs to match the recommended use,” Protocol Labs said.
The firm added that other exchanges have been alerted and to its knowledge, “no other exchange has misused this API in this way.”
Per Cobo’s explanation, the process happened like this: Filecoin’s Lotus nodes provide different types of APIs for pulling information from on-chain transactions.
For instance, ChainGetBlockMessages is one API designed to pull details of all transactions within a designated block. StateGetReceipt is another way for pulling the execution results of a designated transaction ID.
Cobo wrote that “there’s one part that’s not really logical in StateGetReceipt’s design,” which would count the same thing twice if there’s a replace-by-fee transaction.
Replace-by-fee happens when a sender wants to speed up unconfirmed transactions by replacing them with a new one, usually with a higher fee attached.
“Assuming an attacker first send TX1 with a corresponding ID as TXID1. Then the attacker conducted RBF to generate TX2 with a corresponding TXID2. Eventually only TX2 got transacted on-chain. But if you use StateGetReceipt to inquire both TXID1 and TXID2, you’d get results that both are executed,” Cobo wrote in the post.
Cobo said it already detected this problem when it was working with Protocol Labs to support the FIL deposit to its custody service and hence didn’t use the ChainGetBlockMessages and StateGetReceipt APIs to access on-chain information.
After the report of the issue, Filecoin developers clarified the StateGetReceipt API’s design and said it will discard the API after the V1 version.
© 2021 The Block Crypto, Inc. All Rights Reserved. This article is provided for informational purposes only. It is not offered or intended to be used as legal, tax, investment, financial, or other advice.
Coinsmart. Beste Bitcoin-Börse in Europa
Source: https://www.theblockcrypto.com/post/98785/filecoin-double-spend-deny?utm_source=rss&utm_medium=rss
