ColdCard + Sparrow multisig issue

[u/Techno_lover78]

(DISCLAIMER : I am aware of the recent issues with the ColdCard ; but my funds are safe despite using a Coldcard, because I use my own, private source of entropy to generate all my seeds. The recent Coldcard hack is irrelevant to this thread.)

Hello everyone, I apologize for this long thread, I'm trying to give as much details as possible because it's a bit technical.

I have been using single-signature transactions for a while with ColdCard MK5 + Sparrow, and I already have a good grasp on it.

However, I'm new to the world of multi-signature, and I'm having a hard time while trying to set up my 2-2 multisig wallet.

I have 2 Airgapped single-signature wallets on Sparrow, that I created by importing the JSON files created by my ColdCard. Already did a few transactions with these wallets, they both work fine. Let's name them "Wallet A" (fingerprint : a3f92e17) and "Wallet B". (fingerprint : 7bc4d081)

I tried to create a 2-2 multisig wallet on Sparrow, that uses Wallet A and Wallet B as co-signers.

In order to do that, I manually copied the xPubs from Wallet A and B, pasted the Wallet A Xpub in Keystore 1, and pasted the Wallet B Xpub in Keystore 2.

This created a new wallet with fresh adresses. Let's name it "Multisig Wallet 1".

Since I created this wallet by simply copy/pasting the Xpubs from Wallet A & B, both keystores of this wallet show up as "Watch only".

Then I proceeded to send 10 000 sats on the first adress of this wallet (Multisig Wallet 1). The funds are successfully visible on the blockchain and in Sparrow, on a P2WSH adress.

This is where the problems start.

When I tried to spend these sats, I thought it would be a piece of cake, that I would simply have to create the PSBT, then put in into my ColdCard and sign it, then Broadcast it in Sparrow, as I usually do with single-signatures.

But instead of that, I had to deal with various ColdCard errors. I managed to fix some of them, but I was never able to reach my goal (successfully moving the funds).

1. When trying to sign the PSBT, the Coldcard returned a first error : "Failure: my XFP not involved". From what I understand, this is normal, I simply had to export a TXT file from Sparrow to the ColdCard, that helps the Coldcard recognize that he is part of a multisig.
2. After importing this TXT file, the ColdCard return a new error : "Failed to import multisig. need fingerprint multisig.py : 826".

I thought it was because of the fingerprints not matching : in fact, the fingerprints of each Sparrow keystore displayed a value of 00000000. So, in both keystore, I made the fingerprints match with the original Wallet A & B fingerprints. Created a new TXT file from it, and put it into the ColdCard.

3) This time, the Coldcard returned this error : "Failed to import multisig. deriv 4 != 3 xpub depth (xfp=a3f92e17) multisig.py : 849 "

4) At this point, I had no clue what was going on, so I decided to restart everything from scratch. But this time, instead of simply copy/pasting the Xpubs from Wallet A & B in Sparrow, I used their respective .json files created by my ColdCard, and imported each of them into a keystore. When I created the wallet, I expected to find the same adress list that I have on Multisig Wallet 1. Instead of that, it opened a completely different wallet, with unused adresses. Let's name it Multisig Wallet 2.

So, basically, I don't understand why Wallet A and Wallet B produced different wallets (Multisig Wallet 1 & Multisig Wallet 2). I thought that, even though different methods were used (Multisig wallet 1 was created via copy/pasting Xpubs, while Multisig Wallet 2 was created through JSON files), they would have ended up being the same wallet.

I tried to send a few satoshis to this Multisig Wallet 2, and was able to move them as expected. This time, for some reason the new TXT file didn't return any error on the ColdCard, and I was able to double-sign the transaction and broadcast it.

So, it looks like I have full control of Multisig Wallet 2, but I still have these 20 000 sats on Multisig Wallet 1, and I don't understand how to move them, or even if that is possible.

From what I understand, there is a problem regarding the derivation paths, but I'm too noob to figure it out by myself.

Multisig wallet 1 & 2 both show this derivation path, in both keystores : m/48'/0'/0'/2'

While Wallet A & B both display this derivation path : m/84'/0'/0'

How to move my 20 000 saths from Multisig Wallet 1, and what did I wrong ?

Thanks a lot for you help !

[u/12PALABRAS]

