<p>The requirement for canonical DER signatures was only added in the <a href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki" rel="noreferrer">BIP66</a> softfork in 2015.</p>
<p>Before that time, such non-canonical signatures were legal, and your transaction predates the BIP66 activation.</p>

CC BY-SA 4.0
2023-11-30T20:23:50.310Z
How are those old signatures verified, now that OpenSSL has been removed from the codebase?
Casey Rodarmor
CC BY-SA 4.0
2023-11-30T20:28:17.853Z
There is a custom ECDSA parser which supports all historical violations to the encoding: https://github.com/bitcoin/bitcoin/blob/v25.0/src/pubkey.cpp#L41
Pieter Wuille
CC BY-SA 4.0
2023-11-30T23:04:39.777Z
But this code is not compiled into the `bitcoinconsensus` lib? Is there a way to invoke it from there?
Alec Matusis
CC BY-SA 4.0
2023-11-30T23:09:07.683Z
@AlecMatusis Yes, it is. ECDSA signatures are *always* parsed using this code. The logic for enforcing BIP66 is independent. in `bitcoinconsensus` it is enabled using the `bitcoinconsensus_SCRIPT_FLAGS_VERIFY_DERSIG` flag.
Pieter Wuille
CC BY-SA 4.0
2023-11-30T00:00:10.760Z
2023-11-30T00:00:10.760Z
Pieter Wuille
<p>Certain rare spent P2PKH outputs give <code>error: Non-canonical DER signature</code> when I try to verify the spent output using both <a href="https://github.com/bitcoin-core/btcdeb/blob/master/doc/btcdeb.md" rel="nofollow noreferrer"><code>btcdeb</code></a> (version 5.0.24) and <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/shared-libraries.md" rel="nofollow noreferrer"><code>bitcoinconsensus</code></a> (version 0.20.2, using Rust bindings).</p>
<p>Here is a <a href="https://www.youtube.com/watch?v=McIpSbApuR4&amp;feature=youtu.be" rel="nofollow noreferrer">screen grab</a> of <code>btcdeb</code> failure on the 0th input of the transaction <a href="https://blockstream.info/tx/a618dc10b8a1f9d9a1469b3bb84fc17da86df2d51c27e2aa16fa130953840735?expand" rel="nofollow noreferrer"><code>a618dc10b8a1f9d9a1469b3bb84fc17da86df2d51c27e2aa16fa130953840735</code></a>. The command to reproduce is:</p>
<pre><code>$ btcdeb --tx=0100000001162e699cebb46e6f3fa9b99e82c792f394562ce7e6fda97980f1866f6ca7f251010000008c493045022100a9379b66c22432585cb2f5e1e85736c69cf5fdc9e1033ad583fc27f0b7c561d802202c7b5d9d92ceca742829ffbe28ba6565faa8f94556cb091cbc39d2f11d45946700014104650a9a1deb523f636379ec70c29b3e1e832e314dea0f791160f3dba628f4f509360e525318bf7892af9ffe2f585bf7b264aa31792744ec1885ce17f3b1ef50f3ffffffff0240a5ae02000000001976a914ed2533122ffd7f0724c424599206ccb23e89d6f788ac404b4c00000000001976a914c0ac87c28c943caead3e6d64663449bfc9f0a5ce88ac00000000 --txin=010000000415a71cebe8e2bc4b4b645f685dace9966a13aa1b12646b0dc808b368e49be2f6310000008c4930460221008aa83ca31a71a65f429ae46bf216f9cae8ea4474771ec996950821660f4611e8022100e2de287ac2e0edfa90b1363fde96ff0698495eb71e1460ec1e34f56912d3949101410431740cc7170cc597693a91662f4dcf78b3130900cf5f62f0104ae7f3d17856cc0f75780c7cfebd6bcce571fa3c69f2796fd3a7ab7b223750ffed25dabf198e85ffffffff2a5e1cd0f98718655093e50992762db461b09973640a011275634c7367a6c5af230000008a4730440220329aba7a3d19d07d371e001a4d74ee14d69a25b98ac13e5726ae85ce8c90d1c7022035bdb358186091d258fddd7cdf78657d1ddd8adbefd4b245f81d9d34c833475901410431740cc7170cc597693a91662f4dcf78b3130900cf5f62f0104ae7f3d17856cc0f75780c7cfebd6bcce571fa3c69f2796fd3a7ab7b223750ffed25dabf198e85ffffffff3f22f0f55ed55307e5afcb92c1af44065dbb53e147fe12f5544b0ffdc0d56efb1b0000008b483045022100dd6496bf066835511a8d5c0ef640d339dfff51e0263843177e6ecce4db155e89022058f99badfeae1638e463a53e4baac75663482b5c367a9d79fa93cdb9d9349e1a01410431740cc7170cc597693a91662f4dcf78b3130900cf5f62f0104ae7f3d17856cc0f75780c7cfebd6bcce571fa3c69f2796fd3a7ab7b223750ffed25dabf198e85ffffffff57f75b3a3412b5a3aeeaa12a0ed8a0c4158d942c6c0d671e1781abd7f41c5d47000000008a473044022037622097853da2b3f2757cb2d3776b5c0f88ec5aba4301c89cd933b02977185b02200c869b080e60b596b0f5540011be681b7b0b2cbead1730beca2653192481b50201410439363df8bfe1566aaa40c5812e9931df6d3cf97455c67dce7c1bf2f74f1564d5646ebae32a435015a68cb73ef14d8c1c8f311a19dbfb461cb161a9e2cfdad64fffffffff02b34c0f00000000001976a914ef9b3d09be64c9372c99c6de18ca225e108e63c688ac80f0fa02000000001976a9146482d425dc43ff3890071f13c07c42236e50833888ac00000000
</code></pre>
<p>Lib <code>bitcoinconsensus</code> gives <code>SCRIPT_ERR_SIG_DER</code>.</p>
<p>My question is, how these transactions ended up being put into the old blocks?</p>

