Which hardware wallets require importation of PSBT for knowledge of multisig set up?

Question

My understanding of a multi-vendor multisig is that certain wallets require importation of the resultant multisig wallet's PSBT information in order to sign multisig transactions. Coldcard's documentation indicates that it requires this import of the info, but do other wallets? Specifically:

1. Trezor
2. BlockStream Jade
3. Seedsigner

Additionally, why do some require this and others not?

To be clear, I already understand that the output script descriptor of the x of n keys are needed to recover funds, but here I am asking about the specific need to import the PSBT into the x wallets so that they 'know' about the multisig.

Edit:

Jade's documentation suggest that it does require notification. Only seedsigner does not?

This documentation (walking through a Coldcard, CoboVault, and Seedsigner multisig set up) has steps for 'notifying coldcard' and 'notifying Cobo' but none for 'notifying seedsigner'. Does this mean seedsigner does not need to notified about the multisig?

Answer 1

One of the tasks of a signer is to determine whether it should sign something. There are a few different schools of thought on what should be done for this determination, however many hardware signers follow the pattern of parsing the transaction to be signed, showing it to the user, and asking the user for confirmation to sign it.

Even with many wallets doing this basic pattern, they still do some things differently, such as what information should be shown to the user, and what can be assumed about the user. Generally, the assumption is that the user is not technical and so as much technical information needs to be elided or otherwise separately verified by the signer to be safe.

For example, a technical detail that is often hidden is that transactions have change outputs. One of the most basic things for a hardware signer to do is to show the user all of the addresses that will receive Bitcoin in the transaction and the amounts that they will receive. But most users don't know about change outputs, or they don't know what change address is theirs. Showing the user the change output may confuse them, so the hardware signers will determine which outputs are change so that they do not need to show them.

But how can a hardware signer determine which outputs are change? For single sig scripts, this is easy as the hardware signer can generate the key for the script, and by assuming that anything that it can sign for is change, it can find the change outputs.

However for multisigs there will be keys that it does not know nor can generate. For multisig inputs, it needs to be told the script (and therefore the other keys). It needs the same for any outputs that are change. But even if it can produce the change output, how does it know that it actually is the change output? How can it be sure that there wasn't malware that swapped out some of the keys for an attackers?

Some hardware signers deal with these questions by requiring the user to have registered the multisig on the device before they sign any transactions involving it. The user provides the multisig threshold as well as xpubs of the involved keys, and the order they should appear. The wallet may store this or they may provide a signature of sorts that would later prove to the device that it had been pre-registered. Then during signing, it can look at that multisig information in order to determine which output is change.

Other wallets do not necessarily need this information and instead try to figure out the change from the transaction itself. A PSBT can contain enough information to figure it out. The signer can look at the inputs, determine the threshold and the xpubs of the multisig from the inputs, then check if any of the outputs match that. Thus they can determine the change output.

Change output detection is not the only problem. Some wallets want to do further verification to ensure that users are not accidentally losing funds. Suppose the user is participating in multiple multisigs. Some hardware signers want the user to make sure that the user knows which multisig they are spending from. This requires such devices to store the multisig or have be able to verify a commitment to it, and so require registering the multisig before signing.

There are also other wallets that simply don't care to verify and show this information to the user, and may just blindly sign anything that they can. It all depends on the security model that the hardware vendor is trying to go for.

Here are is a non-exhaustive list of hardware signers that require registering the multisig:

• Ledger (Bitcoin App 2.0+)
• Coldcard and clones
• Jade
• BitBox02

Some hardware signers that do not require registration:

• Ledger (Bitcoin App 1.x)
• Trezor and clones
• BitBox01

I don't know about the seed signer, but from the documentation I can find, I think it does not require registration.

It's important to know that this is all just implemented in software on the devices that can be updated. As you can see in the list, Ledger has changed from previously signing anything, to requiring registration in order to sign. Other signers may choose to implement registration as well.

Answer 2

SeedSigner doesn't require that the multisig wallet descriptor be pre-loaded into the device. In fact, because there's no onboard persistent storage, anything loaded would be forgotten once it was powered down anyway.

But it is strongly recommended that you scan in a "known-good" copy of your descriptor when reviewing a psbt.

If the descriptor can't generate the same change address, you get a show-stopping warning that prevents you from proceeding. This would only happen if your software coordinator had crafted an "evil" psbt that was attempting to steal your change.

Note: this also applies for any receive addresses for your wallet if you're doing an internal cycle/consolidation back to yourself.

What is a "known-good" descriptor?

This whole optional step of scanning in your descriptor is a safety measure to help protect you from a compromised, "evil" software coordinator constructing a malicious psbt for you to sign.

The basic scenario you have to have in mind is:

• I created as secure an environment as possible when installing my software coordinator (e.g. Sparrow, Specter Desktop, Nunchuk, etc) and then used it to create my multisig.
• At some point later, my software coordinator was compromised and is now controlled by an attacker.
• I use the compromised software to construct a transaction that will steal some of my funds.

In this scenario, when SeedSigner offers to verify the change (or self-spend receive) address, if you scan the wallet descriptor straight from this theoretically now-compromised coordinator (e.g. in Sparrow, going to the wallet Settings and clicking the QR icon next to your Descriptor), it's just going to lie to you some more and provide a matching "evil" descriptor that will verify just fine in SeedSigner.

You're essentially being duped into confirming: Yes, the "evil" change address really does belong to this "evil" wallet that I don't actually control.

Instead, when creating the multisig in your initially secure environment, you need to backup the resulting wallet descriptor right then and there. If your initial environment really was sound, then you can be assured that this backup really describes the wallet you just created. Sparrow and Specter Desktop even provide printable pdfs of the backup/descriptor that include the descriptor as a QR code that SeedSigner knows how to read.

This backup saved at this stage is your "known-good" copy of the descriptor (again, all hinges on your initial environment being clean).

I print this pdf backup and keep a paper copy with each geographically distributed key. I also keep digital copies of it in various local and cloud vaults (note: the descriptor is a potential privacy leak--anyone who has it can see all your past and future transactions--but it doesn't contain any private key info and so it isn't a security risk; the descriptor alone can't be used to steal any funds).

No matter how compromised my system becomes after this, it doesn't matter since the attackers cannot alter what's on my "known-good" descriptor print out (ignoring real-world ninja/spycraft infiltration!).

If they try to get me to sign an "evil" psbt, my "known-good" descriptor will raise the alarm that the proposed change/receive address is not actually owned by my wallet.