<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. the transaction is the first instance of a SIGHASH_NONE in the live blockchain. 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 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'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 check and be rejected ever since bip66. 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 
#include 

#include 
#include 
#include 
#include 

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.  

---

