<p><code>ypub</code> and <code>zpub</code> are not things that are specified in BIPs. They are things that people have decided to use and specify outside of the BIPs process.</p>

<p>Furthermore, they are a layer violation. They specify what kind of addresses a public key should be used to create, but key generation and the address type to create from a key are entirely separate things that shouldn't be mixed together.</p>

<p>Lastly, Bitcoin Core does not currently support having a public key be for a specific address type. Any public key in Bitcoin Core can be used for all 3 address types and there is no separation of derivation paths or master keys for different address types.</p>

CC BY-SA 4.0
2019-12-11T05:39:18.257Z
Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/102059/discussion-on-answer-by-andrew-chow-why-does-importmulti-not-support-zpub-and-yp).
Ava Chow
CC BY-SA 4.0
2020-09-22T14:16:22.763Z
`zpub` seems to be defined on [BIP-84](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki), currently with status draft.
eloyesp
CC BY-SA 4.0
2019-07-20T15:37:22.590Z
2019-07-20T15:37:22.590Z
Ava Chow
<p>The "xpub" format was defined by BIP32. It's a standard that specifies how to derive public keys from master public keys and seeds. Parts of it are widely adopted, some parts aren't. However, it does not say anything about how the keys it generate should be turned into addresses, only the keys themselves.</p>

<p>Now, at the time, there was only really one obvious way of turning a key into an addresses: by using its hash in a P2PKH (1...) address. This was implemented by numerous pieces of software, which more often than not treated "importing an xpub" as "importing an xpub and watching all P2PKH addresses for the resulting keys". This made sense, because it was how everyone wanted to use them anyway.</p>

<p>Then came along Segwit, which introduced two new common ways of paying to single-key outputs. Wallet software needed a way to "mark" an xpub as being intended to be used for P2WPKH (bc1...) or P2SH-P2WPKH (3...), instead of the traditional P2PKH. As the xpub standard had become interpreted as P2PKH only (rather than an address-agnostic way of describing public keys), something other than xpubs were needed. This is why some people adopted ypub/zpub for this purpose.</p>

