<p>The r and s values are prepended with 0x00 if their highest bit is 1 even when they are shorter than 32 bytes. For example, if the r-value is just <code>80</code>, it will be serialized as <code>0080</code>. Additional padding zeros are not allowed, so for example <code>000080</code> would not be valid.</p>
<p>You can find all the rules strict for DER encoding in <a href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki" rel="nofollow noreferrer">BIP66</a>, or in the <a href="https://github.com/bitcoin/bitcoin/blob/v28.0/src/script/interpreter.cpp#L107" rel="nofollow noreferrer">implementation in Bitcoin Core</a>. There's also an online <a href="https://bitcoinutils.dev/der" rel="nofollow noreferrer">DER signature decoder/encoder</a> that I've created which you can use to test if a signature is valid.</p>

CC BY-SA 4.0
2024-11-20T18:47:39.360Z
Great tool, many thanks. So would Bitcoin Core reject the option (2) above which has the extra zeros and would thus consider such signature as invalid even though the integer values (r, s) are correct? Could you provide a link to the Bitcoin Core source code where DER signatures are created and validated?
Crypto L Plate
CC BY-SA 4.0
2024-11-20T19:29:51.210Z
Yes, as I said additional padding zeros are not allowed. I've added links to BIP66 and the implementation in Bitcoin Core.
Vojtěch Strnad
CC BY-SA 4.0
2024-11-20T21:28:11.010Z
Great help, thanks.
Crypto L Plate
CC BY-SA 4.0
2024-11-20T17:37:39.747Z
2024-11-20T19:29:24.873Z
2024-11-20T19:29:24.873Z
Vojtěch Strnad
<p>As described in <a href="https://bitcoin.stackexchange.com/a/77192/117559">this answer</a> to <a href="https://bitcoin.stackexchange.com/q/77191/117559">What is the maximum size of a DER encoded ECDSA signature?</a> the DER encoded signature for a given ECDSA signature (r, s) has format:</p>
<pre><code>0x30 = 1 byte constructed sequence type
L = 1 byte length of the following bytes (excluding SIGHASH byte)
0x02 = 1 byte primitive integer type
LR = 1 byte length of integer r
R = integer r in big endian
0x02 = 1 byte primitive integer type
LS = 1 byte length of integer s
S = integer s in big endian
SIGHASH = 1 byte
</code></pre>
<p>where r is prepended with a byte 0x00 in the case where it has a highest bit of 1, and likewise with s.</p>
<p>However how is the case where r has a byte length less than 32 handled?</p>
<p>Suppose for example we had :</p>
<pre><code>r = 0x83e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2
</code></pre>
<p>which is 30 bytes.</p>
<p>Do we</p>
<p>(1) prepend this with 0x00 because of the highest bit (ie. bit 239) being 1, so we put :</p>
<pre><code>0x0083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2
</code></pre>
<p>in the R field above, or :</p>
<p>(2) write it in full 32 byte format :</p>
<pre><code>0x000083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2
</code></pre>
<p>and therefore do not prepend it with 0x00 because the highest bit (ie. bit 255) is zero, so we put :</p>
<pre><code>0x000083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2
</code></pre>
<p>in the R field above?</p>
<p>Can anyone point to any example blockchain transactions illustrating how these shorter r, s values are handled?</p>
<p>Is there any possibility of malleability here, ie. both options (1) and (2) are accepted by Bitcoin Core, assuming (r, s) is a valid signature?</p>
<p>Or are leading zero bytes always stripped away from r and s before considering whether their highest bit is 1 (noting zero is not a permissible value for r or s)?</p>

CC BY-SA 4.0
2024-11-21T13:28:34.633Z
One example on the blockchain with s at 28 bytes long is TxId = [3419cbc51cec42d4f55d4147d0c1cef54fbdabddf4384270e6e93970b2496f74](https://mempool.space/tx/3419cbc51cec42d4f55d4147d0c1cef54fbdabddf4384270e6e93970b2496f74), also described [here](https://blog.eternitywall.com/2017/12/12/shortest-transaction/).
Crypto L Plate
<signature><ecdsa><input-script>
Effect of byte length of r and s on DER encoded signature
Crypto L Plate
# Effect of byte length of r and s on DER encoded signature

(Asked by: username_0 on 2024-11-20)

As described in [this answer](https://bitcoin.stackexchange.com/a/77192/117559) to [What is the maximum size of a DER encoded ECDSA signature?](https://bitcoin.stackexchange.com/q/77191/117559) the DER encoded signature for a given ECDSA signature (r, s) has format:

```
0x30 = 1 byte constructed sequence type
L = 1 byte length of the following bytes (excluding SIGHASH byte)
0x02 = 1 byte primitive integer type
LR = 1 byte length of integer r
R = integer r in big endian
0x02 = 1 byte primitive integer type
LS = 1 byte length of integer s
S = integer s in big endian
SIGHASH = 1 byte

```

where r is prepended with a byte 0x00 in the case where it has a highest bit of 1, and likewise with s.

However how is the case where r has a byte length less than 32 handled?

Suppose for example we had :

```
r = 0x83e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2

```

which is 30 bytes.

Do we

(1) prepend this with 0x00 because of the highest bit (ie. bit 239) being 1, so we put :

```
0x0083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2

```

in the R field above, or :

(2) write it in full 32 byte format :

```
0x000083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2

```

and therefore do not prepend it with 0x00 because the highest bit (ie. bit 255) is zero, so we put :

```
0x000083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2

```

in the R field above?

Can anyone point to any example blockchain transactions illustrating how these shorter r, s values are handled?

Is there any possibility of malleability here, ie. both options (1) and (2) are accepted by Bitcoin Core, assuming (r, s) is a valid signature?

Or are leading zero bytes always stripped away from r and s before considering whether their highest bit is 1 (noting zero is not a permissible value for r or s)?

**Tags:** signature, ecdsa, input-script

> **Comments:**
> **username_0**: One example on the blockchain with s at 28 bytes long is TxId = [3419cbc51cec42d4f55d4147d0c1cef54fbdabddf4384270e6e93970b2496f74](https://mempool.space/tx/3419cbc51cec42d4f55d4147d0c1cef54fbdabddf4384270e6e93970b2496f74), also described [here](https://blog.eternitywall.com/2017/12/12/shortest-transaction/).  

---

## 1 answers

### Answer by username_1 on 2024-11-20. Score: 3 | Accepted answer

The r and s values are prepended with 0x00 if their highest bit is 1 even when they are shorter than 32 bytes. For example, if the r-value is just `80`, it will be serialized as `0080`. Additional padding zeros are not allowed, so for example `000080` would not be valid.

You can find all the rules strict for DER encoding in [BIP66](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki), or in the [implementation in Bitcoin Core](https://github.com/bitcoin/bitcoin/blob/v28.0/src/script/interpreter.cpp#L107). There's also an online [DER signature decoder/encoder](https://bitcoinutils.dev/der) that I've created which you can use to test if a signature is valid.

> **Comments:**
> **username_0**: Great tool, many thanks. So would Bitcoin Core reject the option (2) above which has the extra zeros and would thus consider such signature as invalid even though the integer values (r, s) are correct? Could you provide a link to the Bitcoin Core source code where DER signatures are created and validated?  
> **username_1**: Yes, as I said additional padding zeros are not allowed. I've added links to BIP66 and the implementation in Bitcoin Core.  
> **username_0**: Great help, thanks.  

---

