# ECDSA r, s encoding as a signature

An ECDSA algorithm when signing a given messages produces a pair of outputs, r and s. 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?

If you want, you can pay \$100 for the standard, ANSI X9.62. Or, you can cheat and look at 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 you can see that one of the signatures is:

3045 0220
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)
``````
• 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 - stackoverflow.com/questions/8693513/… Jan 3, 2012 at 19:21
• I actually have no idea what that 01 is doing there. I'll try to find out and update my answer. Jan 3, 2012 at 20:17
• 01 is SIGHASH_ALL, used by OP_CHECKSIG to decide how to hash the transaction that is being signed. Jan 8, 2012 at 0:58

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