<p>A possible reason is that Bitcoin Core expects a low S value. Try changing s with N-s if s > N/2 (N is the curve order).</p>

<p>Source <a href="https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki#low-s-values-in-signatures" rel="nofollow noreferrer">here</a></p>

CC BY-SA 4.0
2018-10-18T11:39:29.243Z
Actually that was not my initial issue, that's a completely different error code which I am getting now (`SCRIPT_ERR_SIG_HIGH_S`) after prepending my faulty S value with an 0x00 byte (I read in some other thread that should be done if the initial S's first byte is >= 128). So yeah most likely what I have to do now is what you suggested
Tedy S.
CC BY-SA 4.0
2018-10-18T11:19:31.800Z
2018-10-18T11:19:31.800Z
Mike D
<p>The following python code can create a valid DER encoded signature given <code>r</code> and <code>s</code> as byte objects:</p>

<pre><code>def ser_sig_der(r, s):
    sig = b"\x30"

    # Make r and s as short as possible
    ri = 0
    for b in r:
        if b == "\x00":
            ri += 1
        else:
            break
    r = r[ri:]
    si = 0
    for b in s:
        if b == "\x00":
            si += 1
        else:
            break;
    s = s[si:]

    # Make positive of neg
    first = r[0]
    if first &amp; (1 &lt;&lt; 7) != 0:
        r = b"\x00" + r
    first = s[0]
    if first &amp; (1 &lt;&lt; 7) != 0:
        s = b"\x00" + s

    # Write total length
    total_len = len(r) + len(s) + 4
    sig += struct.pack("B", total_len)

    # write r
    sig += b"\x02"
    sig += struct.pack("B", len(r))
    sig += r

    # write s
    sig += b"\x02"
    sig += struct.pack("B", len(s))
    sig += s
    return sig
</code></pre>

<p>It is important to note that signatures in Bitcoin also contain an extra byte appended to the DER encoded signature which represents the sighash type. You will need to add that byte yourself.</p>

CC BY-SA 4.0
2018-10-18T14:07:06.140Z
2018-10-18T14:07:06.140Z
Ava Chow
<p>The third byte encodes information about the content length.
If content length is less than 127 bytes third byte is equal to content length.
If it is greater than 127 and less than 255, the third byte is 0x81.
If it is greater than 255, the third byte is 0x82.</p>
<p>The next byte(s) indicates the content length.</p>
<p>Reference:
<a href="https://github.com/openssl/openssl/blob/master/crypto/asn1_dsa.c" rel="nofollow noreferrer">https://github.com/openssl/openssl/blob/master/crypto/asn1_dsa.c</a>  encode_der_length
<a href="https://www.itu.int/rec/T-REC-X.690-201508-I/en" rel="nofollow noreferrer">https://www.itu.int/rec/T-REC-X.690-201508-I/en</a></p>

CC BY-SA 4.0
2020-09-04T05:18:59.540Z
Although bitcoin signatures use secp256k1, and low-S as MikeD noted, so all of the value parts never exceed 69 bytes and your second and third cases of length encoding never occur. (The third case actually is >=256 and <65536; for longer than that, there are more length encodings you don't mention, but they aren't supported or needed by the code you link.)
dave_thompson_085
CC BY-SA 4.0
2020-09-03T11:35:35.780Z
2020-09-03T11:35:35.780Z
gari
<p>I am writing transactions manually and have stumbled across a rather bizarre situation.</p>

<p>Only one in a few of the transactions I broadcast to bitcoind is accepted, otherwise I get a <code>REJECT_NONSTANDARD</code> (Non-canonical DER signature).</p>

<p>So I got my hands dirty and tracked the rejection to be originating from this line: <a href="https://github.com/bitcoin/bitcoin/blob/9c5f0d542d1db507b3b9c87bd9de6d0d758d51c1/src/script/interpreter.cpp#L163" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/9c5f0d542d1db507b3b9c87bd9de6d0d758d51c1/src/script/interpreter.cpp#L163</a></p>

<p>I read about DER encoding and checked how <code>IsValidSignatureEncoding</code> is enforcing it, but I do not know why OpenSSL generates not-DER-compliant (r, s) values?</p>

<p>How should I overcome this? I am thinking of something along the lines of (pseudocode):</p>

<pre><code>Pair (r, s);
do
{
   (r, s) = sign(hash, pvtkey);
} while (r[0] &gt;= 128 || s[0] &gt;= 128); // where r[0], s[0] should be the very first byte of each value
</code></pre>

