Multisig derivation paths and xpubs

[aesthete2022]

I am having trouble wrapping my head around derivation paths in multisig setups. I had a multisig wallet with the derivation path m/49/0/3 (i.e., each key used that path). I wanted to swap a key to set up a new wallet. I used Sparrow and, even though the new device used the derivation path m/48/0/0/2 and the other two had m/49/0/3, it still generated the multisig wallet (i.e., Sparrow detected no error).

My question is, can each device in a multisig setup have a different derivation path? I always thought every device had to refer to the same one.

[aesthete2022]

My current multisig (with a third-party provider) uses m/49/0/3. I took the derivation paths and xpubs from that and created a smaller multisig quorum, which has signed fine.

[blue Snow]

My question is, can each device in a multisig setup have a different derivation path? I always thought every device had to refer to the same one.

I believe every wallet has a different costume path, so be careful about that. we've discussed it here: https://bitcointalk.org/index.php?topic=5243350.msg54314948#msg54314948

[nc50lc]

My question is, can each device in a multisig setup have a different derivation path? I always thought every device had to refer to the same one.

Technically, it's not an issue since each of your MultiSig Addresses are derived from each cosigner's individual child keys.
The derivation path is just a way to tell the client a way to derive child keys.

Signing wont be an issue either as long as the client know how to derive those child keys from the master key.

As for Sparrow, it's using "Descriptors" to take note of the derivation path for each cosigner master keys.

[o_e_l_e_o]

My question is, can each device in a multisig setup have a different derivation path?

Absolutely.

The derivation path tells your software how to turn a seed phrase in to an extended private key and extended public key. So if you use m/49/0/3, this tells the wallet to derive the extended key at the 50th index, then use that to derive the extended key at the 1st index, then use that to derive the extended key at the 4th index. This final extended key is the xprv/xpub used in your multi-sig wallet.

It doesn't matter if every seed phrase in your multi-sig uses a different derivation path - each one will end up with an xprv/xpub which are combined to create your multi-sig. In fact, the wallet does not even need to know the derivation paths at all. Indeed, there doesn't even need to be a seed phrase in the first place. You could just generate an xprv directly from some entropy source.

As long as you feed it it the same xprvs/xpubs, it will always generate the same addresses, regardless of where these xprvs/xpubs came from.

[witcher_sense]

My question is, can each device in a multisig setup have a different derivation path? I always thought every device had to refer to the same one.

A derivation scheme is just one of the ways to organize the storage or relationship of keys: each key in such a scheme will have its own place within this huge hierarchy, but they all can be derived from the common ancestor. The entropy (single signature wallet) or a bunch of entropies (multi-signature wallet) serve as an entry point from which to generate information needed for wallet creation and signing of transaction data. While you are absolutely free to determine how initial entropy and derived keys should relate to each other, it is advisable to follow standards described in BIPs and similar specifications because this helps wallet software to remain interoperable and interchangeable.

[aesthete2022]

Ok, so I'm learning through doing here. I took what I know to be valid xpubs from my three keys and used the derivation path for nested segwit. However, I can't sign from that quorum. I'm thinking this is probably because the xpubs I am using were not generated by the derivation path I specified?

[blue Snow]

Ok, so I'm learning through doing here. I took what I know to be valid xpubs from my three keys and used the derivation path for nested segwit. However, I can't sign from that quorum. I'm thinking this is probably because the xpubs I am using were not generated by the derivation path I specified?

You can't sign because you don't have the private key, So is not because of different xpubs or public keys.

[aesthete2022]

I have the master fingerprints, so could sign. That’s not the issue. The private keys are stored in my hardware wallets.

[nc50lc]

I took what I know to be valid xpubs from my three keys and used the derivation path for nested segwit. However, I can't sign from that quorum. I'm thinking this is probably because the xpubs I am using were not generated by the derivation path I specified?

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.

[aesthete2022]

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.

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.

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?

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

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.  

[nc50lc]

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?

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.

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

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.  

I checked and that safety check can indeed be disabled.
Maybe you have the safety setting "Validate Derivations" disabled that enabled you to use the single-sig derivation paths to MultiSig.

[aesthete2022]

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

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

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.

I think you're right. The $30 locked in that wallet is the cost of tuition.

[o_e_l_e_o]

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.

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:

xprv9zScb44VdRkzpdV8djUnNzD69QWRCA3iMvMm29UaouknnXxH3KRrnpN9QAyzEbqgMSVUVUavpkiaWuBhTBpefXXX5kg4tUvSQpd2dDHKFFX

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 2³¹, but the reasons behind that are not relevant for this.

[aesthete2022]

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.

Wow, thanks for this. I think I'm going to have to read it taking notes several times.

[nc50lc]

-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.

...And this is where some "signing issue" came from.
This setup can generate address without any issue, good enough for watching-only wallets.

Problem is, hardware wallets need to know the derivation path to be able to sign the transactions linked to the provided xpub.
This is why MultiSig descriptors with hardware wallets starts from "m" and not directly from xpub.
Ref: github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#bip32-derived-keys-and-chains

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

BIP49 is for Nested-SegWit Purpose field but most wallets aren't strict on the derivation path used.
Since it's still set 'on', then the path must have been different from the single-sig Nested-SegWit default m/49'/0'/0' and higher account index which Sparrow wont accept for MultiSig. (test it)
(or maybe it was setup in older versions when the feature isn't implemented yet)

[aesthete2022]

Just revisiting this topic for verification/reassurance.

As my (thoroughly backed up and tested) keys are geographically distributed, I have used the derivation path (m/49/0/4) and xpubs derived by my collaborative custodian to create a 2 of 3 fully self-sovereign multisig. It signs fine. My one concern is that I'm using a non-standard derivation path (I would have preferred to have used m/84/0/0). 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?

[o_e_l_e_o]

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?

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'.

[aesthete2022]

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'.

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).

[o_e_l_e_o]

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

Not necessarily, no. It depends where you get the xpubs from.

If you are using the xpub already at m/49'/0'/4', then it will derive the right addresses. If you are using the xpub at m, then you will need to specify the derivation path.

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).

m/49 is unhardened. m/49' is hardened. 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.