<p>What malleability means is that you can't store the transaction ID that <code>bitcoind</code> returns from its <code>sendtoaddress</code> API call and expect that number to mean anything at all later.</p>

<p>Instead, if you want to keep track of a high volume of outgoing transactions, you have to wait for the transactions to be fully confirmed and immune to blockchain reorganizations, and then guess at which blockchain transactions correspond to which withdrawal or automatic payment events by matching the amount and destination address.</p>

<p>Some famous guy recommended using a combination of amount, address, and timestamp, but apparently <a href="https://bitcoin.stackexchange.com/questions/5233/which-is-the-reliability-of-a-transaction-timestamp">transaction timestamps are not reliable either</a>, so there really isn't a good, reliable way for Bitcoin apps to keep track of which transactions they sent out and why.</p>

<p><code>bitcoind</code> itself tracks outputs, not transaction IDs, but it doesn't expose this information to API users. So if you want to send transactions and track them by the outputs, which is considered to be reliable, you need to write your own Bitcoin client, which is a lot like writing your own SQL server, except it's not as simple.</p>

CC BY-SA 3.0
2014-02-11T22:08:58.040Z
> *so there really isn't a good, reliable way for Bitcoin apps to keep track of which transactions they sent out and why*
----
Wallet address are cheap. Exchanges could create one per transaction, send a small amount there, and use that as a discriminator.
Silvio
CC BY-SA 3.0
2014-02-11T23:00:47.587Z
That's a rather inelegant hack, and they'd have to constantly dump coins into this process as they are continually eaten up by miner fees.
Guesty Guest
CC BY-SA 3.0
2014-02-12T01:52:05.173Z
a good, reliable way for Bitcoin apps to keep track of which transactions they sent out and why is to keep track of the txid and vout of the first input to the transaction, rather than the txid.  It's incorrect to say that bitcoind doesn't expose this information; it's all available via the raw transactions interface.
Chris Moore
CC BY-SA 3.0
2014-02-11T05:20:18.600Z
2014-02-11T05:20:18.600Z
2017-04-13T12:47:33.743Z
Guesty Guest
<p>Mt.Gox' escrow wallet service only checks transaction hash. If anybody changes transaction hash before transaction is included into block, service considers transaction invalid and returns coins back to the owner's virtual account. But transaction itself is not invalid, it is finally accepted and coins are sent to the owner.  </p>

<p>It is primary bug in Mt.Gox's escrow service. They probably failed to detect exceptional situations in their wallets.</p>

CC BY-SA 3.0
2014-02-10T13:40:21.523Z
2014-02-10T13:40:21.523Z
user13322
<p><a href="http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/" rel="nofollow">Here's a good interview</a> by Gregory Maxwell himself <a href="https://github.com/bitcoin/bitcoin/commits?author=gmaxwell" rel="nofollow">who's a Bitcoin developer</a>: </p>

<blockquote>
  <p>Oh there is a “problem” in the Bitcoin protocol, known since at least
  2011 (<a href="https://en.bitcoin.it/wiki/Transaction_Malleability" rel="nofollow">see the link I gave</a>). But for normal applications, not involving
  unconfirmed transactions, it shouldn’t cause any severe problems
  because wallets can handle it locally.</p>
</blockquote>

<p>This has to do with systems, such as Mt.Gox, that rely on unconfirmed transactions. Normal Bitcoin apps don't rely on unconfirmed transactions.</p>

<p>The <a href="https://en.bitcoin.it/wiki/Transaction_Malleability" rel="nofollow">Transaction Malleability</a> issue that Mt.Gox talks about has been around since 2011. It only effects transactions which are not included in a block. Once a block is hashed, you can't change the transactions within it because then the hash of the block would have to change as well.</p>

<p>For all other Bitcoin applications that rely on <em>confirmed</em> transactions, as they should, this is not an issue.</p>

CC BY-SA 3.0
2014-02-11T02:56:39.723Z
Soon,  people new to BitCoin will think that the word "MtGox" is a vulgarity.
Pacerier
CC BY-SA 3.0
2014-02-10T12:56:27.740Z
2014-03-08T22:48:57.577Z
2014-03-08T22:48:57.577Z
Luca Matteis
<p>The well-known Bitcoin exchange Mt.Gox last week suspended all Bitcoin withdrawals because of "technical issues", which today have been better described in <a href="https://www.mtgox.com/press_release_20140210.html">this press release</a>.</p>