<signature><transaction-verification><p2pkh>
Certain spent P2PKH outputs give error: Non-canonical DER signature
Alec Matusis
# Certain spent P2PKH outputs give error: Non-canonical DER signature

(Asked by: username_0 on 2023-11-29)

Certain rare spent P2PKH outputs give `error: Non-canonical DER signature` when I try to verify the spent output using both [`btcdeb`](https://github.com/bitcoin-core/btcdeb/blob/master/doc/btcdeb.md) (version 5.0.24) and [`bitcoinconsensus`](https://github.com/bitcoin/bitcoin/blob/master/doc/shared-libraries.md) (version 0.20.2, using Rust bindings).

Here is a [screen grab](https://www.youtube.com/watch?v=McIpSbApuR4&feature=youtu.be) of `btcdeb` failure on the 0th input of the transaction [`a618dc10b8a1f9d9a1469b3bb84fc17da86df2d51c27e2aa16fa130953840735`](https://blockstream.info/tx/a618dc10b8a1f9d9a1469b3bb84fc17da86df2d51c27e2aa16fa130953840735?expand). The command to reproduce is:

```
$ btcdeb --tx=0100000001162e699cebb46e6f3fa9b99e82c792f394562ce7e6fda97980f1866f6ca7f251010000008c493045022100a9379b66c22432585cb2f5e1e85736c69cf5fdc9e1033ad583fc27f0b7c561d802202c7b5d9d92ceca742829ffbe28ba6565faa8f94556cb091cbc39d2f11d45946700014104650a9a1deb523f636379ec70c29b3e1e832e314dea0f791160f3dba628f4f509360e525318bf7892af9ffe2f585bf7b264aa31792744ec1885ce17f3b1ef50f3ffffffff0240a5ae02000000001976a914ed2533122ffd7f0724c424599206ccb23e89d6f788ac404b4c00000000001976a914c0ac87c28c943caead3e6d64663449bfc9f0a5ce88ac00000000 --txin=010000000415a71cebe8e2bc4b4b645f685dace9966a13aa1b12646b0dc808b368e49be2f6310000008c4930460221008aa83ca31a71a65f429ae46bf216f9cae8ea4474771ec996950821660f4611e8022100e2de287ac2e0edfa90b1363fde96ff0698495eb71e1460ec1e34f56912d3949101410431740cc7170cc597693a91662f4dcf78b3130900cf5f62f0104ae7f3d17856cc0f75780c7cfebd6bcce571fa3c69f2796fd3a7ab7b223750ffed25dabf198e85ffffffff2a5e1cd0f98718655093e50992762db461b09973640a011275634c7367a6c5af230000008a4730440220329aba7a3d19d07d371e001a4d74ee14d69a25b98ac13e5726ae85ce8c90d1c7022035bdb358186091d258fddd7cdf78657d1ddd8adbefd4b245f81d9d34c833475901410431740cc7170cc597693a91662f4dcf78b3130900cf5f62f0104ae7f3d17856cc0f75780c7cfebd6bcce571fa3c69f2796fd3a7ab7b223750ffed25dabf198e85ffffffff3f22f0f55ed55307e5afcb92c1af44065dbb53e147fe12f5544b0ffdc0d56efb1b0000008b483045022100dd6496bf066835511a8d5c0ef640d339dfff51e0263843177e6ecce4db155e89022058f99badfeae1638e463a53e4baac75663482b5c367a9d79fa93cdb9d9349e1a01410431740cc7170cc597693a91662f4dcf78b3130900cf5f62f0104ae7f3d17856cc0f75780c7cfebd6bcce571fa3c69f2796fd3a7ab7b223750ffed25dabf198e85ffffffff57f75b3a3412b5a3aeeaa12a0ed8a0c4158d942c6c0d671e1781abd7f41c5d47000000008a473044022037622097853da2b3f2757cb2d3776b5c0f88ec5aba4301c89cd933b02977185b02200c869b080e60b596b0f5540011be681b7b0b2cbead1730beca2653192481b50201410439363df8bfe1566aaa40c5812e9931df6d3cf97455c67dce7c1bf2f74f1564d5646ebae32a435015a68cb73ef14d8c1c8f311a19dbfb461cb161a9e2cfdad64fffffffff02b34c0f00000000001976a914ef9b3d09be64c9372c99c6de18ca225e108e63c688ac80f0fa02000000001976a9146482d425dc43ff3890071f13c07c42236e50833888ac00000000

```

Lib `bitcoinconsensus` gives `SCRIPT_ERR_SIG_DER`.

My question is, how these transactions ended up being put into the old blocks?

**Tags:** signature, transaction-verification, p2pkh


---

## 1 answers

### Answer by username_1 on 2023-11-30. Score: 6 | Accepted answer

The requirement for canonical DER signatures was only added in the [BIP66](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki) softfork in 2015.

Before that time, such non-canonical signatures were legal, and your transaction predates the BIP66 activation.

> **Comments:**
> **username_2**: How are those old signatures verified, now that OpenSSL has been removed from the codebase?  
> **username_1**: There is a custom ECDSA parser which supports all historical violations to the encoding: https://github.com/bitcoin/bitcoin/blob/v25.0/src/pubkey.cpp#L41  
> **username_0**: But this code is not compiled into the `bitcoinconsensus` lib? Is there a way to invoke it from there?  
> **username_1**: @username_0 Yes, it is. ECDSA signatures are *always* parsed using this code. The logic for enforcing BIP66 is independent. in `bitcoinconsensus` it is enabled using the `bitcoinconsensus_SCRIPT_FLAGS_VERIFY_DERSIG` flag.  

---

