Quote from: o_e_l_e_o on June 29, 2023, 01:07:25 PM

-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 the "signing issue" came from.
This setup can generate address without any issue, good enough for watching-only wallet.

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

Quote from: aesthete2022 on June 29, 2023, 12:11:06 PM

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)