<p>There is no such requirement. Any key in a derivation path is a master key for all children derived from it. It's trivial to make xprv2 a master key within a descriptor or PSBT. Even if there were a requirement to use the actual master key, there would be no way to enforce it unless the signer knew all of the possible derived children and their paths. Other signers, and generic software, would be completely unable to enforce such a restriction.</p>
<p>The purpose of including derivation paths is so that signers that hold master keys will be able to use BIP 32 and sign for children that they do not know the derivation paths of. If your master key is actually a child of some other key, then the PSBT and any descriptors can just include paths that are relative to that key. The fact it isn't the &quot;master&quot; is irrelevant, all keys can be master keys, they aren't special.</p>
<blockquote>
<p>Are both paths (m/99/88h/0/0 and 99/88h/0/0) considered valid? I have observed both in a few PSBTs generated by different libraries.</p>
</blockquote>
<p>Yes, and they are not distinct. Within a PSBT, the <code>m</code> is not actually stored. It is not useful information to a computer, but it is useful to users. So depending on the software, <code>m</code> may be prepended when displaying. But it doesn't actually exist.</p>
<blockquote>
<p>If the answer to the above is yes, what is the purpose of the master key marker 'm'?</p>
</blockquote>
<p>For display to the user to make it visually distinct that they are actually looking at a derivation path and that the the keys are derived from some master key. It's just notation and not meaningfully useful.</p>

CC BY-SA 4.0
2023-12-14T22:24:01.167Z
Thanks for the clarity.

What did you mean by this statement? "It's trivial to make xprv2 a master key within a descriptor or PSBT."
solar
CC BY-SA 4.0
2023-12-15T07:30:04.783Z
Any xprv can be a master key, so included its xpub in a descriptor or psbt and then giving derivations paths relative to it is sufficient to make it a master key to anything that processes psbts or descriptors.
Ava Chow
CC BY-SA 4.0
2023-12-14T20:43:51.147Z
2023-12-14T20:43:51.147Z
Ava Chow
<p>Let's consider a scenario: I have a master xprv named xprv1, and I derived an xprv named xprv2 at m/99/88h. Now, I want to use xprv2 to create a new multi-sig wallet, intending to use m/99/88h/0/* as my keys.</p>
<p>As per the specification, I am required to place the full path (e.g., m/99/88h/0/0) at the BIP32 derivation path, and the fingerprint of xprv1 as the master fingerprint.</p>
<p><strong>This introduces a couple of challenges:</strong></p>
<ol>
<li>If the signing device only has xprv2 (not the root xprv1), I cannot find the matching BIP32 derivation to sign.</li>
<li>Cosigners cannot verify signatures of xpub2 due to the same problem
mentioned above.</li>
</ol>
<p><strong>Questions:</strong></p>
<ol>
<li>Why is this rule of providing the full path from the master key enforced in Output Descriptor BIP380 (as key origin information) and PSBT BIP174?</li>
<li>Is it a strict rule (MUST) or an optional one?</li>
<li>Are we allowed to use 0/0 as the path and the fingerprint of xprv2
as the master fingerprint?</li>
</ol>
<p><em>Note: The JavaScript BIP32 <a href="https://github.com/bitcoinjs/bip32/blob/master/ts-src/bip32.ts#L376" rel="nofollow noreferrer">library</a> does not permit the use of the fingerprint of xprv2 as the master fingerprint.</em></p>
<ol start="4">
<li>Are both paths (m/99/88h/0/0 and 99/88h/0/0) considered valid? I have observed both in a few PSBTs generated by different libraries.</li>
<li>If the answer to the above is yes, what is the purpose of the master
key marker 'm'?</li>
</ol>

<bip32-hd-wallets><bip174-psbt><output-script-descriptors>
Why do PSBT and Descriptor enforce providing the BIP32 derivation path from the root?
solar
# Why do PSBT and Descriptor enforce providing the BIP32 derivation path from the root?

(Asked by: username_0 on 2023-12-14)

Let's consider a scenario: I have a master xprv named xprv1, and I derived an xprv named xprv2 at m/99/88h. Now, I want to use xprv2 to create a new multi-sig wallet, intending to use m/99/88h/0/\* as my keys.

As per the specification, I am required to place the full path (e.g., m/99/88h/0/0) at the BIP32 derivation path, and the fingerprint of xprv1 as the master fingerprint.

**This introduces a couple of challenges:**

1. If the signing device only has xprv2 (not the root xprv1), I cannot find the matching BIP32 derivation to sign.
2. Cosigners cannot verify signatures of xpub2 due to the same problem
   mentioned above.

**Questions:**

1. Why is this rule of providing the full path from the master key enforced in Output Descriptor BIP380 (as key origin information) and PSBT BIP174?
2. Is it a strict rule (MUST) or an optional one?
3. Are we allowed to use 0/0 as the path and the fingerprint of xprv2
   as the master fingerprint?

*Note: The JavaScript BIP32 [library](https://github.com/bitcoinjs/bip32/blob/master/ts-src/bip32.ts#L376) does not permit the use of the fingerprint of xprv2 as the master fingerprint.*

4. Are both paths (m/99/88h/0/0 and 99/88h/0/0) considered valid? I have observed both in a few PSBTs generated by different libraries.
5. If the answer to the above is yes, what is the purpose of the master
   key marker 'm'?

**Tags:** bip32-hd-wallets, bip174-psbt, output-script-descriptors


---

## 1 answers

### Answer by username_1 on 2023-12-14. Score: 1 | Accepted answer

There is no such requirement. Any key in a derivation path is a master key for all children derived from it. It's trivial to make xprv2 a master key within a descriptor or PSBT. Even if there were a requirement to use the actual master key, there would be no way to enforce it unless the signer knew all of the possible derived children and their paths. Other signers, and generic software, would be completely unable to enforce such a restriction.

The purpose of including derivation paths is so that signers that hold master keys will be able to use BIP 32 and sign for children that they do not know the derivation paths of. If your master key is actually a child of some other key, then the PSBT and any descriptors can just include paths that are relative to that key. The fact it isn't the "master" is irrelevant, all keys can be master keys, they aren't special.

> Are both paths (m/99/88h/0/0 and 99/88h/0/0) considered valid? I have observed both in a few PSBTs generated by different libraries.

Yes, and they are not distinct. Within a PSBT, the `m` is not actually stored. It is not useful information to a computer, but it is useful to users. So depending on the software, `m` may be prepended when displaying. But it doesn't actually exist.

> If the answer to the above is yes, what is the purpose of the master key marker 'm'?

For display to the user to make it visually distinct that they are actually looking at a derivation path and that the the keys are derived from some master key. It's just notation and not meaningfully useful.

> **Comments:**
> **username_0**: Thanks for the clarity.  What did you mean by this statement? "It's trivial to make xprv2 a master key within a descriptor or PSBT."  
> **username_1**: Any xprv can be a master key, so included its xpub in a descriptor or psbt and then giving derivations paths relative to it is sufficient to make it a master key to anything that processes psbts or descriptors.  

---

