<p>the fact that <code>pybitcointools</code> (a pure python implementation of ecdsa) is able to verify the message against the pubkey and signature indicates that it is a problem with <code>openssl</code> and not with the data itself being incorrect.</p>

<p>as per <a href="https://bitcoin.stackexchange.com/users/12983/amaclin">amaclin</a>'s comments under his answer, the der encoding for this signature is non-standard:</p>

<pre><code>30440220bb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a022004afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a2
</code></pre>

<p>this is decoded as:</p>

<pre><code>0x30 # constant placeholder
0x44 # total length = 68 bytes
0x02 # constant placeholder
0x20 # r-length = 32 bytes
0xbb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a # r
0x02 # constant placeholder
0x20 # s-length = 32 bytes
0x04afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a2 # s
</code></pre>

<p>note that the <code>r</code> value here starts with <code>0xbb = 1011 1011</code> - since the most significant bit (<code>0x80</code>) is set then this is a negative number. this would fail the <a href="https://github.com/bitcoin/bitcoin/blob/41e6e4caba9899ce7c165b0784461c55c867ee24/src/script/interpreter.cpp#L99" rel="nofollow noreferrer"><code>IsValidSignatureEncoding</code></a> check and be rejected ever since <a href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki" rel="nofollow noreferrer">bip66</a>. specifically, this line would cause the failure:</p>

<pre><code>// Negative numbers are not allowed for R.
if (sig[4] &amp; 0x80) return false;
</code></pre>

<p>here <code>sig[4]</code> is the first (leftmost) byte of the <code>r</code> value.</p>

<p>so this explains why some versions of openssl will fail this checksig and others will pass it - it is non-standard der encoding which is only compatible with certain versions of openssl.</p>

CC BY-SA 3.0
2015-06-01T04:56:02.917Z
2015-06-01T05:06:26.790Z
2017-04-13T12:47:34.187Z
mulllhausen
<p>Yes, you calculated digest <strong>2c7ecdcb2381e657228284398f2f66b2d7d9cf6aa1bd8e39a7300d0b3c8cfa5a</strong> correctly.</p>

<p>Here is my piece of dirty code:</p>

<pre><code>static void xxtest ( )
{
  const QByteArray t ( MyByteArray ( )
      .putInt32 ( TX_VERSION ) // 01000000
      .putInt8 ( 1 )           // 01 : one input
      .putArray ( QByteArray::fromHex ( "5f386c8a3842c9a9dcfa9b78be785a40a7bda08b64646be3654301eaccfc8d5e" ) )
      .putInt32 ( 1 )          // 01000000 : index
      .putPrefixed ( MyByteArray ( )
         .putInt8 ( OP_DUP )
         .putInt8 ( OP_HASH160 )
         .putPrefixed ( QByteArray::fromHex ( "21c43ce400901312a603e4207aadfd742be8e7da" ) )
         .putInt8 ( OP_EQUALVERIFY )
         .putInt8 ( OP_CHECKSIG ) )
       .putInt32 ( TX_SEQUENCE )
       .putInt8 ( 0 )          // no outputs
       .putInt32 ( TX_LOCK )
       .putInt32 ( SIGHASH_NONE ) );
  _trace ( QString ( t.toHex ( ).constData ( ) ) );
  const MyKey32 digest ( t.constData ( ), t.size ( ) );
  _trace ( QString ( "digest = %1" ).arg ( digest.toStringRev ( ) ) );
  const QByteArray pubkey ( QByteArray::fromHex ( "04f1939ae6b01e849bf05d0ed51fd5b92b79a0e313e3f389c726f11fa3e144d9227b07e8a87c0ee36372e967e090d11b777707aa73efacabffffa285c00b3622d6" ) );
  const QByteArray signature ( QByteArray::fromHex ( "30440220bb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a022004afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a2" ) );
  _trace ( QString ( "verify=%1 (expected value=1)" ).arg ( digest.verify ( pubkey, signature ) ) );
  // now test the same with wrong digest
  const MyKey32 temp ( "temp", 4 );
  _trace ( QString ( "verify=%1 (expected value=0)" ).arg ( temp.verify ( pubkey, signature ) ) );
}
//--------------------------------------------------------------
bool MyKey32::verify ( const QByteArray&amp; pub, const QByteArray&amp; sig ) const
{
  return 0 &lt; ECDSA_verify ( 0, constPtr ( ), 32, (const quint8*)sig.constData ( ), sig.size ( ), EC_KEY_pub_key ( pub ) );
}
</code></pre>

