Topic: Multisig derivation paths and xpubs (Read 408 times)

I was thinking less about forgetting your derivation path and more about if you ever needed to use some different piece of software.

As I said above, you can easily back up your derivation path alongside your seed phrase, and therefore have no additional risk of losing your coins. The issue would come if you want to import your multi-sig in to a different piece of software for whatever reason that does not let you specify arbitrary derivation paths.

If you back up your full descriptors and always use the same version of Sparrow then of course there will be no problems. But it is fairly easy to imagine a scenario where you need emergency access to your funds and you are forced to recover the seed phrases using different software, perhaps on a different OS, perhaps on mobile instead of a computer, and so on. In such a case it is always going to be an easier process if you have used the widely accepted standards rather than done something unique.

It is of course up to you - just explaining my rationale behind preferring to stick to standard practices.

However, I think so long as I backup the derivation path I should be ok. This thread will serve as an extra back up

Simply because it is the standard. I am not aware of a single wallet which derives P2SH address at m/49/0/x by default, while there are hundreds which follow the BIP39 standard of m/49'/0'/x'.

Just like there is nothing stopping me deriving a single sig wallet at m/3894329'/284760'/1609266' and backing up my derivation path, it is much safer to just stick to the standard m/84'/0'/0'.

Forgive my ignorance, but how does a hardened path help wallet recovery? I have the output descriptors and Sparrow and Electrum wallet files backed up on multiple media.

Thanks for the above. So ultimately unhardened vs hardened doesn't matter a great deal in multisig?

However, I would highly recommend sticking to the standard of using hardened paths for the first three levels if you are using 49 at the purpose level, not least of all to make your life easier when recovering your wallet in the future.

Of course in MultiSig, it needs the "N" number of cosigners, not just one.
And the other cosigner's xpub and private keys are unrelated to each other, that unhardened derivation vulnerability isn't applicable to each cosigner's keys.

Right. So after doing a little digging, it seems that the unhardened path can compromise all the coins in a wallet if the xprv of one address is compromised.

The relevance is that unhardened levels can be derived only using public keys, while hardened levels require the private keys. In short, they are entirely different numbers and will derive entirely different addresses.

Thanks. So, the xpubs will point to the right addresses with or without the derivation paths?

What is the difference between m/49' and m/49? So far as I can see, the derivation paths for all my multisig wallets are hardened (i.e., m/49).

If your output descriptors either include your derivation path, or are using the xpubs already derived from the relevant derivation paths, then yes.

Just be careful with hardened paths. You've said m/49/0/4, but I suspect you mean m/49'/0'/4'.

However, so long as I have the output descriptors and private keys fully backed up, I should always be able to sign from this wallet, correct?

-snip- Now, my wallet software has three xpubs, but it may or may not have any idea the derivation paths used to reach the two xpubs from the hardware wallets. But actually, it doesn't need to know. All it needs to do is calculate a child key at /0/0 for each one and combine them in to a multi-sig address.

So it can do seed phrase + m/48'/0'/0'/2'/0/0 to generate the first key itself, and then it can do hardware-wallet-xpubs/0/0 to generate the second and third keys. One it has all three keys at /0/0, it combines them to create an address. It does the same thing at /0/1 and combines the three keys to generate the second address, and so on.

No, it is on. BIP 49 is a multisig derivation path though.

So the derivation path is used both in the generation of the xprvs/xpubs, and also in the generation of individual addresses from those xprvs/xpubs. Allow me to explain.

Take the following familiar derivation path: m/84'/0'/0'.

