<p>The concept of an <code>xpub</code> originates from <a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki" rel="noreferrer">BIP32</a>, where it denotes an extended public key, from which multiple child keys can be derived.</p>
<p>At the time of BIP32, there was really only one address type commonly used, pay-to-pubkey-hash (P2PKH). Thus, BIP32 were commonly understood to imply a sequence of derived P2PKH addresses.</p>
<p>After <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="noreferrer">segwit</a>, when other address types came in common use, like P2SH-P2WPKH and P2WPKH, people needed a way to convey &quot;a BIP32 extended public key, but the derived addresses are P2SH-P2WPKH&quot;. This became the <code>ypub</code> scheme defined in <a href="https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki" rel="noreferrer">BIP49</a> for P2SH-P2WPKH, and later the <code>zpub</code> scheme in <a href="https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki" rel="noreferrer">BIP84</a> for P2WPKH. They contain the exact same information as a BIP32 extended public key, but with a different prefix to denote the corresponding address type. Various other variants were defined and adopted by some software, e.g. <code>Zpub</code> for P2WSH, but not standardized through the BIP process as far as I know.</p>
<p>Other software never adopted <code>ypub</code>/<code>zpub</code>/<code>Zpub</code>/..., as the continuing need for new prefixes does not scale well, and the notion of trying to pack all address derivation information into a single key string also just doesn't work for more complex constructions like multisig. For example, in the newer output descriptors (<a href="https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki" rel="noreferrer">BIP380</a>) standard, <code>xpub</code> is always used, but one would use <code>wpkh(xpub...)</code> to indicate a P2WPKH address type.</p>
<p>As far as I know, there is no <code>*pub</code>-like standard for P2TR yet, and in my opinion there should not be. It is much clearer to convey address type information outside of key strings.</p>
<p>Disclaimer: I'm the author of BIP32, and co-author of BIP380.</p>

CC BY-SA 4.0
2024-01-08T17:52:45.007Z
2024-01-08T17:59:52.783Z
2024-01-08T17:59:52.783Z
Pieter Wuille
<p>There is no ypub/zpub similar thing for Taproot. The recommendation is to use xpriv/xpub along with some extra information indicating that the script to create is Taproot, (e.g. with a <code>tr()</code> descriptor).</p>
<p>This is because it is a layer violation to have the extended keypair indicate the script type to create. The keys should not and do not care about what scripts to create. Additionally, xprv and xpub are not supposed to indicate legacy addresses - they are for BIP 32 extended keys which are script agnostic. To use them to indicate legacy addresses is incorrect.</p>
<p>In general, there is a move towards encouraging and using more complicated scripts where having extended keypairs indicate script type doesn't really make sense.</p>

CC BY-SA 4.0
2021-11-15T17:23:51.457Z
2021-11-15T17:23:51.457Z
Ava Chow
<p>As far as I understand, there is a standard that describes what address types an extended private key or extended public key is intended to derive and it works as such:</p>
<ul>
<li>xpriv/xpub =&gt; Legacy address (1...)</li>
<li>ypriv/ypub =&gt; nested SegWit address (3...)</li>
<li>zpriv/zpub =&gt; native SegWit address (bc1q...)</li>
</ul>
<p>So regarding this, I have 2 questions:</p>
<ol>
<li>What is the name or BIP number of this standard?</li>
<li>What does an extended public key look like, that is intended to be used for P2TR addresses (bc1p...)?</li>
</ol>

<bip32-hd-wallets><xpub><output-script-descriptors><p2tr>
XPRIV/XPUB type for P2TR
Dalit Sairio
# XPRIV/XPUB type for P2TR

(Asked by: username_0 on 2021-11-15)

As far as I understand, there is a standard that describes what address types an extended private key or extended public key is intended to derive and it works as such:

* xpriv/xpub => Legacy address (1...)
* ypriv/ypub => nested SegWit address (3...)
* zpriv/zpub => native SegWit address (bc1q...)

So regarding this, I have 2 questions:

1. What is the name or BIP number of this standard?
2. What does an extended public key look like, that is intended to be used for P2TR addresses (bc1p...)?

**Tags:** bip32-hd-wallets, xpub, output-script-descriptors, p2tr


---

## 2 answers

### Answer by username_2 on 2021-11-15. Score: 13 | Accepted answer

There is no ypub/zpub similar thing for Taproot. The recommendation is to use xpriv/xpub along with some extra information indicating that the script to create is Taproot, (e.g. with a `tr()` descriptor).

This is because it is a layer violation to have the extended keypair indicate the script type to create. The keys should not and do not care about what scripts to create. Additionally, xprv and xpub are not supposed to indicate legacy addresses - they are for BIP 32 extended keys which are script agnostic. To use them to indicate legacy addresses is incorrect.

In general, there is a move towards encouraging and using more complicated scripts where having extended keypairs indicate script type doesn't really make sense.


---

### Answer by username_1 on 2024-01-08. Score: 8

The concept of an `xpub` originates from [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki), where it denotes an extended public key, from which multiple child keys can be derived.

At the time of BIP32, there was really only one address type commonly used, pay-to-pubkey-hash (P2PKH). Thus, BIP32 were commonly understood to imply a sequence of derived P2PKH addresses.

After [segwit](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki), when other address types came in common use, like P2SH-P2WPKH and P2WPKH, people needed a way to convey "a BIP32 extended public key, but the derived addresses are P2SH-P2WPKH". This became the `ypub` scheme defined in [BIP49](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki) for P2SH-P2WPKH, and later the `zpub` scheme in [BIP84](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki) for P2WPKH. They contain the exact same information as a BIP32 extended public key, but with a different prefix to denote the corresponding address type. Various other variants were defined and adopted by some software, e.g. `Zpub` for P2WSH, but not standardized through the BIP process as far as I know.

Other software never adopted `ypub`/`zpub`/`Zpub`/..., as the continuing need for new prefixes does not scale well, and the notion of trying to pack all address derivation information into a single key string also just doesn't work for more complex constructions like multisig. For example, in the newer output descriptors ([BIP380](https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki)) standard, `xpub` is always used, but one would use `wpkh(xpub...)` to indicate a P2WPKH address type.

As far as I know, there is no `*pub`-like standard for P2TR yet, and in my opinion there should not be. It is much clearer to convey address type information outside of key strings.

Disclaimer: I'm the author of BIP32, and co-author of BIP380.


---

