3

I'm reading the Master Bitcoin book and I'm a bit confused. The confusion is related to the length of the extended keys.

The book says that extended keys are 512 or 513 bits long. It is clear to me that the length of the extended private key is 512 bits (chain code (256 bits) || private key (256 bits)). Confusion arises in the length of the extended public key. In the book they say that it is 513 bits. How is it possible? Isn't it 520 bits (chain code (256 bits) || public key (264 bits = 0x02/0x03 || X coordinate))?

I found a similar question already asked (link), but the answer by miketery confused me a bit. He said the following:

The book says 512 or 513 bits because the extended private key is 256 chain code bits || 256 private key bits (512), and the extended public key is 256 chain code bits || 1 evenness bit || 256 public key bits (513).

Since computers storage works in bytes, the 1 bit for evenness is represented as a whole byte.

How can this be true when evenness is defined by setting 0x02 or 0x03 so it has to be more than just one bit (at least 2 bits). So it would make more sense to me, if not say 520 bits, then at least say 514 bits?

Improve this question
1
  • 2
    0x02 and 0x03 are only two values, so nothing prevents you from encoding them as 0x00 and 0x01 - single bit is sufficient. In practice you'll need a whole byte anyway just to store it somehow, unless you want to store a collection of such keys and can afford bit manipulation (e.g. 8 keys can be stored as three entities - array of 8 32-byte sequences, 1 byte with every bit encoding the parity of one key, and 8x32 again).
    – SUTerliakov
    Apr 9 at 11:01

1 Answer 1

Reset to default
3

If it says 513 bits it's referring to the fact that you need at least 513 bits of data to convey the information in an extended public: 256 bits of the chaincode, 256 bits of the X coordinate of the public key, and 1 bit to convey whether or not the Y coordinate is even or odd.

However, it's not true that extended public keys are in practice encoded using just 513 bits. In fact, it's not 520 bits either. The way to encode extended public keys is defined in BIP32; the "xpub" encoding format, which also contains information like a 32-bit fingerprint of the parent, and the depth in the tree.

Improve this answer
2
  • First of all, thanks for the reply. I know they are represented via the "xpub" base58check encoding system, but I'm interested now in this "raw representation". So we can say that an extended public key requires 513 bits: 256 bits of chain code || 1 bit to determine parity (eg 1 for even, 0 for odd) || 256 bits of the X coordinate. However, in practice two rather than one parity bit would be required to set 0x02 or 0x03, so a total of 514 bits would be required. As computers look at everything at the byte level, that would be 520 bits. Am I right?
    – Filip
    Apr 9 at 1:35
  • 1
    0x02 or 0x03 are bytes; if you're talking about byte encodings then you need 65 bytes, which can also store 520 bits. If you're talking about bit-legel encodings, 513 suffices.
    – Pieter Wuille
    Apr 9 at 11:35

Your Answer

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

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