Topic: How did tx malleability/DDOS attacks allow exchanges to get "out of sync"? (Read 735 times)

No. The original transactions will have gone through, especially if using something like the reference client Bitcoin-qt/Bitcoind, which will not usually broadcast invalid transactions. The only thing which doesn't "go through" is the expected transaction ID.


Actually that's what they should have done. They should have assumed their transaction was valid/approved once broadcast. When and if they believed it wasn't they should have investigated the reason(s) why, instead of simply sending new transactions.


No. Once a mutated version of the transaction was confirmed MtGox's accounting system had a problem because a transaction it assumed was confirmed, was confirmed, but someone told them it wasn't, and to check they used the irresponsible method of relying on transaction ID (which has the known malleability issue).

Exchanges accounting systems can get out of sync, if they follow the "transaction ID".

A customer issues a withdrawal request. The exchange system initiates a bitcoin transaction and records the TxID for audit purposes, and to show the customer for tracking purposes. In the event of a malleability attack, it is possible for a mutated version of the transaction to be accepted by the blockchain, and therefore the original transaction ID will be rejected and never confirm (but the transaction had, in fact, completed under the new ID). In this scenario, exchange software may see the TxID has failed to confirm on the blockchain, and treat it as a failed transaction, and give the customer the option of trying the withdrawal again (allegedly what happened at Silk Road 2 by a completely automated system for re-attempting withdrawals).

In the case of Mt Gox, it appears that in the event that the TxID didn't show up in the blockchain, a customer could contact support claiming not to have received the transaction (even though it had arrived), and support would issue a new transaction.

In this case, the exchange thinks that the withdrawal is still pending, but it has actually completed. Good audit and reconciliation practice should mitigate this significantly, because the books wouldn't balance as soon as a new transaction was issued and a customer got double paid.

However, if an exchange didn't take care to check their wallet balances on a regular basis, then they could easily end up losing coins. (Mt Gox claimed that they had suffered losses over a period of years. This would suggest that they had never checked their wallet balance against deposits/withdrawals ever over a period of several years - either they are lying, or the negligence is beyond comprehension).

This Coindesk article says that


I think I understand the first part; as transactions are created, hundreds of transactions are created that are identical except for a mutated signature are created in the network. The second part confuses me a bit, though. Do the exchange's accounting systems get out of sync because some of the original transactions aren't going through because a mutated version has already been confirmed in the blockchain? So for example, Mt. Gox, which was using an automated system to approve withdrawals (as stated in the article), would consider a withdrawal transaction approved before it was actually confirmed in the blockchain. Once a mutated version of that transaction was confirmed in the blockchain, Mt. Gox's accounting system had a problem because a transaction it assumed was confirmed (and therefore had already "lost" the Bitcoins for) wasn't actually confirmed.