<p>R and S are visible in each of the tx inputs.
You can see them already extracted on this site. I also provide the Z value.</p>
<p><a href="https://2xoin.com/tx/711b6457b4b2b51e56b94ab541a75d02908648a9de26a3c0ce5b2c3b10573d4e" rel="nofollow noreferrer">https://2xoin.com/tx/711b6457b4b2b51e56b94ab541a75d02908648a9de26a3c0ce5b2c3b10573d4e</a></p>
<p>See the bitcoin protocol specification for more info about the byte order.
<a href="https://en.bitcoin.it/wiki/Protocol_specification#tx" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Protocol_specification#tx</a></p>
<p>Below is an example of a TX input hex,</p>
<blockquote>
<p>4830450220657912a72d3ac8169fe8eaecd5ab401c94fc9981717e3e6dd4971889f785790c022100ed3bf3456eb76677fd899c8ccd1cc6d1ebc631b94c42f7c4578f28590d651c6e0141049b5506df53ff5eff7dc553131043bb993f55d2b0fddd866984f593777023c8226920ff05747ccb963f0fe459cb217d502e57dcf8afec786c3dcee4d1558f85fa</p>
</blockquote>
<p>Now separated to make it easier to read,</p>
<blockquote>
<p>48</p>
</blockquote>
<blockquote>
<p>3045</p>
</blockquote>
<blockquote>
<p>0220
(The Hex 20 says the next 32 bytes are the R value)</p>
</blockquote>
<blockquote>
<p>657912a72d3ac8169fe8eaecd5ab401c94fc9981717e3e6dd4971889f785790c</p>
</blockquote>
<blockquote>
<p>0221 (The hex 21 says the next 33 bytes are the S value)</p>
</blockquote>
<blockquote>
<p>00ed3bf3456eb76677fd899c8ccd1cc6d1ebc631b94c42f7c4578f28590d651c6e</p>
</blockquote>
<blockquote>
<p>0141 (The hex 41 says the next 65 bytes are the public key)</p>
</blockquote>
<blockquote>
<p>049b5506df53ff5eff7dc553131043bb993f55d2b0fddd866984f593777023c8226920ff05747ccb963f0fe459cb217d502e57dcf8afec786c3dcee4d1558f85fa</p>
</blockquote>

CC BY-SA 4.0
2014-12-15T07:59:12.550Z
2020-12-27T15:45:28.180Z
2020-12-27T15:45:28.180Z
Sean Bradley
<p>If you want, you can pay $100 for the standard, <a href="http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.62:2005" rel="nofollow noreferrer">ANSI X9.62</a>. Or, you can cheat and look at <a href="https://www.rfc-editor.org/rfc/rfc3278#section-8.2" rel="nofollow noreferrer">RFC3278, section 8.2</a>. It is in DER format consisting of a SEQUENCE of two INTEGERs. The first INTEGER is <code>r</code>, the second <code>s</code>.</p>
<p>If you look at <a href="http://blockexplorer.com/rawtx/d2b04f28dfe36bbd7f6228519725f4560b6d7eef0eb9c1b1d4c718f2ba4548f5" rel="nofollow noreferrer">this transaction</a> you can see that one of the signatures is:</p>
<blockquote>
<p>3045 0220<br>
316eb3cad8b66fcf1494a6e6f9542c3555addbf337f04b62bf4758483fdc881d<br>
022100<br>
bf46d26cef45d998a2cb5d2d0b8342d70973fa7c3c37ae72234696524b2bc812<br>
01</p>
</blockquote>
<p>If we parse that as DER, we get:</p>
<pre><code> 0:d=0  hl=2 l= 69 cons: SEQUENCE          
 2:d=1  hl=2 l= 32 prim: INTEGER :316EB3CAD8B66FCF1494A6E6F9542C3555ADDBF337F04B62BF4758483FDC881D
36:d=1  hl=2 l= 33 prim: INTEGER :BF46D26CEF45D998A2CB5D2D0B8342D70973FA7C3C37AE72234696524B2BC812
</code></pre>
<p>You can also peek at the OpenSSL source code, file <code>ecdsa/ecs_asn1.c</code>:</p>
<pre><code>ASN1_SEQUENCE(ECDSA_SIG) = {
        ASN1_SIMPLE(ECDSA_SIG, r, CBIGNUM),
        ASN1_SIMPLE(ECDSA_SIG, s, CBIGNUM)
} ASN1_SEQUENCE_END(ECDSA_SIG)
</code></pre>

CC BY-SA 3.0
2012-01-03T19:21:35.220Z
Hmm, I managed to encode and decode the two integers, but my encoding seems to be missing the 01 byte at the end. Any ideas why that might be so? I used the code form here - http://stackoverflow.com/questions/8693513/go-der-and-handling-big-integers/8708864#8708864
ThePiachu
CC BY-SA 3.0
2012-01-03T20:17:29.517Z
I actually have no idea what that 01 is doing there. I'll try to find out and update my answer.
David Schwartz
CC BY-SA 3.0
2012-01-08T00:58:58.230Z
01 is SIGHASH_ALL, used by OP_CHECKSIG to decide how to hash the transaction that is being signed.
gavinandresen
CC BY-SA 3.0
2012-01-01T07:22:14.793Z
2012-01-01T08:56:39.790Z
2021-10-07T07:05:27.390Z
David Schwartz
<p><a href="http://en.wikipedia.org/wiki/Elliptic_Curve_DSA">An ECDSA algorithm</a> when signing a given messages produces a pair of outputs, <a href="http://en.wikipedia.org/wiki/Elliptic_Curve_DSA#Signature_generation_algorithm">r and s</a>. How, given a sigStr from a Tx can one extract r and s? Are they just concatenated byte arrays of a specific length, or is there more to it?</p>