<p>This looks like a serious problem, but is it actually true?<br>
Has this issue been confirmed by third parties?<br>
Has it really been known "for a while"?<br>
What true impact can it have?</p>

<transactions><protocol><mtgox><transaction-malleability>
Is this "transaction malleability" really an issue?
Massimo
# Is this "transaction malleability" really an issue?

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

The well-known Bitcoin exchange Mt.Gox last week suspended all Bitcoin withdrawals because of "technical issues", which today have been better described in [this press release](https://www.mtgox.com/press_release_20140210.html).

This looks like a serious problem, but is it actually true?  
Has this issue been confirmed by third parties?  
Has it really been known "for a while"?  
What true impact can it have?

**Tags:** transactions, protocol, mtgox, transaction-malleability


---

## 3 answers

### Answer by username_5 on 2014-02-10. Score: 11 | Accepted answer

[Here's a good interview](http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/) by Gregory Maxwell himself [who's a Bitcoin developer](https://github.com/bitcoin/bitcoin/commits?author=gmaxwell):

> Oh there is a “problem” in the Bitcoin protocol, known since at least
> 2011 ([see the link I gave](https://en.bitcoin.it/wiki/Transaction_Malleability)). But for normal applications, not involving
> unconfirmed transactions, it shouldn’t cause any severe problems
> because wallets can handle it locally.

This has to do with systems, such as Mt.Gox, that rely on unconfirmed transactions. Normal Bitcoin apps don't rely on unconfirmed transactions.

The [Transaction Malleability](https://en.bitcoin.it/wiki/Transaction_Malleability) issue that Mt.Gox talks about has been around since 2011. It only effects transactions which are not included in a block. Once a block is hashed, you can't change the transactions within it because then the hash of the block would have to change as well.

For all other Bitcoin applications that rely on *confirmed* transactions, as they should, this is not an issue.

> **Comments:**
> **username_6**: Soon,  people new to BitCoin will think that the word "MtGox" is a vulgarity.  

---

### Answer by username_1 on 2014-02-11. Score: 10

What malleability means is that you can't store the transaction ID that `bitcoind` returns from its `sendtoaddress` API call and expect that number to mean anything at all later.

Instead, if you want to keep track of a high volume of outgoing transactions, you have to wait for the transactions to be fully confirmed and immune to blockchain reorganizations, and then guess at which blockchain transactions correspond to which withdrawal or automatic payment events by matching the amount and destination address.

Some famous guy recommended using a combination of amount, address, and timestamp, but apparently [transaction timestamps are not reliable either](https://bitcoin.stackexchange.com/questions/5233/which-is-the-reliability-of-a-transaction-timestamp), so there really isn't a good, reliable way for Bitcoin apps to keep track of which transactions they sent out and why.

`bitcoind` itself tracks outputs, not transaction IDs, but it doesn't expose this information to API users. So if you want to send transactions and track them by the outputs, which is considered to be reliable, you need to write your own Bitcoin client, which is a lot like writing your own SQL server, except it's not as simple.

> **Comments:**
> **username_2**: > *so there really isn't a good, reliable way for Bitcoin apps to keep track of which transactions they sent out and why* ---- Wallet address are cheap. Exchanges could create one per transaction, send a small amount there, and use that as a discriminator.  
> **username_1**: That's a rather inelegant hack, and they'd have to constantly dump coins into this process as they are continually eaten up by miner fees.  
> **username_3**: a good, reliable way for Bitcoin apps to keep track of which transactions they sent out and why is to keep track of the txid and vout of the first input to the transaction, rather than the txid.  It's incorrect to say that bitcoind doesn't expose this information; it's all available via the raw transactions interface.  

---

### Answer by username_4 on 2014-02-10. Score: 6

Mt.Gox' escrow wallet service only checks transaction hash. If anybody changes transaction hash before transaction is included into block, service considers transaction invalid and returns coins back to the owner's virtual account. But transaction itself is not invalid, it is finally accepted and coins are sent to the owner.

It is primary bug in Mt.Gox's escrow service. They probably failed to detect exceptional situations in their wallets.


---

