<p>The extended public key contains just a bit more information than the public key and chaincode, but the public key and chaincode are all that matter for key derivation. The rest is just metadata about the keys for wallets and people.</p>

<p>The version bytes distinguish between xpub, xpriv, and other types of keys. The fingerprint identifies the parent so that a wallet can know what the parent of this key is. The child index tells a wallet how to derive this key again from the parent.</p>

<blockquote>
  <p>I'm unfamiliar with what comprises the extended private key. </p>
</blockquote>

<p>The extended private key is exactly the same as the extended public key but instead of 33 bytes of public key data, it's 33 bytes of private key data.</p>

<blockquote>
  <p>the network has an effect on this as well, which doesn't make sense to me either but clearly (as shown above) it is a part of this formula.</p>
</blockquote>

<p>The network determines the version bytes. These version bytes are present in everything else in Bitcoin and is only to indicate to the user what network the key is used for. This is useful in identifying whether a key may be compromised (because e.g. it has been used for testing software)</p>

<blockquote>
  <p>Can someone deconstruct an extended key from beginning to end?</p>
</blockquote>

<p>Let's use <code>xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw</code> as our xpub.</p>

<p>Base58 decoding this gives us </p>

<pre><code>0488B21E013442193E8000000047FDACBD0F1097043B78C63C20C34EF4ED9A111D980047AD16282C7AE6236141035A784662A4A20A65BF6AAB9AE98A6C068A81C52E4B032C0FB5400C706CFCCC56B8B9C580
</code></pre>

<p><code>0488B21E</code> are the version bytes as defined by BIP 32.</p>

<p><code>01</code> means that this key as at depth one</p>

<p><code>3442193E</code> is the fingerprint of the parent key</p>

