user1311: 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.
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?

user13322: 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.

user13348: 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, 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.

user8717: Here's a good interview by Gregory Maxwell himself who's a Bitcoin developer: 

Oh there is a “problem” in the Bitcoin protocol, known since at least
  2011 (see the link I gave). 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 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.

1311: <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>
 13322: <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>
 13348: <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>
 8717: <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>
