I’m interested in doing a 2 of 3 multisig with a passphrase applied to every seed. Is this possible with passport?
1 Like
Hey @atori welcome to the community!
When you apply a passphrase you essentially create a new wallet, so anything you can do on the regular, unpassphrased accounts, you can do in the passphrased accounts too - and this includes setting up a multisig.
However, I don’t think many people will recommend it because it is the perfect storm of things that can go wrong. You will have to do a backup of every seed, plus a backup of every passphrase in physically different locations, and make sure you double and triple check XFPs every time you try to send or spend money to/from the multisig. I think it’s safe to say this is very much a reckless setup, even for advanced users.
That being said though, and all warnings aside, yes, it can be done. When setting up your multisig in Sparrow for example, instead of using the seed from your passport directly, type in the passphrase on your passport first, double and triple check you take note of the passphrase and the XFP, and then proceed to pair to the Sparrow multisig setup like you would normally do. From the primary account go to Manage account, Connect wallet, Sparrow, Multisig. Do this for all three passports (or for all three seeds+passphrases) and you will have your multisig account set up.
Also please make sure to back up the multisig config!
1 Like
Hi, the question is really, if I then import the multisig into the Passport, is it stored after clearing the paasphrase?
Or do I have to import the multisig wallet every time I want to spend?
That will depend on the multisig policy you set up. By default after version 2.3.2, new Passport wallets default the multisig policy to Ask to Import, but if you set up your wallet before then you might have Require Existing selected.
To change this policy head to Settings → Bitcoin → Multisig → Multisig Policy. The options are:
Ask to import: Every time you scan a multisig tx in order to spend, Passport will check if this configuration already exists in your wallet. If it does, it moves forward to the signing flow, if it doesn’t it asks you whether you want to save this config. Regardless of your choice, you can then move on to the signing flow.
Require Existing: When scannig a multisig tx you are part of, Passport will check if you have the config saved. It won’t let you move forward and will fail with an error if you don’t already have it imported. You will need to import it and save it if you want to sign any transactions.
Skip Verification: Passport will NOT check for an existing config file and you will always be moved on to the signing flow.
You can select any of these, and the setting remains selected from that point on, even after you apply a passphrase. Besides, passphrase accounts “remember” their specific multisig configurations, so if you apply a passphrase, then import a multisig configuration, this will be saved and displayed ONLY when you type in that passphrase. Without passphrase you won’t be able to see your passphrase’d wallets’ multisig configurations.
The last part is important, pretty brilliant that multisig config will be remembered when importing it with a passphrase applied.
I understand that it increases complexity, but right now only have backups in encrypted electronic form. Clear text seed backups freak me out but so relying on electronic media. Having a passphrase as a last line of defence would give me more peace of mind having steel backups.
PS: isn’t a security threat to sign without having the multisig imported?
If you feel comfortabe with this setup then go ahead, just be very careful with your backups.
Regarding the security threat - that was the idea behind defaulting to Require Existing, you must have willingly added a multisig setup before signing a transaction. However, in reality this ended up being more of a burden than a safety measure for most of our users.
Most people use a tool like Sparrow to build the multisig, and while you are prompted to import the multisig configuration right after scanning passport’s QR into Sparrow, the reality is that the multisig setup only ends after you pair and define all the wallets to Sparrow, and then after manually going to Settings and clicking Export. At that point, Passport might already be shut down, since the time you needed to set the other wallets was likely greater than the autoshutdown feature. This meant that most of our multisig users skipped all the manual steps needed after the wallet was set up, “the wallet has already been set up after all”.
At the end of the day, most of the scenarios where a user IS part of a multisig but does NOT have the config file saved are due to legitimate human errors. This is why we defaulted to Ask to Import on 2.3.2. Besides, think of the attack you describe. Performing an attack where a user signs a transaction out of a multisig configuration their seed actually belongs to, but they were not aware existed and somehow has the user’s funds, requires a level of social engineering and/or access to the device that escapes most real scenarios. At that point you might just steal their seed. Or, if they defaulted to Require Existing, you could have cheated them into importing the rogue wallet’s config file making them think it’s a different thing, or just into changing this setting to Skip Verification. If you have enough power over the victim to successfully perform the attack you mention, defaulting to Require Existing won’t do much to save them.
This setting is helpful for people that work with multiple multisig wallets, multiple passphrasses, and multiple devices, maybe some fund manager or something, where it might be very important to know what passports belong in which of the multiple multisigs you might have, and if something si not 100% correct you get an error and extra friction.
So, reastically, people just forget to add their configuration file, and we now default to asking whether they want to import or not, and asking whether they want to sign or not. It just reduces friction to 99.99% of the users, without practically compromising on security.
Hope this makes sense!
2 Likes