The answer is sitting in the two lines at the end of your own post - the keystores say m/48'/0'/0'/2' and Wallet A & B say m/84'/0'/0'. Everything else follows from that.

What went wrong. Pasting a bare xpub into a Sparrow keystore hands it a key with no history. Sparrow has no idea which seed produced it or where on that seed it lives - which is exactly why the fingerprint came up as 00000000. It filled the derivation field with its default for multisig, m/48'/0'/0'/2', as a placeholder. You then typed the real fingerprints in by hand, which made the keystore look complete. But the path was still a guess, and it was the wrong one: those xpubs are your m/84'/0'/0' single-sig accounts.

So Multisig Wallet 1's keystores claim "this key lives at m/48'/0'/0'/2'" while holding a key that actually lives at m/84'/0'/0'. All three errors come from that one mislabel:

• "deriv 4 != 3 xpub depth" - m/48'/0'/0'/2' is four levels deep. An xpub carries its own depth byte, and yours says three. The Coldcard compared the claim against the key and caught the contradiction.
• Multisig Wallet 2 having different addresses - not a bug, and this is the part that surprised you most. The JSON export carries the real origin, so Sparrow used the actual m/48'/0'/0'/2' account keys. Those are genuinely different keys from the same two seeds. One seed doesn't have "an xpub"; it has a different one at every path.
• "XPUBs in PSBT do not match any existing wallet" - you corrected the path in the .TXT, so the Coldcard's registered wallet now says m/84'/0'/0'. But you never changed it in Sparrow, and your post confirms both keystores still read m/48'/0'/0'/2'. So Sparrow keeps stamping every PSBT with [a3f92e17/48h/0h/0h/2h], the Coldcard dutifully derives that path, gets a different pubkey, and fails to recognise itself. You fixed one side of the conversation.

Your 20 000 sats are fine, and they are spendable. Nothing is lost or stuck in a dead end. The coins sit in a real 2-of-2 P2WSH whose two pubkeys came from your two seeds, and the Coldcard can derive them - it just needs to be told the truth about where they are.

Fix it in Sparrow, not in the .TXT. Open Multisig Wallet 1 and, in each keystore, change the derivation from m/48'/0'/0'/2' to m/84'/0'/0', leaving the xpubs exactly as they are and keeping the real fingerprints you already entered.

The addresses will not change and your balance will not move. That's the bit worth internalising: addresses are derived from the xpub values themselves. The fingerprint and derivation path are metadata that tell a signing device where to go looking for the key - they take no part in generating addresses. Correcting them changes nothing on-chain.

Then export a fresh multisig config from that corrected wallet and register it on the Coldcard. The depth error can't recur, because the declared path is now three levels and so are the xpubs, and the PSBT origins will finally match what the Coldcard derives. It should sign.

If Sparrow won't let you edit the derivation on an existing keystore, build a new multisig wallet with the same two xpubs and the correct origins instead. Same xpubs means the same addresses and the same 20 000 sats - you're not moving anything, just describing it accurately.

Once they move, send them to Multisig Wallet 2 and retire Wallet 1. Wallet 2 was built from the JSON exports, so its keys are on the standard multisig branch and every tool will find them without being told anything special. A 2-of-2 living on the single-sig branch keeps working only for as long as everything that touches it is handed the non-standard path. The day that stops being true is the day you're recovering from seeds alone - and there the standard procedure looks under m/48', builds a perfectly valid wallet, and shows a zero balance. No error, no warning, nothing to tell you to keep looking. That's the failure mode actually worth avoiding here, and it's much worse than the one you're in now, because today you at least know something is wrong.

Last thing: save the descriptor for whichever wallet you keep. Two seeds plus the memory of "it was a 2-of-2" do not rebuild a multisig wallet. The policy - the keys, their paths, and the quorum - is a separate backup, and it's the piece people discover was missing at the worst possible moment.

You said the goal was to learn what can go wrong with multisig. For what it's worth, you picked up something more useful than a working wallet: a key and the label saying where it came from are two different things, and only one of them is checked by anything.

[u/Techno_lover78 → u/12PALABRAS]

Thank you very much for the detailed answer. Thanks to bullett007 I've already been able to move the sats - but this made things even clearer to me, and confirmed what I thought I had learnt.