<p><code>80000000</code> means that the key is index 0h (0'th hardened key)</p>

<p><code>47FDACBD0F1097043B78C63C20C34EF4ED9A111D980047AD16282C7AE6236141</code> is the chaincode</p>

<p><code>035A784662A4A20A65BF6AAB9AE98A6C068A81C52E4B032C0FB5400C706CFCCC56</code> is the public key</p>

<p><code>B8B9C580</code> is the base58 check encoding checksum.</p>

CC BY-SA 4.0
2018-08-16T20:04:15.583Z
2018-08-16T20:04:15.583Z
Ava Chow
<p>I was under the impression that an extended public key was comprised of the public key + chain code, and I'm unfamiliar with what comprises the extended private key. </p>

<p>However this does not seem to be the case. As per <a href="https://github.com/ranaroussi/pywallet/blob/eb784ea4dd62fe2a50e1352e7d24438fc66a4ac0/pywallet/utils/bip32.py#L502" rel="noreferrer">pywallet</a>:</p>

<pre><code>The key consists of
            * 4 byte version bytes (network key)
            * 1 byte depth:
                - 0x00 for master nodes,
                - 0x01 for level-1 descendants, ....
            * 4 byte fingerprint of the parent's key (0x00000000 if master key)
            * 4 byte child number. This is the number i in x_i = x_{par}/i,
              with x_i the key being serialized. This is encoded in MSB order.
              (0x00000000 if master key)
            * 32 bytes: the chain code
            * 33 bytes: the public key or private key data
              (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)
              (Note that this also supports 0x04 + X + Y uncompressed points,
              but this is totally non-standard and this library won't even
              generate such data.)
</code></pre>

<p>It isn't so straight forward as publickey + chaincode. Can someone deconstruct an extended key from beginning to end? According to <a href="https://iancoleman.io/bip39/" rel="noreferrer">the amazing iancoleman website</a> the network has an effect on this as well, which doesn't make sense to me either but clearly (as shown above) it is a part of this formula.</p>

CC BY-SA 4.0
2018-08-16T19:35:50.443Z
The network bytes are a human-safety feature, they do not impact key derivation. They are mainly to identify which network a program should be checking, if it is given an extended key
Raghav Sood
CC BY-SA 4.0
2018-08-16T19:40:01.937Z
So only the public or private key + chaincode impact key derivation? Are the rest just identifiers?  What about the extended pub/priv key at root, before cointype? The wallet may have multiple coins underneath. Should that data simply not be included?
arshbot
<wallet><private-key><public-key><xpub>
What makes an extended public or private key?
arshbot
# What makes an extended public or private key?

(Asked by: username_0 on 2018-08-16)

I was under the impression that an extended public key was comprised of the public key + chain code, and I'm unfamiliar with what comprises the extended private key.

However this does not seem to be the case. As per [pywallet](https://github.com/ranaroussi/pywallet/blob/eb784ea4dd62fe2a50e1352e7d24438fc66a4ac0/pywallet/utils/bip32.py#L502):

```
The key consists of
            * 4 byte version bytes (network key)
            * 1 byte depth:
                - 0x00 for master nodes,
                - 0x01 for level-1 descendants, ....
            * 4 byte fingerprint of the parent's key (0x00000000 if master key)
            * 4 byte child number. This is the number i in x_i = x_{par}/i,
              with x_i the key being serialized. This is encoded in MSB order.
              (0x00000000 if master key)
            * 32 bytes: the chain code
            * 33 bytes: the public key or private key data
              (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)
              (Note that this also supports 0x04 + X + Y uncompressed points,
              but this is totally non-standard and this library won't even
              generate such data.)

```

It isn't so straight forward as publickey + chaincode. Can someone deconstruct an extended key from beginning to end? According to [the amazing iancoleman website](https://iancoleman.io/bip39/) the network has an effect on this as well, which doesn't make sense to me either but clearly (as shown above) it is a part of this formula.

**Tags:** wallet, private-key, public-key, xpub

> **Comments:**
> **username_1**: The network bytes are a human-safety feature, they do not impact key derivation. They are mainly to identify which network a program should be checking, if it is given an extended key  
> **username_0**: So only the public or private key + chaincode impact key derivation? Are the rest just identifiers?  What about the extended pub/priv key at root, before cointype? The wallet may have multiple coins underneath. Should that data simply not be included?  

---

## 1 answers

### Answer by username_2 on 2018-08-16. Score: 13 | Accepted answer

The extended public key contains just a bit more information than the public key and chaincode, but the public key and chaincode are all that matter for key derivation. The rest is just metadata about the keys for wallets and people.

The version bytes distinguish between xpub, xpriv, and other types of keys. The fingerprint identifies the parent so that a wallet can know what the parent of this key is. The child index tells a wallet how to derive this key again from the parent.

> I'm unfamiliar with what comprises the extended private key.

The extended private key is exactly the same as the extended public key but instead of 33 bytes of public key data, it's 33 bytes of private key data.

> the network has an effect on this as well, which doesn't make sense to me either but clearly (as shown above) it is a part of this formula.

The network determines the version bytes. These version bytes are present in everything else in Bitcoin and is only to indicate to the user what network the key is used for. This is useful in identifying whether a key may be compromised (because e.g. it has been used for testing software)

> Can someone deconstruct an extended key from beginning to end?

Let's use `xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw` as our xpub.

Base58 decoding this gives us

```
0488B21E013442193E8000000047FDACBD0F1097043B78C63C20C34EF4ED9A111D980047AD16282C7AE6236141035A784662A4A20A65BF6AAB9AE98A6C068A81C52E4B032C0FB5400C706CFCCC56B8B9C580

```

`0488B21E` are the version bytes as defined by BIP 32.

`01` means that this key as at depth one

`3442193E` is the fingerprint of the parent key

`80000000` means that the key is index 0h (0'th hardened key)

`47FDACBD0F1097043B78C63C20C34EF4ED9A111D980047AD16282C7AE6236141` is the chaincode

`035A784662A4A20A65BF6AAB9AE98A6C068A81C52E4B032C0FB5400C706CFCCC56` is the public key

`B8B9C580` is the base58 check encoding checksum.


---

