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

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

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

CC BY-SA 3.0
2015-10-23T09:25:23.407Z
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
CC BY-SA 3.0
2015-11-01T13:25:42.320Z
it was a problem, but its fixed by requiring low-s right?
mulllhausen
CC BY-SA 3.0
2015-11-02T03:10:04.177Z
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
CC BY-SA 3.0
2015-10-23T01:41:33.190Z
2015-10-23T01:41:33.190Z
k kurokawa
<p>The recent re-emergence of transaction malleability has been responsible for a large number of Txs which are being double spent (October 2015).</p>

<p><a href="https://www.reddit.com/r/Buttcoin/comments/3okxo5/does_amaclin_need_some_btc_to_wreck_havoc/cvyfy53">/r/Bitcoin has posted</a> some C++ code which @amaclin has taken responsibility for. </p>

<p>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 (<em>disclaimer: I don't know C++ so these are educated guesses</em>). </p>

<p>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. </p>

<ol>
<li>Can someone clarify what @amaclin's code is doing?</li>
<li>Why is this exploit possible if BIP66 was implemented several weeks ago?</li>
</ol>

CC BY-SA 3.0
2015-10-23T00:06:15.277Z
@amaclin Care to comment? :)
Wizard Of Ozzie
CC BY-SA 3.0
2015-10-28T09:12:41.480Z
Sorry. I missed this post. My email is in profile. feel free to contact me
amaclin
<signature><ecdsa><transaction-malleability><bip66><bip62>
Why was the Oct 2015 Transaction Malleability event possible in spite of BIP62/66?
Wizard Of Ozzie
# Why was the Oct 2015 Transaction Malleability event possible in spite of BIP62/66?

(Asked by: username_0 on 2015-10-23)

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](https://www.reddit.com/r/Buttcoin/comments/3okxo5/does_amaclin_need_some_btc_to_wreck_havoc/cvyfy53) some C++ code which @username_1 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 @username_1's code is doing?
2. Why is this exploit possible if BIP66 was implemented several weeks ago?

**Tags:** signature, ecdsa, transaction-malleability, bip66, bip62

> **Comments:**
> **username_0**: @username_1 Care to comment? :)  
> **username_1**: Sorry. I missed this post. My email is in profile. feel free to contact me  

---

## 1 answers

### Answer by username_2 on 2015-10-23. Score: 9 | Accepted answer

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

> **Comments:**
> **username_0**: 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  
> **username_3**: it was a problem, but its fixed by requiring low-s right?  
> **username_4**: 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.  

---

