<p>If the first byte is greater than or equal to 0x80 (128), then you need to add a leading zero byte. You can do 0x80 &amp; first_byte. If the result is zero, no padding is needed.</p>

CC BY-SA 3.0
2018-03-10T08:02:56.857Z
2018-03-10T08:02:56.857Z
ManfredMacx
<p>There are unsigned and signed numbers. R + S values are obviously interpreted as signed numbers, and when the first bit of the number is high, then you have a number, which is interpreted as negative. So all signatures' S and R values beginning with "more than 7F" </p>

<p>Pieter explained it <a href="http://bitcoin-development.narkive.com/OOU2XVSG/bitcoin-development-who-is-creating-non-der-signatures" rel="nofollow noreferrer">here</a>:
extract:</p>

<ul>
<li>R and S are signed integers, encoded as a big-endian byte sequence.
They are stored in as few bytes as possible (i.e., no 0x00 padding in
front), except that a single 0x00 byte is needed and even required
when the byte following it has its highest bit set, to prevent it
from being interpreted as a negative number.</li>
</ul>

CC BY-SA 3.0
2018-03-10T06:49:48.637Z
2018-03-10T06:49:48.637Z
pebwindkraft
<p>Supposedly, if an R or S value will equal a "negative" number, one must append zeros to it and alter the "length" descriptor for the value to reflect that.  When manually creating a raw tx how does one determine whether one's R and or S values require the addition of these extra byte(s)?  All conversions I do with a hex calculator always show positive numbers.</p>

<transactions><signature><raw-transaction>
When manually creating a raw bitcoin tx, how does one determine whether the r or s values require more zeros?
Mine
# When manually creating a raw bitcoin tx, how does one determine whether the r or s values require more zeros?

(Asked by: username_0 on 2018-03-09)

Supposedly, if an R or S value will equal a "negative" number, one must append zeros to it and alter the "length" descriptor for the value to reflect that. When manually creating a raw tx how does one determine whether one's R and or S values require the addition of these extra byte(s)? All conversions I do with a hex calculator always show positive numbers.

**Tags:** transactions, signature, raw-transaction


---

## 2 answers

### Answer by username_1 on 2018-03-10. Score: 2

If the first byte is greater than or equal to 0x80 (128), then you need to add a leading zero byte. You can do 0x80 & first\_byte. If the result is zero, no padding is needed.


---

### Answer by username_2 on 2018-03-10. Score: 1

There are unsigned and signed numbers. R + S values are obviously interpreted as signed numbers, and when the first bit of the number is high, then you have a number, which is interpreted as negative. So all signatures' S and R values beginning with "more than 7F"

Pieter explained it [here](http://bitcoin-development.narkive.com/OOU2XVSG/bitcoin-development-who-is-creating-non-der-signatures):
extract:

* R and S are signed integers, encoded as a big-endian byte sequence.
  They are stored in as few bytes as possible (i.e., no 0x00 padding in
  front), except that a single 0x00 byte is needed and even required
  when the byte following it has its highest bit set, to prevent it
  from being interpreted as a negative number.


---

