<p>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. </p>

<p>The operator of <a href="http://faucet.xeno-genesis.com/" rel="nofollow">http://faucet.xeno-genesis.com/</a> also informed me his service had huge issues around the time of the malleability bot. </p>

<p>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. </p>

<p>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.</p>

<p>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.</p>

<p>MtGOX also would have had issues sending coins they received <em>before</em> 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.</p>

<p>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. </p>

<p>Wallets which sent a high number of transactions during the attack were most affected. </p>

CC BY-SA 3.0
2014-08-18T14:17:31.010Z
2014-08-18T14:17:31.010Z
karimkorun
<p>Transaction malleability has nothing to do with it.
Read <a href="http://www.reddit.com/tb/1zcrj8" rel="nofollow">http://www.reddit.com/tb/1zcrj8</a> to learn more.</p>

CC BY-SA 3.0
2014-05-22T18:48:51.533Z
Doesn't "transaction malleability" have *everything* to do with it?
Pacerier
CC BY-SA 3.0
2014-03-03T01:49:50.243Z
2014-03-03T01:49:50.243Z
TheGenesisBloke
<p><a href="http://www.coindesk.com/massive-concerted-attack-launched-bitcoin-exchanges/">This Coindesk article</a> says that:</p>

<blockquote>
  <p>“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.</p>
  
  <p>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.</p>
</blockquote>

<p>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. </p>

<p>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.</p>

<p>Is my understanding correct?</p>

CC BY-SA 3.0
2014-03-02T22:09:36.037Z
The reports that Mt. Gox's problems were actually due to transaction malleability are, at the moment, speculation with little evidence.
Greg Hewgill
CC BY-SA 3.0
2014-03-02T22:26:32.577Z
@GregHewgill I hadn't heard about that. The reports I heard were that Mt. Gox was drained through multiple withdrawals because of transaction malleability and the way they processed transactions. I've also heard other people saying that the person in charge just ran off with the coins; are both of those ideas basically just speculation at the moment?
Jacob
CC BY-SA 3.0
2014-03-02T22:31:16.460Z
Yes, it's all speculation. For example, see http://falkvinge.net/2014/02/28/the-gox-crater-crowd-detectives-reveal-billion-dollar-heist-as-inside-job/ for an analysis from a different perspective.
Greg Hewgill
CC BY-SA 3.0
2014-03-02T22:44:15.177Z
@GregHewgill That's a very informative article; thanks for posting that!
Jacob
CC BY-SA 3.0
2014-03-03T13:09:16.997Z
related: [What is Transaction Malleability?](http://bitcoin.stackexchange.com/q/21994/5406), [Collecting questions related to Mt.Gox' insolvency](http://meta.bitcoin.stackexchange.com/q/538/5406)
Murch
<blockchain><transaction-malleability><attack>
How did transaction malleability/DDOS attacks allow an exchange's internal accounting system to get "out of sync"?
Jacob
# How did transaction malleability/DDOS attacks allow an exchange's internal accounting system to get "out of sync"?

(Asked by: username_0 on 2014-03-02)

[This Coindesk article](http://www.coindesk.com/massive-concerted-attack-launched-bitcoin-exchanges/) 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?

**Tags:** blockchain, transaction-malleability, attack

> **Comments:**
> **username_1**: The reports that Mt. Gox's problems were actually due to transaction malleability are, at the moment, speculation with little evidence.  
> **username_0**: @GregHewgill I hadn't heard about that. The reports I heard were that Mt. Gox was drained through multiple withdrawals because of transaction malleability and the way they processed transactions. I've also heard other people saying that the person in charge just ran off with the coins; are both of those ideas basically just speculation at the moment?  
> **username_1**: Yes, it's all speculation. For example, see http://falkvinge.net/2014/02/28/the-gox-crater-crowd-detectives-reveal-billion-dollar-heist-as-inside-job/ for an analysis from a different perspective.  
> **username_0**: @GregHewgill That's a very informative article; thanks for posting that!  
> **username_2**: related: [What is Transaction Malleability?](http://bitcoin.stackexchange.com/q/21994/5406), [Collecting questions related to Mt.Gox' insolvency](http://meta.bitcoin.stackexchange.com/q/538/5406)  

---

## 2 answers

### Answer by username_3 on 2014-08-18. Score: 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 by username_4 on 2014-03-03. Score: -2

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

> **Comments:**
> **username_5**: Doesn't "transaction malleability" have *everything* to do with it?  

---

