10

The recent re-emergence of transaction malleability has been responsible for a large number of Txs which are being double spent (October 2015).

/r/Bitcoin has posted some C++ code which @amaclin has taken responsibility for.

I understand that, based on this source code, the transaction malleability "exploit" is simply tweaking the DER signatures for certain Txs (ie non P2SH Txs) and rebroadcasting the Tx (disclaimer: I don't know C++ so these are educated guesses).

BIP62 deals with numerous issues, amongst these is the requirement for canonical DER signatures: I was under the impression canonical DER signatures was implemented in BIP66.

  1. Can someone clarify what @amaclin's code is doing?
  2. Why is this exploit possible if BIP66 was implemented several weeks ago?
Improve this question
2
  • 1
    @amaclin Care to comment? :)
    – Wizard Of Ozzie
    Oct 23, 2015 at 0:06
  • Sorry. I missed this post. My email is in profile. feel free to contact me
    – amaclin
    Oct 28, 2015 at 9:12

1 Answer 1

Reset to default
9

Canonical DER signature implemented in BIP 66 fixes issue #1 of BIP 62 ( Non-DER encoded ECDSA signatures )

Amacilin's code exploits issue #5 in BIP 62 ( Inherent ECSDA signature malleability ), and is explained here : https://github.com/bitcoin/bitcoin/commit/a81cd96805ce6b65cca3a40ebbd3b2eb428abb7b

This issue was fixed by requiring signatures to have low-S encoding in pull request 6769 : https://github.com/bitcoin/bitcoin/pull/6769 . Note that this fix only prevents mutated transactions from being relayed (transactions without low-S encoding can still be mined into blocks).

Improve this answer
3
  • 1
    From BIP62: Inherent ECDSA signature malleability ECDSA signatures themselves are already malleable: taking the negative of the number S inside (modulo the curve order) does not invalidate it.. Wow, that is a huge problem
    – Wizard Of Ozzie
    Oct 23, 2015 at 9:25
  • 1
    it was a problem, but its fixed by requiring low-s right?
    – mulllhausen
    Nov 1, 2015 at 13:25
  • 2
    The short answer is that BIP66 was not intended to even address malleability. It was intended to stop having the network indirectly depend on OpenSSL's arbitrary ASN.1 parser implementation. It just happened to technically coincide with a part of BIP62.
    – Pieter Wuille
    Nov 2, 2015 at 3:10

Your Answer

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

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