Unusual multisig change path warning using Jade with Sparrow wallet

[georgantas]

I've set up a 2-of-3 multisig using 3 Jades and Sparrow wallet. When I try to sign a transaction to spend from the wallet, I get a warning message: Unusual multisig change path.

Sparrow wallet uses path ../1/0 for the change, which I believe is standard. It also uses m/48'/0'/0'/2' as derivation paths.

[JamieDriver]

Hi,
Yes, I think you may be right, in that the check for 'expected path' may not be correct for multisig bips 48 and 87.
We intend to warn if the path deviates from bips 45/48/87, but I think atm the checks are perhaps not quite right and maybe we always test for 'cosigner_index' as per bip45, even when that is not appropriate.
I will look at this over the next few days and will endeavour to get the corrections into the next fw release.
Many thanks.

[JamieDriver]

Just to confirm, does the warning only appear for 'change path' when signing ? Do you have the full path ?
Does Sparrow support showing your own receive address on the Jade hw - and if so does that also show a warning ?
Cheers.
ps. also, do you/sparrow use sortedmulti() ?

[JamieDriver]

Looking at the bip48 spec, I assume you mean derivation paths m/48'/0'/0'/2' registered in the jade multisig registration + 0/n (or 1/n for change) ?
I really need to know what paths Sparrow is registering as part of the multisig registration process, and what it is passing as 'change paths' at signing time - because if it is just passing '1/n' I would not expect that warning.
Can you see that sort of info in sparrow's logs ?
Thanks.

[JamieDriver]

apologies! closed in error!

[georgantas]

does the warning only appear for 'change path' when signing

• The warning appears for the change path while trying to send coins. If there is no change, the warning does not appear. The warning is: Warning: Unusual multisig change path. Proceed at your own risk.

• A warning is also shown when displaying the change address on the device (in other words, an ../1/n address). The warning is different: Warning: Unusual multisig path. Proceed at your own risk.

• No warning appears during multisig registration, nor while showing a regular receive address (in other words, an ../0/n address).

Do you have the full path ?

The full paths are m/48'/0'/0'/2'/<0 for wallet, 1 for change>/n.

From Sparrow UI:

Wallet address derivation path (no warning when displaying this address on the Jade):

Change address derivation path (warning when displaying this address on the Jade):

Does Sparrow support showing your own receive address on the Jade hw - and if so does that also show a warning ?

Yes, this is supported, but a warning only appears when showing a change address.

ps. also, do you/sparrow use sortedmulti() ?

Yes, Sparrow will register a sorted multisig. On the Jade, I see Sorted: Y.

Looking at the bip48 spec, I assume you mean derivation paths m/48'/0'/0'/2' registered in the jade multisig registration + 0/n (or 1/n for change) ?

Yes, correct.

I really need to know what paths Sparrow is registering as part of the multisig registration process, and what it is passing as 'change paths' at signing time - because if it is just passing '1/n' I would not expect that warning. Can you see that sort of info in sparrow's logs ?

m/48'/0'/0'/2' shows up on the Jade during registration with Sorted: Y.

Trying to pull some logs now.

[georgantas]

Not sure if this is helpful, but I ran bitcoin-cli decodepsbt <psbt_produced_by_sparrow_which_I assume_is_sent_to_the_jade_for_signing_through_hwi>, and I see in the json returned:

"outputs": [
    {
      "witness_script": {
        "asm": "2 <redacted> <redacted> <redacted> 3 OP_CHECKMULTISIG",
        "hex": "<redacted>",
        "type": "multisig"
      },
      "bip32_derivs": [
        {
          "pubkey": "<redacted>",
          "master_fingerprint": "<redacted>",
          "path": "m/48'/0'/0'/2'/1/2"
        },
        {
          "pubkey": "<redacted>",
          "master_fingerprint": "<redacted>",
          "path": "m/48'/0'/0'/2'/1/2"
        },
        {
          "pubkey": "<redacted>",
          "master_fingerprint": "<redacted>",
          "path": "m/48'/0'/0'/2'/1/2"
        }
      ]
    },
    {
      "witness_script": {
        "asm": "2 <redacted> <redacted> <redacted> 3 OP_CHECKMULTISIG",
        "hex": "<redacted>",
        "type": "multisig"
      },
      "bip32_derivs": [
        {
          "pubkey": "<redacted>",
          "master_fingerprint": "<redacted>",
          "path": "m/48'/0'/0'/2'/0/10"
        },
        {
          "pubkey": "<redacted>",
          "master_fingerprint": "<redacted>",
          "path": "m/48'/0'/0'/2'/0/10"
        },
        {
          "pubkey": "<redacted>",
          "master_fingerprint": "<redacted>",
          "path": "m/48'/0'/0'/2'/0/10"
        }
      ]}
  ]