<p>the output is:</p>

<pre><code>"01000000015f386c8a3842c9a9dcfa9b78be785a40a7bda08b64646be3654301eaccfc8d5e010000001976a91421c43ce400901312a603e4207aadfd742be8e7da88acffffffff000000000002000000"
"digest = 2c7ecdcb2381e657228284398f2f66b2d7d9cf6aa1bd8e39a7300d0b3c8cfa5a"
"verify=1 (expected value=1)"
"verify=0 (expected value=0)"
</code></pre>

<p><strong>Update:</strong>
Here is small program for checking signatures with dependency only for OpenSSL lib:</p>

<pre><code>#include &lt;QByteArray&gt;
#include &lt;QDebug&gt;

#include &lt;openssl/ec.h&gt;
#include &lt;openssl/evp.h&gt;
#include &lt;openssl/ecdsa.h&gt;
#include &lt;openssl/sha.h&gt;

static EC_KEY* EC_KEY_pub_key ( const QByteArray&amp; pub )
{
  static EC_KEY* eckey = EC_KEY_new_by_curve_name ( NID_secp256k1 );
  const quint8* ppub = (const quint8*)pub.constData ( );
  o2i_ECPublicKey ( &amp;eckey, &amp;ppub, pub.size ( ) );
  return eckey;
}
//--------------------------------------------------------------
int main(int argc, char *argv[])
{
  const QByteArray data ( QByteArray::fromHex ( argv [1] ) );
  const QByteArray sign ( QByteArray::fromHex ( argv [2] ) );
  const QByteArray pubk ( QByteArray::fromHex ( argv [3] ) );

  quint8 tmp [32];
  ::SHA256 ( (const quint8*)data.constData ( ), data.size ( ), tmp );
  quint8 digest [32];
  ::SHA256 ( tmp, 32, digest );
  qDebug ( ) &lt;&lt; "data=" &lt;&lt; QString ( data.toHex ( ) );
  qDebug ( ) &lt;&lt; "sign=" &lt;&lt; QString ( sign.toHex ( ) );
  qDebug ( ) &lt;&lt; "pubk=" &lt;&lt; QString ( pubk.toHex ( ) );

  qDebug ( ) &lt;&lt; "digest=" &lt;&lt; QString ( QByteArray ( (const char*)digest, 32 ).toHex ( ) );

  const bool v ( ::ECDSA_verify ( 0, digest, 32, (const quint8*)sign.constData ( ), sign.size ( ), EC_KEY_pub_key ( pubk ) ) );
  qDebug ( ) &lt;&lt; "result=" &lt;&lt; v;

  return 0;
}
</code></pre>

CC BY-SA 3.0
2015-05-21T00:53:10.080Z
excellent thanks. its very strange its failing to verify on two of my pcs! i will test it with the rpc client and also with pybitcointools. if the rpc client fails then it must be a problem with a particular version/configuration of openssl...
mulllhausen
CC BY-SA 3.0
2015-05-21T14:10:05.610Z
oh, yes! the signature has non-standard der-encoding! Just look to the start of it: 30440220bb... - the proper encoding is 3044022100bb... because R-part can not be negative and starts with "bb". Some OpenSSL versions allow this, some others - not. See http://bitcoin.stackexchange.com/questions/2376/ecdsa-r-s-encoding-as-a-signature
amaclin
CC BY-SA 3.0
2015-05-21T14:48:18.927Z
to be correct 3045022100bb...
amaclin
CC BY-SA 3.0
2015-05-21T14:53:01.037Z
no luck with the rpc client - see my updated op :p
mulllhausen
CC BY-SA 3.0
2015-05-21T15:16:23.210Z
I have never used rpc for verifying transaction signatures. Seems to me that this call is intended for something else. Drop me a mail to alistermaclin@mail.ru and I will send you Qt/C++ code for checking such things
amaclin
CC BY-SA 3.0
2015-05-24T18:43:17.763Z
Yes, OpenSSL versions since Jan. 2015 check correct DER in signatures (DSA and RSA as well as ECDSA); that's 0.9.8zd+ 1.0.0p+ 1.0.1k+ and 1.0.2*. http://bitcoin.stackexchange.com/questions/35841/get-latest-blocks-with-bitcoind-on-ubuntu is the same problem.
dave_thompson_085
CC BY-SA 3.0
2015-05-27T01:05:52.733Z
i came accross [bip66](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki) while googling and this addresses the problem.
mulllhausen
CC BY-SA 3.0
2015-05-20T08:01:24.953Z
2015-05-21T16:05:23.437Z
2015-05-21T16:05:23.437Z
amaclin
<p>i'm attempting to verify a checksig from a transaction in the live blockchain. it is failing on my debian jessie pc with <code>openssl 1.0.1k</code>, failing on my ubuntu 12.04 virtual machine with <code>openssl 1.0.1</code> and validating correctly on my debian wheezy pc with <code>openssl 1.0.1e</code>. both are <a href="https://github.com/mulllhausen/btc-inquisitor" rel="nofollow">using the same code</a>. the transaction is <a href="http://blockexplorer.com/tx/599e47a8114fe098103663029548811d2651991b62397e057f0c863c2bc9f9ea" rel="nofollow">the first instance of a SIGHASH_NONE in the live blockchain</a>. i calculate the "message" (tx) hash as:</p>

