<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>

CC BY-SA 3.0
2014-05-22T17:12:18.067Z
When you say "in fact, the reference client version 0.8 made some types of malleability already non-standard", what *types* of malleability are you talking about?
Pacerier
CC BY-SA 3.0
2014-02-17T00:24:42.557Z
2014-02-17T00:24:42.557Z
Pieter Wuille
<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>

CC BY-SA 3.0
2014-05-22T17:13:33.023Z
But there *is* a unique way to express 1 isn't it? How un-unique is "A send 0.246 BTC to B"?
Pacerier
CC BY-SA 3.0
2014-05-22T18:08:25.443Z
@Gracchus, I don't get it, his whole answer is based on "Transaction malleability is possible because there isn't a unique way to express 1" which is false, yet it gets 4 upvotes...
Pacerier
CC BY-SA 3.0
2014-02-16T22:54:27.190Z
2014-02-16T22:54:27.190Z
Diego Basch
<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>

CC BY-SA 3.0
2014-05-22T17:14:10.073Z
Is there no better workarounds then?
Pacerier
CC BY-SA 3.0
2014-04-16T17:10:50.183Z
2014-04-16T17:10:50.183Z
David Schwartz
<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>

CC BY-SA 3.0
2014-02-16T21:32:53.100Z
The many examples I've seen simply have insignificant zeros added to a signature. Why not just remove the extra insignificant zeros and only have significant numbers?
John T
CC BY-SA 3.0
2014-02-17T12:33:50.347Z
Wtf is loopty loop scripting?
Jannes
CC BY-SA 3.0
2014-05-22T17:14:42.670Z
@Gracchus, What do you mean by "loop scripting"?
Pacerier
<transactions><transaction-malleability>
Why was transaction malleability ever allowed?
RentFree
# Why was transaction malleability ever allowed?

(Asked by: username_0 on 2014-02-16)

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.

**Tags:** transactions, transaction-malleability

> **Comments:**
> **username_1**: The many examples I've seen simply have insignificant zeros added to a signature. Why not just remove the extra insignificant zeros and only have significant numbers?  
> **username_2**: Wtf is loopty loop scripting?  
> **username_3**: @Gracchus, What do you mean by "loop scripting"?  

---

## 3 answers

### Answer by username_4 on 2014-02-17. Score: 7

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.

> **Comments:**
> **username_3**: When you say "in fact, the reference client version 0.8 made some types of malleability already non-standard", what *types* of malleability are you talking about?  

---

### Answer by username_5 on 2014-02-16. Score: 4

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](https://en.bitcoin.it/wiki/Script) flexibility. To understand this in more detail, read this post:

<http://www.righto.com/2014/02/bitcoin-transaction-malleability.html>

> **Comments:**
> **username_3**: But there *is* a unique way to express 1 isn't it? How un-unique is "A send 0.246 BTC to B"?  
> **username_3**: @Gracchus, I don't get it, his whole answer is based on "Transaction malleability is possible because there isn't a unique way to express 1" which is false, yet it gets 4 upvotes...  

---

### Answer by username_6 on 2014-04-16. Score: 2

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*.

> **Comments:**
> **username_3**: Is there no better workarounds then?  

---