[georgantas]

It seems this may be related to the fact that my transaction is a redeposit to myself with change. I created a new transaction, sending to an address I don't own, and I didn't get the warning (made sure the transaction included change).

It's not immediately obvious why the warning shows up because I see that the send and change addresses are correctly picked out by the Jade. '../0/10' is shown as the singular output in the confirmation screen, and '../1/2' is hidden meaning that it's correctly picked up as the change address.

[JamieDriver]

OK, Yes we have seen similar with other 'companion' code and I think I can guess what is happening ... I am not sure whether the problem is Jade's, really, but am open to suggestion ... ok, here goes ;-) :

• The wallet can tell Jade something like: 'output 2 is a p2wsh change address to path (suffix) [1,13]' - in this case Jade will internally verify that if it generates the script-pubkey for that path, it gets the same script as that in the tx output (if it doesn't match the 'sign' action will fail).

• Jade issues the red warning you have seen if either a) the penultimate index is not '1' - for change outputs Jade expects /1/n, or b) if the last element (n) is more than 10,000

Now, I suspect what is happening here, is the wallet is flagging the redeposit output as change - ie. it may be using something like: tell_jade_is_change := (output.fingerprint == this_wallet.fingerprint)
ie. you generate a /0/n address, you send funds to this /0/n address, but the wallet is flagging it as change (as it is an address owned by your wallet). Jade then prints the warning because it is being told the /0/n address is 'change' - which it thinks is 'unusual' ...
[...and breathe]

NOTEs:

• Send to [external address] then works as expected, as only the actual 'change' address is owned by this wallet and so flagged as 'change', and it can be auto-verified (no need to show to user), and the path is indeed '.../1/n' as expected, all good ...

• If the wallet asks Jade to generate/confirm/display etc. an address, Jade assumes this is a 'receive' address (ie one you may give to a counterparty) so it warns if the path is not .../0/n.

Does all this sound consistent with what you are seeing ... I think so ...

[georgantas]

If this is the case, would the issue be in HWI? From my understanding, the wallet (Sparrow) just calls the sign_tx(psbt) ref, right? (and then HWI translates that to device commands)

One strange thing about this though, is that it does seem like the Jade knows what's change and what's redeposit at the signing screen. On the confirmation screen, it shows the output as being the redeposit address, and the change address is hidden (meaning it's detected as the change address), and yet the warning shows up.

[JamieDriver]

Yes indeed - The [actual] change address is not the issue - it has it has a /1/n path as expected, and since Jade can 'rebuild' the script/pubkey/address from the path given, it is all auto-verified and not shown to the user at all. No problems there.

The issue is the redeposit address, which has a /0/n path BUT has been flagged as a change output by the wallet.
Jade thinks this alleged 'change' output looks suspicious, and so shows it to the user, with a warning about it being 'unusual'.

FYI Jade itself does not 'detect' that it is a change output - the wallet app tells Jade it is change, and Jade internally confirms that indeed the given path creates the given output script/pubkey/address.

If this wallet is using hwilib, then yes, the issue would be caused by HWI guessing what is change, using the 'matching fingerprint' method described above.
I wonder what tomfool added that !? ;-o

[georgantas]

Lol!

That makes sense. Thank you for investigating. 🙂

[JamieDriver]

Options:

1. change HWI so it only flags .../1/n paths as 'change'.
   con: This would then not 'auto-verify' any change output not using that convention - as as HWI is not the actual wallet (just the hww 'interface' layer), it doesn't actually know what is change and what is not... so has to make an 'educated guess'.

2. change jade to not warn about /0/n and /1/n being change or not - maybe just treat it as 'ok' so long as that element is 0 or 1 (or maybe even if it is less than some ceiling ... regardless of whether it is 'change')
   con: this is slightly less strict checking [does that matter?]

3. Do nothing
   con: redeposit txs will show that warning, esp. if the wallet is using HWI or the wallet uses the same 'fingerprint matching' scheme to determine what is 'change'.

[georgantas]

I see that the change parameter passed into the Jade is similar to the outputs parameter of the PSBT. I think it might be good to simply pass that PSBT information through (option 2).

[georgantas]

An additional benefit of option 2: The jade would also be able to mark the output address as a "redeposit" directly on the signing screen (instead of requiring the user to first display the address, and then make sure it matches the output address on the signing screen).

[JamieDriver]

I have recently made a PR to HWI which should address this issues - ofc we have to wait for HWI to take them, release, and then Sparrow to upgrade HWI ...
See bitcoin-core/HWI#753

[georgantas]

Amazing, I’m really looking forward to the next HWI release.