<pre><code>hex: 2c7ecdcb2381e657228284398f2f66b2d7d9cf6aa1bd8e39a7300d0b3c8cfa5a
same thing in base58: 3zh5uvKWoRjFgKMSLRVqEWXB6YVLsuDKo97yCsCJZ2wB
</code></pre>

<p>the signature is:</p>

<pre><code>hex: 30440220bb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a022004afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a2
same thing in base58: 381yXZvFc5V2dx81gRNNpj7ResKUgWA92mkTefemM9gM2kW37b3DGkV5v2BsFq94pSuH1E4jHq9ScHcp6T7Mfg41a7rbZCnd
note that this signature does not have the 02 hashcode appended to it
</code></pre>

<p>and the pubkey is:</p>

<pre><code>hex: 04f1939ae6b01e849bf05d0ed51fd5b92b79a0e313e3f389c726f11fa3e144d9227b07e8a87c0ee36372e967e090d11b777707aa73efacabffffa285c00b3622d6
same thing in base58: SJa4B8CrqDs6St5KaXMm4KCCksaT7RDcCaRDyKSD6Mbu1WzSwokEq3JwGtfZRz7by6jYD5QmuVhgqsPYc6wTijQq
converts to bitcoin address: 145YPBBWRj4aquewvx59SAWNrSZFT5rvxr
</code></pre>

<p>could someone tell me if these parameters pass the ecdsa verification or not? also if anyone knows of an online validator that would be helpful.</p>

<hr>

<p>i'm trying to verify this with the jsonrpc client but it doesn't work on any machine i have:</p>

<pre><code>#!/usr/bin/env python2.7                                                        

from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException
rpcuser = 1
rpcpassword = 1
rpc_connection = AuthServiceProxy("http://%s:%s@127.0.0.1:8332" % (rpcuser, rpcpassword))
message = "3zh5uvKWoRjFgKMSLRVqEWXB6YVLsuDKo97yCsCJZ2wB"                        
sig = "381yXZvFc5V2dx81gRNNpj7ResKUgWA92mkTefemM9gM2kW37b3DGkV5v2BsFq94pSuH1E4jHq9ScHcp6T7Mfg41a7rbZCnd"
addr = "145YPBBWRj4aquewvx59SAWNrSZFT5rvxr"                                     
res = rpc_connection.verifymessage(addr, sig, message)                          
print res
</code></pre>

<p>output:</p>

<pre><code>False
</code></pre>

<p>maybe i'm encoding the message or signature wrong for the rpc client? i tried passing binary encoded data to it, but it didn't like that:</p>

<pre><code>File "/usr/local/lib/python2.7/dist-packages/bitcoinrpc/authproxy.py", line 125, in __call__
    json.dumps(args, default=EncodeDecimal)))
  File "/usr/lib/python2.7/json/__init__.py", line 238, in dumps
    **kw).encode(obj)
  File "/usr/lib/python2.7/json/encoder.py", line 200, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/usr/lib/python2.7/json/encoder.py", line 263, in iterencode
    return _iterencode(o, 0)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xcd in position 2: invalid continuation byte
</code></pre>

<hr>

