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.

  • 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
    Feb 16, 2014 at 21:32
  • 2
    Wtf is loopty loop scripting?
    – Jannes
    Feb 17, 2014 at 12:33
  • @Gracchus, What do you mean by "loop scripting"?
    – Pacerier
    May 22, 2014 at 17:14

3 Answers 3


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.

  • 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
    May 22, 2014 at 17:12

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:


  • But there is a unique way to express 1 isn't it? How un-unique is "A send 0.246 BTC to B"?
    – Pacerier
    May 22, 2014 at 17:13
  • @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
    May 22, 2014 at 18:08

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.

  • Is there no better workarounds then?
    – Pacerier
    May 22, 2014 at 17:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.