Quote from: TierNolan on February 10, 2014, 01:42:02 PM

That isn't a reason not to try.

Yes, it is. When your intended solution may likely just create more problems than there were in the first place, it is better not to try.

Currently, at least informed people know that transaction hashes are unreliable. People who understand this are a small minority of Bitcoin users already. Now consider that you implement canonical transaction hashes, which aren't actually fully canonical. Then people rely on them because no one yet knows they aren't. Then someone figures out how to make them malleable. Kaboom.

Quote from: TierNolan on February 10, 2014, 01:42:02 PM

The core problem is that the transaction hash is different from the signature hash.

The core problem, really, is that there's transaction script in the first place. This was an idiotic design decision in an otherwise brilliant protocol, and has caused nothing but grief and pain. We end up with a hobbled transaction script that can't really be used for any of the flexible purposes it was meant for, and a few hard-coded, "trusted" transaction types which don't require a script language, anyway.

If we could just define transaction hash = signing hash, that would be great. But a transaction can have many signing hashes, depending on the number of previous out points used and their pk script. Which signing hashes do we pick? We could concatenate them all, and then hash that. But then, what if a transaction is non-standard, and uses zero signatures? Then it's always malleable.

What if the signatures are of a type that doesn't sign all the new outputs, so the transaction could be disassembled, and its pieces put together to produce a different transaction that spends some of the same previous outputs? Then you can't rely on the transaction hash again, even if it's canonical.

Quote from: TierNolan on February 10, 2014, 01:42:02 PM

The possibility that the EC signature is malleable can't be defended against though.

Indeed, that is one risk.

Quote from: TierNolan on February 10, 2014, 01:42:02 PM

Even then, once it is discovered, a canonical version could be picked (unless you can create an large number or it is expensive).

But the entire deployed base of software will fail to do this, so for all practical purposes, you're back to non-canonical hashes again.