A signature created by the Bitcoin-Qt client can always be decoded (base64) to a 65-byte array. This array seems (according to https://github.com/bitcoin/bitcoin/blob/master/src/key.cpp#L217) to contain a header byte, a 32-byte R part, and a 32-byte S part.

I've extracted some (R,S) pairs from some ECDSA Signatures encoded in the DER format. I found that R and S are not necessarily of 32 bytes in size. They sometimes can be 33 bytes long. Could anyone tell me why the signature created by the Qt client is always 65 bytes, or whether it is OK to always convert both R and S into a 32-byte array? Thanks.

1 Answer 1


There are two different encodings used.

Everything in the Bitcoin protocol, including transaction signatures and alert signatures, uses DER encoding. This results in 71 bytes signatures (on average), as there are several header bytes, and the R and S valued are variable length.

For message signatures, a custom encoding is used which is more compact (and more recent) and supports public key recovery (given a message and a signature, find which public key would have created it). The code you're referring to in the question is for creating such signatures.

A correct DER-encoded signature has the following form:

  • 0x30: a header byte indicating a compound structure.
  • A 1-byte length descriptor for all what follows.
  • 0x02: a header byte indicating an integer.
  • A 1-byte length descriptor for the R value
  • The R coordinate, as a big-endian integer.
  • 0x02: a header byte indicating an integer.
  • A 1-byte length descriptor for the S value.
  • The S coordinate, as a big-endian integer.

Where initial 0x00 bytes for R and S are not allowed, except when their first byte would otherwise be above 0x7F (in which case a single 0x00 in front is required). Also note that inside transaction signatures, an extra hashtype byte follows the actual signature data.

  • 1
    Thank you, Pieter! Now I understand why we can safely ignore the first byte in the 33 bytes cases.
    – Ning
    Aug 7, 2013 at 1:15
  • Why are values above 0x7F in the first byte of R or S not allowed? Maybe something to do with DER? The signatures that are printing for me seem to have the 0x00 out in front of the R, S about 50% of the time, disjointly.
    – morsecoder
    Oct 29, 2014 at 1:29
  • 2
    @StephenM347 If the first byte has its highest bit set (>0x7F), BER (of which DER is a specialization of) says that it is to be interpreted as a negative number. OpenSSL, knowing that signatures only contain positive numbers, ignores this, but this violates the specification. As of v0.8.0, Bitcoin Core requires strict adherence to DER for signatures, although anything that OpenSSL accepts is valid in the blockchain for now (although BIP62 proposes making it a network rule to require strict DER). Oct 30, 2014 at 3:49
  • Great, thanks. Sort of wish Satoshi had just used data pushes for R and S on the stack rather than this whole DER thing, but what can you do! :)
    – morsecoder
    Oct 30, 2014 at 3:51
  • Can you expand more on the custom format? I am trying to recreate the QT signing process. However, C++ is far beyond my understanding.
    – Jus12
    Dec 20, 2017 at 17:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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