<p>verifying with <a href="https://github.com/vbuterin/pybitcointools" rel="nofollow">pybitcointools</a> works on all machines:</p>

<pre><code>from bitcoin import *
import binascii

msg = "2c7ecdcb2381e657228284398f2f66b2d7d9cf6aa1bd8e39a7300d0b3c8cfa5a"
# make sure to include the 02 hashcode on the end of the signature here!!
sig = "30440220bb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a022004afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a202"
pub = "04f1939ae6b01e849bf05d0ed51fd5b92b79a0e313e3f389c726f11fa3e144d9227b07e8a87c0ee36372e967e090d11b777707aa73efacabffffa285c00b3622d6"
msg = binascii.unhexlify(msg)
print ecdsa_raw_verify(msg, der_decode_sig(sig), pub)
</code></pre>

<p>output:</p>

<pre><code>True
</code></pre>

<signature><checksig>
blockchain checksig fail
mulllhausen
# blockchain checksig fail

(Asked by: username_0 on 2015-05-19)

i'm attempting to verify a checksig from a transaction in the live blockchain. it is failing on my debian jessie pc with `openssl 1.0.1k`, failing on my ubuntu 12.04 virtual machine with `openssl 1.0.1` and validating correctly on my debian wheezy pc with `openssl 1.0.1e`. both are [using the same code](https://github.com/username_0/btc-inquisitor). the transaction is [the first instance of a SIGHASH\_NONE in the live blockchain](http://blockexplorer.com/tx/599e47a8114fe098103663029548811d2651991b62397e057f0c863c2bc9f9ea). i calculate the "message" (tx) hash as:

```
hex: 2c7ecdcb2381e657228284398f2f66b2d7d9cf6aa1bd8e39a7300d0b3c8cfa5a
same thing in base58: 3zh5uvKWoRjFgKMSLRVqEWXB6YVLsuDKo97yCsCJZ2wB

```

the signature is:

```
hex: 30440220bb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a022004afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a2
same thing in base58: 381yXZvFc5V2dx81gRNNpj7ResKUgWA92mkTefemM9gM2kW37b3DGkV5v2BsFq94pSuH1E4jHq9ScHcp6T7Mfg41a7rbZCnd
note that this signature does not have the 02 hashcode appended to it

```

and the pubkey is:

```
hex: 04f1939ae6b01e849bf05d0ed51fd5b92b79a0e313e3f389c726f11fa3e144d9227b07e8a87c0ee36372e967e090d11b777707aa73efacabffffa285c00b3622d6
same thing in base58: SJa4B8CrqDs6St5KaXMm4KCCksaT7RDcCaRDyKSD6Mbu1WzSwokEq3JwGtfZRz7by6jYD5QmuVhgqsPYc6wTijQq
converts to bitcoin address: 145YPBBWRj4aquewvx59SAWNrSZFT5rvxr

```

could someone tell me if these parameters pass the ecdsa verification or not? also if anyone knows of an online validator that would be helpful.

---

i'm trying to verify this with the jsonrpc client but it doesn't work on any machine i have:

```
#!/usr/bin/env python2.7                                                        

from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException
rpcuser = 1
rpcpassword = 1
rpc_connection = AuthServiceProxy("http://%s:%s@127.0.0.1:8332" % (rpcuser, rpcpassword))
message = "3zh5uvKWoRjFgKMSLRVqEWXB6YVLsuDKo97yCsCJZ2wB"                        
sig = "381yXZvFc5V2dx81gRNNpj7ResKUgWA92mkTefemM9gM2kW37b3DGkV5v2BsFq94pSuH1E4jHq9ScHcp6T7Mfg41a7rbZCnd"
addr = "145YPBBWRj4aquewvx59SAWNrSZFT5rvxr"                                     
res = rpc_connection.verifymessage(addr, sig, message)                          
print res

```

output:

```
False

```

maybe i'm encoding the message or signature wrong for the rpc client? i tried passing binary encoded data to it, but it didn't like that:

```
File "/usr/local/lib/python2.7/dist-packages/bitcoinrpc/authproxy.py", line 125, in __call__
    json.dumps(args, default=EncodeDecimal)))
  File "/usr/lib/python2.7/json/__init__.py", line 238, in dumps
    **kw).encode(obj)
  File "/usr/lib/python2.7/json/encoder.py", line 200, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/usr/lib/python2.7/json/encoder.py", line 263, in iterencode
    return _iterencode(o, 0)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xcd in position 2: invalid continuation byte

```