m stands for your master private key, which is generated from your seed phrase. Technically speaking, this is the only key which should ever be called your master private key, but a lot of people and software also use the term master private key to refer to your account extended private key (which I'll come to in a second).

The next three numbers are, in order, your purpose, coin type, and account. 84 is the number assigned to P2WPKH segwit addresses. 0 is the coin type for mainnet bitcoin. The next 0 simply means the first account. As I explained previously, that derivation path tells your wallet software to generate the extended key at the 85th hardened index,* use that to generate the extended key at the 1st hardened index, and then use that to generate the extended key at the 1st hardened index. The extended key you end up with after doing all that is your account extended private key. Account because it is at the account level, extended because you have an extra part which allows you to continue to derive at further levels. But as I said above, lots of places incorrectly refer to this key as your master private key. When you extract an xprv from a wallet, it is almost always this key that you are extracting - your account extended private key.

Now, to get actual addresses from that key, we need to derive through a further two levels. The derivation path of the very first address in your wallet will look like this: m/84'/0'/0'/0/0. The first extra zero is change (0 for not being a change address, 1 if it is a change address), and then the second extra zero is in the index of the individual address itself.

m/84'/0'/0'/0/0 - 1st non-change address
m/84'/0'/0'/0/1 - 2nd non-change address
m/84'/0'/0'/1/0 - 1st change address
m/84'/0'/0'/1/3 - 4th change address
And so on.

Note that multi-sig sometimes add in an additional field called the script type, so instead of something like m/84'/0'/0' you would have m/48'/0'/0'/2'. (48 is the purpose number for such multi-sig paths, and 2 is the script type for P2WSH.)

So, in the case of HD wallets, you can import keys in two ways. The first is that you can either import a seed phrase, and tell the wallet the exact derivation path you used to get the account extended private key. So for example I could give you the following seed phrase:
Code:
tray expect pact quantum junior chronic nation topple boy today maid syrup
And tell you I used the derivation path m/84'/0'/0', meaning you can calculate the following xprv:
Code:
xprv9zScb44VdRkzpdV8djUnNzD69QWRCA3iMvMm29UaouknnXxH3KRrnpN9QAyzEbqgMSVUVUavpki aWuBhTBpefXXX5kg4tUvSQpd2dDHKFFX
The wallet then knows to start there and add on the extra /0/0 derivations to reach individual addresses.

The second option is I can just give the wallet the xprv directly, and not tell it about the seed phrase or the derivation path I used to get to the given xprv. The wallet will take the xprv and add on the extra /0/0 as above, without knowing the derivation path used to reach that xprv.

Now let's say, for example, I'm setting up a 2-of-3 multi-sig. In this particular multi-sig, I'm using one seed phrase on my computer, and two hardware wallets. Let's say the seed phrase on my computer is using the derivation path m/48'/0'/0'/2'. Great. So my software knows to use this deviation path to calculate the first xprv from the seed phrase it has, and the corresponding xpub. Now my two hardware wallets come along. For the sake of argument, the first uses m/84'/0'/0', and the second uses uses m/0'. What a nightmare! Each hardware wallets generates an xprv at the given derivation path, calculates the corresponding xpub for the xprv, and then feeds the xpub to the wallet software on my computer. Now, my wallet software has three xpubs, but it may or may not have any idea the derivation paths used to reach the two xpubs from the hardware wallets. But actually, it doesn't need to know. All it needs to do is calculate a child key at /0/0 for each one and combine them in to a multi-sig address.

So it can do seed phrase + m/48'/0'/0'/2'/0/0 to generate the first key itself, and then it can do hardware-wallet-xpubs/0/0 to generate the second and third keys. One it has all three keys at /0/0, it combines them to create an address. It does the same thing at /0/1 and combines the three keys to generate the second address, and so on.


*Hardened indices, indicated by the ' symbol, are actually the number you see plus 231, but the reasons behind that are not relevant for this.

I think the fatal flaw in my understanding was that I thought the xpubs were generated solely by the hardware devices and were independent of the derivation path, and that the derivation path specified the receive and change keys from the child xpubs of the devices.

Maybe you have the safety setting "Validate Derivations" disabled that enabled you to use the single-sig derivation paths to MultiSig.

I have no means to test this but you may be able to sign by creating a new MultiSig wallet with the correct derivation paths to the provided extended public keys.

So, given I imported two xpubs from a BIP 49 setup and one from a BIP 84 wallet, then used the derivation path BIP 48 to derive all the receive and change keys, have I just made a huge spaghetti soup that I won't be able to sign?

That's strange, I currently use BIP 49 in a collaborative multisig 3 of 5 setup, and imported it into Sparrow with no issue. I was also able to form a 2 of 3 setup using the same xpubs and derivation path in Sparrow.  

Perhaps.
If those Nested SegWit extended public keys are derived from your master private key with m/49'/0'/0' path,
But used it in a MultiSig setup and provided the standard path of m/48'/0'/0'/1' (BIP48 - Nested SegWit), then your hardware wallet will derive a different xpub key than what you've provided.

What does the descriptor looks like? You can edit the extended public keys for privacy reasons.
BTW, in Sparrow, you can't use the standard derivation path of BIP49 in a MultiSig setup by design.

BTW, in Sparrow, you can't use the standard derivation path of BIP49 in a MultiSig setup by design.