Actually, this is the fix. I'm already running it on my nodes.

https://github.com/bitcoin/bitcoin/pull/3025

PS, like your username.  And, yes, they do -- of electric sheep.  At least the androids.

Only if it's immediately obvious that every user is using OpenSSL-linked bitcoin-qt.  That's neither obvious nor true!

For example, the transactions I use to move coins in and out of cold storage are generated by a javascript client, since it can run on an "air-walled" laptop with no network connection.  A lot of people do this.  In that case the sign of the ECDSA signature depends on what javascript VM I'm using…  Standards are standards, especially for crypto -- never a good idea to start assuming people are using specific implementations.

No, it is not possible.  Some forms of transaction mutation, like the ECSDA sign-inversion mutation, can't be distinguished from the original even if you have both of them side-by-side.

There are other forms of mutation involving alterations to the script.  There have been proposals to prohibit obviously-mutated scripts (like scripts with a bunch of no-ops stuck on the end), but going beyond the obviously-mutated scripts risks accidentally banning useful scripts or future uses of the script system not currently foreseen.

A middle ground is to come up with rules for preferred transactions (ECDSA sig has the preferred sign, DER encoding, only very basic scripts) and hold any non-preferred transactions until the next block to see if a preferred spend of the same outputs shows up.  But you can't force miners to do this and it's slightly contrary to their interests since they'd have to forego the transaction fee.  Cooking up new rules also isn't the sort of thing you want to do in a crisis like the current situation.

is a mathematically true statement.

is mathematically true, and in fact is the same statement.

They've got different hash values though, because hash functions care about binary representations, not mathematical equivalence.

...

Malleability is a potential and hypothetical issue nuisance, which only became possible to exploit at MtGox for two reasons: because Gox failed to correctly implement Bitcoin specification properly, and also because it failed to implement proper workarounds for this issue. You correctly pointed out second reason, but the first is more important to point out, in my opinion, because this is why other exchanges are much less likely to be affected, if likely at all.
Gox didn't follow the specification, which required tx signature to be encoded with ASN1/DER encoding. This requirement was specified in April 2011: https://en.bitcoin.it/wiki/Protocol_specification#Signatures
Instead they used some sloppy format which was not DER encoding but was still accepted by SSL library and old reference client. When tighter checks were implemented in bitcoin reference client (the main reason for which was actually to prevent malleability issue), their transactions, which violated bitcoin spec, were rejected. Basically, their transactions looked like what hackers would employ to exploit this issue. That allowed hackers to pick these rejected transactions up, malleate them to "fix" the signature format, and re-submit. Ironically, hackers were helping MtGox to propagate their malformed transactions through the network.

This. Quit talking about double spending, this is confusing. Notice that MtGox communication don't talk about double spend at all, either.
It's just a voluntary MtGox double send.

This is just poor bookeeping on Mt.Gox side.

If 5 BTC is sent from address X to address Y,  then it will be permanently on record in the block chain.  Does not matter which TXID was used.

It's not true. Both versions of the transaction will have the same inputs, outputs and amounts; they are two different ways of expressing the same transaction, and only one will be accepted by the network, so there is no double-spend. No-one should care which version of the transaction gets accepted. (MtGox did care, and that's their mistake.)

Let me explain further, ppl dont receive their coins isnt because of this. Its because Gox system (bookkeeping) got messed up and send out non available coins since all tx are chain-linked.

from gmaxwell
21 January 2013‎
And you'll note that page is citing a forum thread from 2011.  Bitcoin v0.8 rolled out the first round of fixes to eventually remove malleability way back then too... and we've seen bouts of amounts of malleability use on the network, back in 2012 if not sooner— I haven't grepped my logs.