<blockquote>
<p>For example, if it is XPUB, then we know that we should use BIP44 and how to derive all other keys from it.</p>
</blockquote>
<p>That's not correct. An xpub just identifies a extended public key and its ancestry. It says nothing about how to derive further elements.</p>
<blockquote>
<p>Also, since it is XPUB, we know that all keys derived from this key will only be used for P2PKH.</p>
</blockquote>
<p>That's not correct either. xpubs (as defined in BIP32) say nothing about the address type to use. ypub/zpub were defined independently, later, in unrelated standards, for a different purpose, and are only supported by some software. At some point, there was a perceived need to convey address type information in the same string as the public key, so people defined ypub/zpub/... and various other variations which (ab)use the magic value to try to convey that.</p>
<p>I believe this was, and is, a mistake; it is the wrong place to put this information, for two reasons:</p>
<ul>
<li>With Bitcoin script technology evolving, we need ever new formats, despite the keys being the same (resulting in a plethora of magic bytes today).</li>
<li>In the context of multisig, you inherently need multiple public keys anyway, as they come from distinct sources, so a &quot;higher&quot; level of information &quot;around&quot; the keys is needed regardless.</li>
</ul>
<p><a href="https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md" rel="nofollow noreferrer">Output descriptors</a> serve this purpose of metadata about how keys are to be used now, but are a lot more recent. For example, addresses for receiving would be written as descriptors which just list the derivation paths explicitly:</p>
<ul>
<li>For BIP44, <code>pkh(xpub.../44'/0'/0'/0/*)</code></li>
<li>For BIP49, <code>sh(pkh(xpub.../49'/0'/0'/0/*))</code></li>
<li>For BIP84, <code>wpkh(xpub.../84'/0'/0'/0/*)</code></li>
<li>For a 2-of-2 P2WSH multisig, <code>wsh(multi(2,xpub1/.../*,xpub2/.../*))</code></li>
<li>etc</li>
</ul>
<p>(Disclaimer: I authored BIP32 which defines xpubs, and contributed to the output descriptor format, so I am possibly biased on this topic)</p>
<blockquote>
<p>Is that the purpose of the different types of extended keys (different &quot;values&quot; for magic)?</p>
</blockquote>
<p>The parent fingerprint and the level is there so wallets can recognize implicit derivation steps.</p>
<p>Say you have a wallet which knows the private key to <code>m/a/b</code>. If it is given an xpub for <code>m/a/b/c</code> (which contains the fingerprint for <code>m/a/b</code> and the index <code>c</code>), it can derive the xprv for <code>m/a/b/c</code> by looking up the xprv for <code>m/a/b</code> using the fingerprint as lookup key, and computing its child <code>c</code>.</p>
<p>In retrospect, I'm not sure it was necessary to put this information in the xpub, and I don't know if it's actually used for this purpose. BIP32 was written in 2012-2013, and the Bitcoin world has changed a lot since then.</p>

CC BY-SA 4.0
2023-07-21T20:16:15.570Z
So if a wallet gets, for example, a ZPUB, it won't recognize that it's BIP84 and should use a certain type of derivation path and use those keys for a certain purpose?
dassd
CC BY-SA 4.0
2023-07-21T20:17:30.587Z
That depends on the wallet. Most wallets don't support zpubs at all, AFAIK.
Pieter Wuille
CC BY-SA 4.0
2023-07-21T20:21:02.580Z
Yes, but it should be some behavior? Let's also say that the answer to the previous question is correct (that it is such a wallet), although XPUB is defined according to the BIP32 standard, if the wallet receives XPUB, should it follow BIP44? According to all this, it turns out that all this is only for people to better understand the given key...
dassd
CC BY-SA 4.0
2023-07-21T20:22:59.960Z
Wallets (and software in general) chooses which standards to support; these things are not absolute. Just because someone wrote a document somewhere saying that "xpub" means this or that, does not mean every piece of software is obliged to follow that. Bitcoin Core for example supports BIP32, but not any of the ypub/zpub/... things, so it makes absolutely no assumptions about key paths or address types when an xpub is imported. You need to tell it what to do with it (see the output descriptor examples in my answer).
Pieter Wuille
CC BY-SA 4.0
2023-07-21T20:29:34.093Z
So if most wallets don't support ZPUB, YPUB... we'll just give them XPUB (XPRV) (magic will be 0x0488B21E for public key) and then "tell" them to use, for example, BIP84 if it's ZPUB. So then they will know that for that XPUB they should use the derivation path from BIP84 and for what purpose will the keys derived from that extended key be used? If the wallets support ZPUB, then we shouldn't "tell" them to use BIP84 because they will recognize it by giving them ZPUB (magic will be 0x04b24746 for public key) and not XPUB? Did I get it right?
dassd
CC BY-SA 4.0
2023-07-21T20:30:55.430Z
Maybe, I don't know how exactly the zpub standard works.
Pieter Wuille
CC BY-SA 4.0
2023-07-21T20:34:00.680Z
Apparently they are defined in SLIP-0132 (https://github.com/satoshilabs/slips/blob/master/slip-0132.md), which indeed specifies which derivation paths to use as well.
Pieter Wuille
CC BY-SA 4.0
2023-07-21T20:34:19.673Z
It is defined in BIP84 (https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki#extended-key-version). But the point is: if a wallet doesn't support anything other than XPUB/XPRIV, I give it to the wallets and define the standard they should follow (BIP44/BIP84...); on the other hand, if the wallet supports anything other than XPUB/XPRIV, it should recognize the standard from the value in the magic word?
dassd
CC BY-SA 4.0
2023-07-21T20:35:42.503Z
That depends on what they support.
Pieter Wuille
CC BY-SA 4.0
2023-07-21T20:07:15.763Z
2023-07-21T20:07:15.763Z
Pieter Wuille
<p>I have a few questions about the extended public/private key, i.e. the purpose of its elements.</p>
<p>Namely, according to the BIP32 standard, the &quot;format&quot; of the extended key is as follows:</p>
<pre><code>[ magic ][ depth ][ parent fingerprint ][ key index ][ chain code ][ key ]
</code></pre>
<p>However, what we actually need when generating new child keys is only the chain code and the key (private or public). What is the role of other elements within a given format. I understand that the magic gives the ability to recognize that it is an extended key after encoding with Base58, but even in that case exists a different types of extended keys (zpub/zpriv, ypub/ypriv). I can understand that all those &quot;properties&quot; can help people understand where that key is potentially located within the tree and what we can use it for. For example, if it is XPUB, then we know that we should use BIP44 and how to derive all other keys from it. Since the derivation path according to BIP44 is as follows:</p>
<pre><code>m / purpose' / coin_type' / account' / change / address_index
</code></pre>
<p>... if the depth is 2, then we would know that we should use a hardened derivation and that we cannot use XPUB of this key to derive the child public keys since they are hardened. Also, since it is XPUB, we know that all keys derived from this key will only be used for P2PKH. On the other hand, if it was ZPUB/ZPRIV, we would know that we should follow BIP84 as well as the purpose of those keys. And so on...</p>
<p>So, it is clear to me how we, as humans, would use all the elements from the extended key (although it is not clear to me what the parent fingerprint will do for us). <strong>Do wallets also interpret extended keys this way?</strong> For example, if XPUB/XPUB gets to them, they will know that they follow the BIP44 standard and what the leaf nodes of its derivation path are for (P2PKH), if ZPUB/ZPRIV comes they follow BIP88 and so on. <strong>Is that the purpose of the different types of extended keys (different &quot;values&quot; for magic)?</strong></p>
<p>Can someone tell me something more on this topic? What are all those fields for (different forms of magic, depth, etc.)? <strong>Is it so that the wallets know how to generate all the other keys, what are the keys for, and so on, or do they also have some other purpose?</strong></p>

<private-key><bip32-hd-wallets><public-key>
What is the purpose of the different types of extended keys, as well as some of its other elements?
dassd
# What is the purpose of the different types of extended keys, as well as some of its other elements?

(Asked by: username_0 on 2023-07-21)

I have a few questions about the extended public/private key, i.e. the purpose of its elements.

Namely, according to the BIP32 standard, the "format" of the extended key is as follows:

```
[ magic ][ depth ][ parent fingerprint ][ key index ][ chain code ][ key ]

```

However, what we actually need when generating new child keys is only the chain code and the key (private or public). What is the role of other elements within a given format. I understand that the magic gives the ability to recognize that it is an extended key after encoding with Base58, but even in that case exists a different types of extended keys (zpub/zpriv, ypub/ypriv). I can understand that all those "properties" can help people understand where that key is potentially located within the tree and what we can use it for. For example, if it is XPUB, then we know that we should use BIP44 and how to derive all other keys from it. Since the derivation path according to BIP44 is as follows:

```
m / purpose' / coin_type' / account' / change / address_index

```

... if the depth is 2, then we would know that we should use a hardened derivation and that we cannot use XPUB of this key to derive the child public keys since they are hardened. Also, since it is XPUB, we know that all keys derived from this key will only be used for P2PKH. On the other hand, if it was ZPUB/ZPRIV, we would know that we should follow BIP84 as well as the purpose of those keys. And so on...

So, it is clear to me how we, as humans, would use all the elements from the extended key (although it is not clear to me what the parent fingerprint will do for us). **Do wallets also interpret extended keys this way?** For example, if XPUB/XPUB gets to them, they will know that they follow the BIP44 standard and what the leaf nodes of its derivation path are for (P2PKH), if ZPUB/ZPRIV comes they follow BIP88 and so on. **Is that the purpose of the different types of extended keys (different "values" for magic)?**

Can someone tell me something more on this topic? What are all those fields for (different forms of magic, depth, etc.)? **Is it so that the wallets know how to generate all the other keys, what are the keys for, and so on, or do they also have some other purpose?**

**Tags:** private-key, bip32-hd-wallets, public-key


---

## 1 answers

### Answer by username_1 on 2023-07-21. Score: 0 | Accepted answer

> For example, if it is XPUB, then we know that we should use BIP44 and how to derive all other keys from it.

That's not correct. An xpub just identifies a extended public key and its ancestry. It says nothing about how to derive further elements.

> Also, since it is XPUB, we know that all keys derived from this key will only be used for P2PKH.

That's not correct either. xpubs (as defined in BIP32) say nothing about the address type to use. ypub/zpub were defined independently, later, in unrelated standards, for a different purpose, and are only supported by some software. At some point, there was a perceived need to convey address type information in the same string as the public key, so people defined ypub/zpub/... and various other variations which (ab)use the magic value to try to convey that.

I believe this was, and is, a mistake; it is the wrong place to put this information, for two reasons:

* With Bitcoin script technology evolving, we need ever new formats, despite the keys being the same (resulting in a plethora of magic bytes today).
* In the context of multisig, you inherently need multiple public keys anyway, as they come from distinct sources, so a "higher" level of information "around" the keys is needed regardless.

[Output descriptors](https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md) serve this purpose of metadata about how keys are to be used now, but are a lot more recent. For example, addresses for receiving would be written as descriptors which just list the derivation paths explicitly:

* For BIP44, `pkh(xpub.../44'/0'/0'/0/*)`
* For BIP49, `sh(pkh(xpub.../49'/0'/0'/0/*))`
* For BIP84, `wpkh(xpub.../84'/0'/0'/0/*)`
* For a 2-of-2 P2WSH multisig, `wsh(multi(2,xpub1/.../*,xpub2/.../*))`
* etc

(Disclaimer: I authored BIP32 which defines xpubs, and contributed to the output descriptor format, so I am possibly biased on this topic)

> Is that the purpose of the different types of extended keys (different "values" for magic)?

The parent fingerprint and the level is there so wallets can recognize implicit derivation steps.

Say you have a wallet which knows the private key to `m/a/b`. If it is given an xpub for `m/a/b/c` (which contains the fingerprint for `m/a/b` and the index `c`), it can derive the xprv for `m/a/b/c` by looking up the xprv for `m/a/b` using the fingerprint as lookup key, and computing its child `c`.

In retrospect, I'm not sure it was necessary to put this information in the xpub, and I don't know if it's actually used for this purpose. BIP32 was written in 2012-2013, and the Bitcoin world has changed a lot since then.

> **Comments:**
> **username_0**: So if a wallet gets, for example, a ZPUB, it won't recognize that it's BIP84 and should use a certain type of derivation path and use those keys for a certain purpose?  
> **username_1**: That depends on the wallet. Most wallets don't support zpubs at all, AFAIK.  
> **username_0**: Yes, but it should be some behavior? Let's also say that the answer to the previous question is correct (that it is such a wallet), although XPUB is defined according to the BIP32 standard, if the wallet receives XPUB, should it follow BIP44? According to all this, it turns out that all this is only for people to better understand the given key...  
> **username_1**: Wallets (and software in general) chooses which standards to support; these things are not absolute. Just because someone wrote a document somewhere saying that "xpub" means this or that, does not mean every piece of software is obliged to follow that. Bitcoin Core for example supports BIP32, but not any of the ypub/zpub/... things, so it makes absolutely no assumptions about key paths or address types when an xpub is imported. You need to tell it what to do with it (see the output descriptor examples in my answer).  
> **username_0**: So if most wallets don't support ZPUB, YPUB... we'll just give them XPUB (XPRV) (magic will be 0x0488B21E for public key) and then "tell" them to use, for example, BIP84 if it's ZPUB. So then they will know that for that XPUB they should use the derivation path from BIP84 and for what purpose will the keys derived from that extended key be used? If the wallets support ZPUB, then we shouldn't "tell" them to use BIP84 because they will recognize it by giving them ZPUB (magic will be 0x04b24746 for public key) and not XPUB? Did I get it right?  
> **username_1**: Maybe, I don't know how exactly the zpub standard works.  
> **username_1**: Apparently they are defined in SLIP-0132 (https://github.com/satoshilabs/slips/blob/master/slip-0132.md), which indeed specifies which derivation paths to use as well.  
> **username_0**: It is defined in BIP84 (https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki#extended-key-version). But the point is: if a wallet doesn't support anything other than XPUB/XPRIV, I give it to the wallets and define the standard they should follow (BIP44/BIP84...); on the other hand, if the wallet supports anything other than XPUB/XPRIV, it should recognize the standard from the value in the magic word?  
> **username_1**: That depends on what they support.  

---

