<p>Non-private descriptors are &quot;normalized&quot; before being listed. This process includes deriving the keys it contains to the last hardened step.</p>
<p>All the <code>xpub</code>s in your example are derived from the same master extended key, <code>ab7bc48f</code>, but at different paths. You'll notice these derivation paths are the same as those used in the private version of the descriptor. Except in the private descriptors there is no need to derive at the last hardened step since you have access to the master <code>xpriv</code> already.</p>

CC BY-SA 4.0
2023-04-04T10:33:10.577Z
2023-04-04T10:33:10.577Z
Antoine Poinsot
<p>I noticed that if I <code>listdescriptors true</code> immediately after creating a brand new wallet, it would list 8 descriptors that all use the same <code>xprv</code> key.</p>
<p>However, <code>listdescriptors false</code> would list 8 <code>xpub</code> keys, and they are not all the same key. Note in the example below how public keys start with:</p>
<ul>
<li><code>xpub6ChP1W</code></li>
<li><code>xpub6CyAaD</code></li>
<li><code>xpub6Cc74F</code></li>
<li><code>xpub6BmTmL</code></li>
</ul>
<p>Why are they different?</p>
<h3>Example</h3>
<pre><code>Public (API parameter &quot;private&quot;: false):

Key                                                        Active   Internal
pkh(    [ab7bc48f/44'/0'/0']xpub6ChP1W.../0/*)  #ma29dzhm     +         -
pkh(    [ab7bc48f/44'/0'/0']xpub6ChP1W.../1/*)  #2f0ysh8r     +         +
sh(wpkh([ab7bc48f/49'/0'/0']xpub6CyAaD.../0/*)) #zwwuauzd     +         -
sh(wpkh([ab7bc48f/49'/0'/0']xpub6CyAaD.../1/*)) #h0q29rhj     +         +
tr(     [ab7bc48f/86'/0'/0']xpub6Cc74F.../0/*)  #l6jyecux     +         -
tr(     [ab7bc48f/86'/0'/0']xpub6Cc74F.../1/*)  #wwh9ydv7     +         +
wpkh(   [ab7bc48f/84'/0'/0']xpub6BmTmL.../0/*)  #80mc28c3     +         -
wpkh(   [ab7bc48f/84'/0'/0']xpub6BmTmL.../1/*)  #km7ehjgf     +         +


Private (API parameter &quot;private&quot;: true):

Key                                                Active   Internal
pkh(    xprv9s21Zr.../44'/0'/0'/0/*)  #5l2phqsm      +         -
pkh(    xprv9s21Zr.../44'/0'/0'/1/*)  #9t0q24qr      +         +
sh(wpkh(xprv9s21Zr.../49'/0'/0'/0/*)) #r78qs2yd      +         -
sh(wpkh(xprv9s21Zr.../49'/0'/0'/1/*)) #9a09t80e      +         +
tr(     xprv9s21Zr.../86'/0'/0'/0/*)  #02tnkr5v      +         -
tr(     xprv9s21Zr.../86'/0'/0'/1/*)  #77wjtky5      +         +
wpkh(   xprv9s21Zr.../84'/0'/0'/0/*)  #93lra6e7      +         -
wpkh(   xprv9s21Zr.../84'/0'/0'/1/*)  #596zq0fx      +         +
</code></pre>
<h3>Backing Up Descriptors</h3>
<p>My understanding was that having saved the <code>xprv</code> key only, I'd be able to fully recreate a similar wallet on a different node - because I could derive <code>xpub</code> from <code>xprv</code>. But now I got confused - how would I derive those <code>xpub</code>s, and why there are more than one.</p>

<bitcoin-core><public-key><private-key-export><output-script-descriptors>
Why listdescriptors yields different xpub keys for a brand new wallet in bitcoin core
Meglio
# Why listdescriptors yields different xpub keys for a brand new wallet in bitcoin core

(Asked by: username_0 on 2023-04-03)

I noticed that if I `listdescriptors true` immediately after creating a brand new wallet, it would list 8 descriptors that all use the same `xprv` key.

However, `listdescriptors false` would list 8 `xpub` keys, and they are not all the same key. Note in the example below how public keys start with:

* `xpub6ChP1W`
* `xpub6CyAaD`
* `xpub6Cc74F`
* `xpub6BmTmL`

Why are they different?

### Example

```
Public (API parameter "private": false):

Key                                                        Active   Internal
pkh(    [ab7bc48f/44'/0'/0']xpub6ChP1W.../0/*)  #ma29dzhm     +         -
pkh(    [ab7bc48f/44'/0'/0']xpub6ChP1W.../1/*)  #2f0ysh8r     +         +
sh(wpkh([ab7bc48f/49'/0'/0']xpub6CyAaD.../0/*)) #zwwuauzd     +         -
sh(wpkh([ab7bc48f/49'/0'/0']xpub6CyAaD.../1/*)) #h0q29rhj     +         +
tr(     [ab7bc48f/86'/0'/0']xpub6Cc74F.../0/*)  #l6jyecux     +         -
tr(     [ab7bc48f/86'/0'/0']xpub6Cc74F.../1/*)  #wwh9ydv7     +         +
wpkh(   [ab7bc48f/84'/0'/0']xpub6BmTmL.../0/*)  #80mc28c3     +         -
wpkh(   [ab7bc48f/84'/0'/0']xpub6BmTmL.../1/*)  #km7ehjgf     +         +

Private (API parameter "private": true):

Key                                                Active   Internal
pkh(    xprv9s21Zr.../44'/0'/0'/0/*)  #5l2phqsm      +         -
pkh(    xprv9s21Zr.../44'/0'/0'/1/*)  #9t0q24qr      +         +
sh(wpkh(xprv9s21Zr.../49'/0'/0'/0/*)) #r78qs2yd      +         -
sh(wpkh(xprv9s21Zr.../49'/0'/0'/1/*)) #9a09t80e      +         +
tr(     xprv9s21Zr.../86'/0'/0'/0/*)  #02tnkr5v      +         -
tr(     xprv9s21Zr.../86'/0'/0'/1/*)  #77wjtky5      +         +
wpkh(   xprv9s21Zr.../84'/0'/0'/0/*)  #93lra6e7      +         -
wpkh(   xprv9s21Zr.../84'/0'/0'/1/*)  #596zq0fx      +         +

```

### Backing Up Descriptors

My understanding was that having saved the `xprv` key only, I'd be able to fully recreate a similar wallet on a different node - because I could derive `xpub` from `xprv`. But now I got confused - how would I derive those `xpub`s, and why there are more than one.

**Tags:** bitcoin-core, public-key, private-key-export, output-script-descriptors


---

## 1 answers

### Answer by username_1 on 2023-04-04. Score: 2 | Accepted answer

Non-private descriptors are "normalized" before being listed. This process includes deriving the keys it contains to the last hardened step.

All the `xpub`s in your example are derived from the same master extended key, `ab7bc48f`, but at different paths. You'll notice these derivation paths are the same as those used in the private version of the descriptor. Except in the private descriptors there is no need to derive at the last hardened step since you have access to the master `xpriv` already.


---

