[bitexploder]

It is a non issue, honestly. This issue was known about as early as 2011. You can only modify non-essential pieces of the transaction, but it does change the overall transaction hash.

These poorly coded exchanges were looking for an exact hash match to pop up on the block chain, instead of looking for the deposit/address.

The actual security of the system is not really impacted at all, and the core Bitcoin clients cope fine with this. The exchanges may have put themselves at risk, but that is on them.

[wtbob]

> You can only modify non-essential pieces of the transaction, but it does change the overall transaction hash.

That's the thing I don't get. If one is going to allow non-essential changes, shouldn't one _not_ include those data in the hash? Alternatively, should one simply not allow changes, period?

I've not read the Bitcoin paper, just summaries (been too busy, and it's outside my area); perhaps there's a good reason for it.

[Guvante]

The important bits are signed with an ownership signature, and the whole transaction is hashed to be added to the block chain. As long as you don't trust the transaction hash (which isn't designed to be secure) you won't have an issue.

[bitexploder]

I think you are mostly correct. That is why some people call it an "issue", while others refer to it as a "vulnerability". I personally don't think it is a real vulnerability, more like a quirk.

[yetfeo]

It is not poorly coded exchanges that are causing the issue. It's actually an issue with the reference bitcoin client and those that use the same behaviour: http://www.reddit.com/r/Bitcoin/comments/1xm49o/due_to_activ...

Spending unconfirmed outputs in the presence of malleable transactions is unsafe. The reference client allows spending unconfirmed change outputs as they used to be considered safe. But if the original transactions is modified then the chain of unconfirmed transactions becomes double spent and the reference client gets confused about balances.