Why was the Oct 2015 Transaction Malleability event possible in spite of BIP62/66?

10

2

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?

Wizard Of Ozzie

Posted 2015-10-23T00:05:53.483

Reputation: 4 535

1@amaclin Care to comment? :) – Wizard Of Ozzie – 2015-10-23T00:06:15.277

Sorry. I missed this post. My email is in profile. feel free to contact me – amaclin – 2015-10-28T09:12:41.480

Answers

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

kaykurokawa

Posted 2015-10-23T00:05:53.483

Reputation: 1 902

1From 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 – 2015-10-23T09:25:23.407

1it was a problem, but its fixed by requiring low-s right? – mulllhausen – 2015-11-01T13:25:42.320

1The 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 – 2015-11-02T03:10:04.177

Asked: 2015-10-23T00:05:53.483

Viewed: 434 times

Active: 2015-10-23T01:41:33.190