Take the 2-minute tour ×
Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It's 100% free, no registration required.

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?

share|improve this question

1 Answer 1

up vote 4 down vote accepted

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

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:

share|improve this answer
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/… –  ThePiachu Jan 3 '12 at 19:21
I actually have no idea what that 01 is doing there. I'll try to find out and update my answer. –  David Schwartz Jan 3 '12 at 20:17
01 is SIGHASH_ALL, used by OP_CHECKSIG to decide how to hash the transaction that is being signed. –  gavinandresen Jan 8 '12 at 0:58

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.