user4708: I understand that the data included in a transaction signature is not exactly the same as the data included in a transaction hash, but why was it designed this way?  I don't see any advantage in just making the data set the same for both purposes and there are apparently a lot of drawbacks.

user85: It is designed that way because it has to be designed that way. When you sign a transaction, the signature isn't known yet. And the final transaction hash must include the signature otherwise people couldn't agree on whether a transaction was validly signed or not. So the data included in the signature cannot be the same as the data included in the hash because the former cannot include the signature itself and the latter must.

user13520: The problem is that "transaction" refers to two different things:
1) The actual monetary transaction: address A sends something to address B.
2) The collection of bytes sent to the network expressing the above.
Transaction malleability is possible because there isn't a unique way to express 1. You can express it with two different scripts that do the same thing, and therefore cause the collections of bytes in 2 to have different hashes. Transaction malleability is a consequence of the bitcoin scripting flexibility. To understand this in more detail, read this post:
http://www.righto.com/2014/02/bitcoin-transaction-malleability.html

user208: Bitcoin transactions are intentionally malleable. Some forms of malleability are a feature, and by design. Many of the more advanced uses of Bitcoin transactions (see the Contracts wiki page) rely on the ability to modify transactions in specific - and limited - ways.
However, the current problems are unrelated, and because of unintentional malleabilities. Several are known (and have been known for years). Making them impossible requires changes to the protocol, to validation software and to wallets, so cannot be done very quickly. In fact, the reference client version 0.8 (released almost a year ago) made some types of malleability already non-standard, with the hope of someday being able to add a strict network rule to forbid it.
The reason why the transaction signatures do not sign the full transaction hash, is because that would require knowing the signature before signing. The signature is part of the transaction, so it influences the transaction hash. Because of the design of the scripting language, it however signs less than just not the signatures. This is the source of many (but not all) malleabilities. Some are due to ways in which the signature itself can be modified without invalidating it.

4708: <p>I understand that the data included in a transaction signature is not exactly the same as the data included in a transaction hash, but why was it designed this way?  I don't see any advantage in just making the data set the same for both purposes and there are apparently a lot of drawbacks.</p>
 85: <p>It is designed that way because it <em>has</em> to be designed that way. When you sign a transaction, the signature isn't known yet. And the final transaction hash <em>must</em> include the signature otherwise people couldn't agree on whether a transaction was validly signed or not. So the data included in the signature <em>cannot</em> be the same as the data included in the hash because the former <em>cannot</em> include the signature itself and the latter <em>must</em>.</p>
 13520: <p>The problem is that "transaction" refers to two different things:</p>

<p>1) The actual monetary transaction: address A sends something to address B.</p>

<p>2) The collection of bytes sent to the network expressing the above.</p>

<p>Transaction malleability is possible because there isn't a unique way to express 1. You can express it with two different scripts that do the same thing, and therefore cause the collections of bytes in 2 to have different hashes. Transaction malleability is a consequence of the bitcoin <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow">scripting</a> flexibility. To understand this in more detail, read this post:</p>

<p><a href="http://www.righto.com/2014/02/bitcoin-transaction-malleability.html" rel="nofollow">http://www.righto.com/2014/02/bitcoin-transaction-malleability.html</a></p>
 208: <p>Bitcoin transactions are intentionally malleable. Some forms of malleability are a feature, and by design. Many of the more advanced uses of Bitcoin transactions (see the Contracts wiki page) rely on the ability to modify transactions in specific - and limited - ways.</p>

<p>However, the current problems are unrelated, and because of unintentional malleabilities. Several are known (and have been known for years). Making them impossible requires changes to the protocol, to validation software and to wallets, so cannot be done very quickly. In fact, the reference client version 0.8 (released almost a year ago) made some types of malleability already non-standard, with the hope of someday being able to add a strict network rule to forbid it.</p>

<p>The reason why the transaction signatures do not sign the full transaction hash, is because that would require knowing the signature before signing. The signature is part of the transaction, so it influences the transaction hash. Because of the design of the scripting language, it however signs less than just not the signatures. This is the source of many (but not all) malleabilities. Some are due to ways in which the signature itself can be modified without invalidating it.</p>