<p>But isn't that kind of redundant? Can I give OpenSSL any flag to produce a valid DER (R, S) pair in the first place?</p>

CC BY-SA 4.0
2018-11-18T17:56:06.577Z
Are you using OpenSSL to encode the DER or did you write your own DER encoding function? It's very easy to end up with a function that is only correct for some inputs.
G. Maxwell
<transactions><bitcoind><ecdsa><source-code><openssl>
Bitcoind does not like ECDSA (r, s) pair produced by OpenSSL
Tedy S.
# Bitcoind does not like ECDSA (r, s) pair produced by OpenSSL

(Asked by: username_0 on 2018-10-18)

I am writing transactions manually and have stumbled across a rather bizarre situation.
Only one in a few of the transactions I broadcast to bitcoind is accepted, otherwise I get a REJECT_NONSTANDARD (Non-canonical DER signature).
So I got my hands dirty and tracked the rejection to be originating from this line: https://github.com/bitcoin/bitcoin/blob/9c5f0d542d1db507b3b9c87bd9de6d0d758d51c1/src/script/interpreter.cpp#L163
I read about DER encoding and checked how IsValidSignatureEncoding is enforcing it, but I do not know why OpenSSL generates not-DER-compliant (r, s) values?
How should I overcome this? I am thinking of something along the lines of (pseudocode):
Pair (r, s);
do
{
   (r, s) = sign(hash, pvtkey);
} while (r[0] >= 128 || s[0] >= 128); // where r[0], s[0] should be the very first byte of each value

But isn't that kind of redundant? Can I give OpenSSL any flag to produce a valid DER (R, S) pair in the first place?

**Tags:** transactions, bitcoind, ecdsa, source-code, openssl

> **Comments:**
> **username_1**: Are you using OpenSSL to encode the DER or did you write your own DER encoding function? It's very easy to end up with a function that is only correct for some inputs.  

---

## 3 answers

### Answer by username_2 on 2018-10-18. Score: 2

A possible reason is that Bitcoin Core expects a low S value. Try changing s with N-s if s > N/2 (N is the curve order).

Source [here](https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki#low-s-values-in-signatures)

> **Comments:**
> **username_0**: Actually that was not my initial issue, that's a completely different error code which I am getting now (`SCRIPT_ERR_SIG_HIGH_S`) after prepending my faulty S value with an 0x00 byte (I read in some other thread that should be done if the initial S's first byte is >= 128). So yeah most likely what I have to do now is what you suggested  

---

### Answer by username_3 on 2018-10-18. Score: 0

The following python code can create a valid DER encoded signature given r and s as byte objects:
def ser_sig_der(r, s):
    sig = b"\x30"

    # Make r and s as short as possible
    ri = 0
    for b in r:
        if b == "\x00":
            ri += 1
        else:
            break
    r = r[ri:]
    si = 0
    for b in s:
        if b == "\x00":
            si += 1
        else:
            break;
    s = s[si:]

    # Make positive of neg
    first = r[0]
    if first & (1 << 7) != 0:
        r = b"\x00" + r
    first = s[0]
    if first & (1 << 7) != 0:
        s = b"\x00" + s

    # Write total length
    total_len = len(r) + len(s) + 4
    sig += struct.pack("B", total_len)

    # write r
    sig += b"\x02"
    sig += struct.pack("B", len(r))
    sig += r

    # write s
    sig += b"\x02"
    sig += struct.pack("B", len(s))
    sig += s
    return sig

It is important to note that signatures in Bitcoin also contain an extra byte appended to the DER encoded signature which represents the sighash type. You will need to add that byte yourself.


---

### Answer by username_4 on 2020-09-03. Score: 0

The third byte encodes information about the content length.
If content length is less than 127 bytes third byte is equal to content length.
If it is greater than 127 and less than 255, the third byte is 0x81.
If it is greater than 255, the third byte is 0x82.

The next byte(s) indicates the content length.

Reference:
<https://github.com/openssl/openssl/blob/master/crypto/asn1_dsa.c> encode\_der\_length
<https://www.itu.int/rec/T-REC-X.690-201508-I/en>

> **Comments:**
> **username_5**: Although bitcoin signatures use secp256k1, and low-S as MikeD noted, so all of the value parts never exceed 69 bytes and your second and third cases of length encoding never occur. (The third case actually is >=256 and <65536; for longer than that, there are more length encodings you don't mention, but they aren't supported or needed by the code you link.)  

---