<transactions><protocol><signature><ecdsa>
ECDSA r, s encoding as a signature
ThePiachu
# ECDSA r, s encoding as a signature

(Asked by: username_0 on 2012-01-01)

[An ECDSA algorithm](http://en.wikipedia.org/wiki/Elliptic_Curve_DSA) when signing a given messages produces a pair of outputs, [r and s](http://en.wikipedia.org/wiki/Elliptic_Curve_DSA#Signature_generation_algorithm). How, given a sigStr from a Tx can one extract r and s? Are they just concatenated byte arrays of a specific length, or is there more to it?

**Tags:** transactions, protocol, signature, ecdsa


---

## 2 answers

### Answer by username_2 on 2012-01-01. Score: 20 | Accepted answer

If you want, you can pay $100 for the standard, [ANSI X9.62](http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.62:2005). Or, you can cheat and look at [RFC3278, section 8.2](https://www.rfc-editor.org/rfc/rfc3278#section-8.2). It is in DER format consisting of a SEQUENCE of two INTEGERs. The first INTEGER is `r`, the second `s`.

If you look at [this transaction](http://blockexplorer.com/rawtx/d2b04f28dfe36bbd7f6228519725f4560b6d7eef0eb9c1b1d4c718f2ba4548f5) you can see that one of the signatures is:

> 3045 0220  
> 316eb3cad8b66fcf1494a6e6f9542c3555addbf337f04b62bf4758483fdc881d  
> 022100  
> bf46d26cef45d998a2cb5d2d0b8342d70973fa7c3c37ae72234696524b2bc812  
> 01

If we parse that as DER, we get:

```
 0:d=0  hl=2 l= 69 cons: SEQUENCE          
 2:d=1  hl=2 l= 32 prim: INTEGER :316EB3CAD8B66FCF1494A6E6F9542C3555ADDBF337F04B62BF4758483FDC881D
36:d=1  hl=2 l= 33 prim: INTEGER :BF46D26CEF45D998A2CB5D2D0B8342D70973FA7C3C37AE72234696524B2BC812

```

You can also peek at the OpenSSL source code, file `ecdsa/ecs_asn1.c`:

```
ASN1_SEQUENCE(ECDSA_SIG) = {
        ASN1_SIMPLE(ECDSA_SIG, r, CBIGNUM),
        ASN1_SIMPLE(ECDSA_SIG, s, CBIGNUM)
} ASN1_SEQUENCE_END(ECDSA_SIG)

```

> **Comments:**
> **username_0**: Hmm, I managed to encode and decode the two integers, but my encoding seems to be missing the 01 byte at the end. Any ideas why that might be so? I used the code form here - http://stackoverflow.com/questions/8693513/go-der-and-handling-big-integers/8708864#8708864  
> **username_2**: I actually have no idea what that 01 is doing there. I'll try to find out and update my answer.  
> **username_3**: 01 is SIGHASH_ALL, used by OP_CHECKSIG to decide how to hash the transaction that is being signed.  

---

### Answer by username_1 on 2014-12-15. Score: 3

R and S are visible in each of the tx inputs.
You can see them already extracted on this site. I also provide the Z value.

<https://2xoin.com/tx/711b6457b4b2b51e56b94ab541a75d02908648a9de26a3c0ce5b2c3b10573d4e>

See the bitcoin protocol specification for more info about the byte order.
<https://en.bitcoin.it/wiki/Protocol_specification#tx>

Below is an example of a TX input hex,

> 4830450220657912a72d3ac8169fe8eaecd5ab401c94fc9981717e3e6dd4971889f785790c022100ed3bf3456eb76677fd899c8ccd1cc6d1ebc631b94c42f7c4578f28590d651c6e0141049b5506df53ff5eff7dc553131043bb993f55d2b0fddd866984f593777023c8226920ff05747ccb963f0fe459cb217d502e57dcf8afec786c3dcee4d1558f85fa

Now separated to make it easier to read,

> 48

> 3045

> 0220
> (The Hex 20 says the next 32 bytes are the R value)

> 657912a72d3ac8169fe8eaecd5ab401c94fc9981717e3e6dd4971889f785790c

> 0221 (The hex 21 says the next 33 bytes are the S value)

> 00ed3bf3456eb76677fd899c8ccd1cc6d1ebc631b94c42f7c4578f28590d651c6e

> 0141 (The hex 41 says the next 65 bytes are the public key)

> 049b5506df53ff5eff7dc553131043bb993f55d2b0fddd866984f593777023c8226920ff05747ccb963f0fe459cb217d502e57dcf8afec786c3dcee4d1558f85fa


---

