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.

up vote 29 down vote accepted

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 '13 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. – StephenM347 Oct 29 '14 at 1:29
  • @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). – Pieter Wuille Oct 30 '14 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! :) – StephenM347 Oct 30 '14 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 '17 at 17:12

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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