<p>I believe this is confusing, as it is unclear now what an xpub means, and it is not scalable: we can't keep inventing new xpub-like formats for all types of addresses that may be invented. Especially with the introduction of multisig and more complex constructions, which simply don't fit into a single xpub-like thing (because you'll need to combine multiple of them).</p>

<p>For this reason, Bitcoin Core is using (and further developing) an approach called <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md" rel="noreferrer">Output Descriptors</a>. These are strings that specify exactly and unambiguously what scripts/addresses are desired, based on the involved public keys. These expressions support xpubs, but only in the original address-neutral meaning - the rest is conveyed using functions on top of them. For example:</p>

<ul>
<li><code>pkh(xpub.../44'/0'/0'/0/*)</code> would describe the BIP44 addresses derived from a particular xpub (P2PKH).</li>
<li><code>sh(wpkh(xpub.../49'/0'/0/*))</code> would describe the BIP49 addresses derived from a particular xpub (P2SH-P2WPKH).</li>
<li><code>wsh(multi(2,xpub1.../*,xpub2.../*,xpub3.../*))</code> represents a 2-of-3 P2WSH-embedded multisig.</li>
</ul>

<p>There are many more features in descriptors, and there is ongoing development. </p>

<p>Disclaimer: I'm the author of BIP32.</p>

CC BY-SA 4.0
2019-07-21T20:12:58.950Z
Your work is very much appreciated. I am using the descriptor approach for importing into Bitcoin Core and it is very cool. If anyone wants more info here is a useful link (also written by Pieter) on descriptors: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md
Fontaine
CC BY-SA 4.0
2019-12-09T14:43:34.973Z
Is the extended key itself or its derived keys actually imported into the wallet of Bitcoin Core? It seems to be the later.
Chris Chen
CC BY-SA 4.0
2019-12-09T16:40:50.980Z
In current versions, the descriptors' keys are expanded at import time. This means you need to provide an upper bound for the range of indices used. In a future version you'll be able to import descriptors directly, allowing them to be expanded on the fly as addresses get used.
Pieter Wuille
CC BY-SA 4.0
2019-07-20T19:45:15.417Z
2019-07-20T19:55:30.987Z
2019-07-20T19:55:30.987Z
Pieter Wuille
<p>As far as I can tell <code>importmulti</code> does not work with zpub/ypub.</p>

<p>Why not?</p>

<p>FWIW I prefer only to deal with xpubs, but I am curious. </p>

<bitcoin-core><json-rpc><bitcoin-cli><terminology><xpub>
Why does importmulti not support zpub and ypub?
Fontaine
# Why does importmulti not support zpub and ypub?

(Asked by: username_0 on 2019-07-20)

As far as I can tell `importmulti` does not work with zpub/ypub.

Why not?

FWIW I prefer only to deal with xpubs, but I am curious.

**Tags:** bitcoin-core, json-rpc, bitcoin-cli, terminology, xpub


---

## 2 answers

### Answer by username_3 on 2019-07-20. Score: 12 | Accepted answer

The "xpub" format was defined by BIP32. It's a standard that specifies how to derive public keys from master public keys and seeds. Parts of it are widely adopted, some parts aren't. However, it does not say anything about how the keys it generate should be turned into addresses, only the keys themselves.

Now, at the time, there was only really one obvious way of turning a key into an addresses: by using its hash in a P2PKH (1...) address. This was implemented by numerous pieces of software, which more often than not treated "importing an xpub" as "importing an xpub and watching all P2PKH addresses for the resulting keys". This made sense, because it was how everyone wanted to use them anyway.

Then came along Segwit, which introduced two new common ways of paying to single-key outputs. Wallet software needed a way to "mark" an xpub as being intended to be used for P2WPKH (bc1...) or P2SH-P2WPKH (3...), instead of the traditional P2PKH. As the xpub standard had become interpreted as P2PKH only (rather than an address-agnostic way of describing public keys), something other than xpubs were needed. This is why some people adopted ypub/zpub for this purpose.

I believe this is confusing, as it is unclear now what an xpub means, and it is not scalable: we can't keep inventing new xpub-like formats for all types of addresses that may be invented. Especially with the introduction of multisig and more complex constructions, which simply don't fit into a single xpub-like thing (because you'll need to combine multiple of them).

For this reason, Bitcoin Core is using (and further developing) an approach called [Output Descriptors](https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md). These are strings that specify exactly and unambiguously what scripts/addresses are desired, based on the involved public keys. These expressions support xpubs, but only in the original address-neutral meaning - the rest is conveyed using functions on top of them. For example:

* `pkh(xpub.../44'/0'/0'/0/*)` would describe the BIP44 addresses derived from a particular xpub (P2PKH).
* `sh(wpkh(xpub.../49'/0'/0/*))` would describe the BIP49 addresses derived from a particular xpub (P2SH-P2WPKH).
* `wsh(multi(2,xpub1.../*,xpub2.../*,xpub3.../*))` represents a 2-of-3 P2WSH-embedded multisig.

There are many more features in descriptors, and there is ongoing development.

Disclaimer: I'm the author of BIP32.

> **Comments:**
> **username_0**: Your work is very much appreciated. I am using the descriptor approach for importing into Bitcoin Core and it is very cool. If anyone wants more info here is a useful link (also written by username_3) on descriptors: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md  
> **username_4**: Is the extended key itself or its derived keys actually imported into the wallet of Bitcoin Core? It seems to be the later.  
> **username_3**: In current versions, the descriptors' keys are expanded at import time. This means you need to provide an upper bound for the range of indices used. In a future version you'll be able to import descriptors directly, allowing them to be expanded on the fly as addresses get used.  

---

### Answer by username_1 on 2019-07-20. Score: 6

`ypub` and `zpub` are not things that are specified in BIPs. They are things that people have decided to use and specify outside of the BIPs process.

Furthermore, they are a layer violation. They specify what kind of addresses a public key should be used to create, but key generation and the address type to create from a key are entirely separate things that shouldn't be mixed together.

Lastly, Bitcoin Core does not currently support having a public key be for a specific address type. Any public key in Bitcoin Core can be used for all 3 address types and there is no separation of derivation paths or master keys for different address types.

> **Comments:**
> **username_1**: Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/102059/discussion-on-answer-by-andrew-username_1-why-does-importmulti-not-support-zpub-and-yp).  
> **username_2**: `zpub` seems to be defined on [BIP-84](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki), currently with status draft.  

---

