How did transaction malleability/DDOS attacks allow an exchange's internal accounting system to get "out of sync"?

Question

This Coindesk article says that:

“So as transactions are being created, malformed/parallel transactions are also being created so as to create a fog of confusion over the entire network, which then affects almost every single implementation out there,” he added.

Antonopoulos went on to say that Blockchain.info’s implementation is not affected, but some exchanges have been affected – their internal accounting systems are gradually going out of sync with the network.

How does this getting out of sync occur? Here's my understanding; as a transaction is created, malicious users create hundreds of transactions in the network that are identical except for a mutated signature. The original transaction may or may not be confirmed because a mutated version may get confirmed in the blockchain first.

For example, Mt. Gox, which used an automated system to approve withdrawals (as the article states), 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.

Is my understanding correct?

Answer 1

I'll assume that MtGOX are being truthful here, to avoid undermining OP's question. Transaction malleability was absolutely an issue around the time. It affected a number of implementations, from BitcoinJ, to older bitcoin nodes.

The operator of http://faucet.xeno-genesis.com/ also informed me his service had huge issues around the time of the malleability bot.

The confusion that can occur in a wallet is like this: Imagine your node hears about a transaction with ID A, paying into your wallet. But, imagine this transaction was malleated, and the original was the one to be confirmed. Your wallet has no knowledge of this.

All transactions refer to unspent transactions, and although a various copies of a transaction transaction can exist temporarily in different parts of the world, eventually only one will confirm. We know inputs can only be spent once.

Some implementations might not handle this correctly. Imagine trying to spend a Tx that didn't exist, maybe your customer wants to withdraw BTC? It would fail if you don't check if newly published blocks have transactions that conflict with unconfirmed transactions. You could observe two transactions spending the same input, so you'd take the confirmed one as valid.

MtGOX also would have had issues sending coins they received before the attack. The reason is, if they broadcast their transaction, and a malleated copy ended up in the blockchain, they would assume it failed to confirm, so the customer can try again. Maybe even using other inputs! This cycle could have been repeated by one attacker over and over draining the wallet.

Another possible issue is that if they did correctly believe the transaction went through, but still tried to spend the incorrect TxID, then that transaction would fail, causing panic from the customer.

Wallets which sent a high number of transactions during the attack were most affected.

Answer 2

Transaction malleability has nothing to do with it. Read http://www.reddit.com/tb/1zcrj8 to learn more.