---

verifying with [pybitcointools](https://github.com/vbuterin/pybitcointools) works on all machines:

```
from bitcoin import *
import binascii

msg = "2c7ecdcb2381e657228284398f2f66b2d7d9cf6aa1bd8e39a7300d0b3c8cfa5a"
# make sure to include the 02 hashcode on the end of the signature here!!
sig = "30440220bb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a022004afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a202"
pub = "04f1939ae6b01e849bf05d0ed51fd5b92b79a0e313e3f389c726f11fa3e144d9227b07e8a87c0ee36372e967e090d11b777707aa73efacabffffa285c00b3622d6"
msg = binascii.unhexlify(msg)
print ecdsa_raw_verify(msg, der_decode_sig(sig), pub)

```

output:

```
True

```

**Tags:** signature, checksig


---

## 2 answers

### Answer by username_0 on 2015-06-01. Score: 0 | Accepted answer

the fact that `pybitcointools` (a pure python implementation of ecdsa) is able to verify the message against the pubkey and signature indicates that it is a problem with `openssl` and not with the data itself being incorrect.

as per [username_1](https://bitcoin.stackexchange.com/users/12983/username_1)'s comments under his answer, the der encoding for this signature is non-standard:

```
30440220bb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a022004afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a2

```

this is decoded as:

```
0x30 # constant placeholder
0x44 # total length = 68 bytes
0x02 # constant placeholder
0x20 # r-length = 32 bytes
0xbb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a # r
0x02 # constant placeholder
0x20 # s-length = 32 bytes
0x04afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a2 # s

```

note that the `r` value here starts with `0xbb = 1011 1011` - since the most significant bit (`0x80`) is set then this is a negative number. this would fail the [`IsValidSignatureEncoding`](https://github.com/bitcoin/bitcoin/blob/41e6e4caba9899ce7c165b0784461c55c867ee24/src/script/interpreter.cpp#L99) check and be rejected ever since [bip66](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki). specifically, this line would cause the failure:

```
// Negative numbers are not allowed for R.
if (sig[4] & 0x80) return false;

```

here `sig[4]` is the first (leftmost) byte of the `r` value.

so this explains why some versions of openssl will fail this checksig and others will pass it - it is non-standard der encoding which is only compatible with certain versions of openssl.


---

### Answer by username_1 on 2015-05-20. Score: 2

Yes, you calculated digest **2c7ecdcb2381e657228284398f2f66b2d7d9cf6aa1bd8e39a7300d0b3c8cfa5a** correctly.

Here is my piece of dirty code:

```
static void xxtest ( )
{
  const QByteArray t ( MyByteArray ( )
      .putInt32 ( TX_VERSION ) // 01000000
      .putInt8 ( 1 )           // 01 : one input
      .putArray ( QByteArray::fromHex ( "5f386c8a3842c9a9dcfa9b78be785a40a7bda08b64646be3654301eaccfc8d5e" ) )
      .putInt32 ( 1 )          // 01000000 : index
      .putPrefixed ( MyByteArray ( )
         .putInt8 ( OP_DUP )
         .putInt8 ( OP_HASH160 )
         .putPrefixed ( QByteArray::fromHex ( "21c43ce400901312a603e4207aadfd742be8e7da" ) )
         .putInt8 ( OP_EQUALVERIFY )
         .putInt8 ( OP_CHECKSIG ) )
       .putInt32 ( TX_SEQUENCE )
       .putInt8 ( 0 )          // no outputs
       .putInt32 ( TX_LOCK )
       .putInt32 ( SIGHASH_NONE ) );
  _trace ( QString ( t.toHex ( ).constData ( ) ) );
  const MyKey32 digest ( t.constData ( ), t.size ( ) );
  _trace ( QString ( "digest = %1" ).arg ( digest.toStringRev ( ) ) );
  const QByteArray pubkey ( QByteArray::fromHex ( "04f1939ae6b01e849bf05d0ed51fd5b92b79a0e313e3f389c726f11fa3e144d9227b07e8a87c0ee36372e967e090d11b777707aa73efacabffffa285c00b3622d6" ) );
  const QByteArray signature ( QByteArray::fromHex ( "30440220bb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a022004afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a2" ) );
  _trace ( QString ( "verify=%1 (expected value=1)" ).arg ( digest.verify ( pubkey, signature ) ) );
  // now test the same with wrong digest
  const MyKey32 temp ( "temp", 4 );
  _trace ( QString ( "verify=%1 (expected value=0)" ).arg ( temp.verify ( pubkey, signature ) ) );
}
//--------------------------------------------------------------
bool MyKey32::verify ( const QByteArray& pub, const QByteArray& sig ) const
{
  return 0 < ECDSA_verify ( 0, constPtr ( ), 32, (const quint8*)sig.constData ( ), sig.size ( ), EC_KEY_pub_key ( pub ) );
}

```

the output is:

```
"01000000015f386c8a3842c9a9dcfa9b78be785a40a7bda08b64646be3654301eaccfc8d5e010000001976a91421c43ce400901312a603e4207aadfd742be8e7da88acffffffff000000000002000000"
"digest = 2c7ecdcb2381e657228284398f2f66b2d7d9cf6aa1bd8e39a7300d0b3c8cfa5a"
"verify=1 (expected value=1)"
"verify=0 (expected value=0)"

```

**Update:**
Here is small program for checking signatures with dependency only for OpenSSL lib:

```
#include <QByteArray>
#include <QDebug>

#include <openssl/ec.h>
#include <openssl/evp.h>
#include <openssl/ecdsa.h>
#include <openssl/sha.h>

static EC_KEY* EC_KEY_pub_key ( const QByteArray& pub )
{
  static EC_KEY* eckey = EC_KEY_new_by_curve_name ( NID_secp256k1 );
  const quint8* ppub = (const quint8*)pub.constData ( );
  o2i_ECPublicKey ( &eckey, &ppub, pub.size ( ) );
  return eckey;
}
//--------------------------------------------------------------
int main(int argc, char *argv[])
{
  const QByteArray data ( QByteArray::fromHex ( argv [1] ) );
  const QByteArray sign ( QByteArray::fromHex ( argv [2] ) );
  const QByteArray pubk ( QByteArray::fromHex ( argv [3] ) );

  quint8 tmp [32];
  ::SHA256 ( (const quint8*)data.constData ( ), data.size ( ), tmp );
  quint8 digest [32];
  ::SHA256 ( tmp, 32, digest );
  qDebug ( ) << "data=" << QString ( data.toHex ( ) );
  qDebug ( ) << "sign=" << QString ( sign.toHex ( ) );
  qDebug ( ) << "pubk=" << QString ( pubk.toHex ( ) );

  qDebug ( ) << "digest=" << QString ( QByteArray ( (const char*)digest, 32 ).toHex ( ) );

  const bool v ( ::ECDSA_verify ( 0, digest, 32, (const quint8*)sign.constData ( ), sign.size ( ), EC_KEY_pub_key ( pubk ) ) );
  qDebug ( ) << "result=" << v;

  return 0;
}

```

> **Comments:**
> **username_0**: excellent thanks. its very strange its failing to verify on two of my pcs! i will test it with the rpc client and also with pybitcointools. if the rpc client fails then it must be a problem with a particular version/configuration of openssl...  
> **username_1**: oh, yes! the signature has non-standard der-encoding! Just look to the start of it: 30440220bb... - the proper encoding is 3044022100bb... because R-part can not be negative and starts with "bb". Some OpenSSL versions allow this, some others - not. See http://bitcoin.stackexchange.com/questions/2376/ecdsa-r-s-encoding-as-a-signature  
> **username_1**: to be correct 3045022100bb...  
> **username_0**: no luck with the rpc client - see my updated op :p  
> **username_1**: I have never used rpc for verifying transaction signatures. Seems to me that this call is intended for something else. Drop me a mail to alistermaclin@mail.ru and I will send you Qt/C++ code for checking such things  
> **username_2**: Yes, OpenSSL versions since Jan. 2015 check correct DER in signatures (DSA and RSA as well as ECDSA); that's 0.9.8zd+ 1.0.0p+ 1.0.1k+ and 1.0.2*. http://bitcoin.stackexchange.com/questions/35841/get-latest-blocks-with-bitcoind-on-ubuntu is the same problem.  
> **username_0**: i came accross [bip66](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki) while googling and this addresses the problem.  

---

