Feature Request: Temporarily cache multi-sig wallet configuration on device and allow users to select it during transaction signing.

[austinvach]

I've been playing around with multi-sig vaults on Blue Wallet and I'm using SeedSigner to manage all the keys. Everything works well until I try to send from the multi-sig wallet.

The Context: Once you enter a receiving address and amount to be sent, Blue Wallet displays a screen asking for the required number of signatures. After clicking "Provide signature" under a specific key (see here for a visual), Blue Wallet generates a QR code that needs to be scanned by the SeedSigner. Once scanned, SeedSigner shows the transaction info but can't confirm the change address until you scan the multi-sig configuration information.

The Problem: In order to get back to the multi-sig configuration information in Blue Wallet, you need to back out of the current transaction which means it's not possible to confirm the change address without scanning that info from a QR code that you've saved outside of Blue Wallet.

The Feature Request: Allow users to scan multi-sig configuration information into the SeedSigner and temporarily cache that information so that it can be referenced during transaction signing.

Does that make sense?

Thank you all for your work on this project. It's awesome.

[austinvach]

CC: @DesobedienteTecnologico. I've ported this over from https://github.com/SeedSigner/seedsigner-os/issues/42#issuecomment-1523821245

[kdmukai]

This does make sense, however: the point of the change/receive addr verification is that you shouldn't blindly trust the transaction being created by your coordinator software. Imagine that your BlueWallet was somehow compromised and it was sending your change to an attacker's address instead of using one of your actual change addresses.

But if you "verify" the addresses using the same (compromised) software, it can just lie to you again.

You should ideally create the wallet and export the wallet descriptor/backup before any funds are loaded. That descriptor is your "known-good" copy: you verify for yourself that its xpubs really match your actual multisig keys. That "known-good" descriptor should be stored and set aside; that's what you should be scanning in order to verify your addresses. This way even if your BlueWallet is compromised at some point after creating your multisig, your "known-good" descriptor will catch the lie ("this is NOT one of your change addresses!").

Different wallet software have different ways to back up the wallet descriptor. Some of the desktop options can directly generate it as a QR code for you. You can also just paste the descriptor string into any QR code generator (note privacy implications below) and use that. Then I just print the descriptor QR and store a copy with each signing key.

Note that if your descriptor leaks, someone could see all your future transactions, but it only has public key info so they still wouldn't be able to spend/steal your funds. So I don't mind sending it to a printer, but I wouldn't take a photo of it or store it in the cloud. If you need to use a QR code generator, using an offline one is obviously better than sending your descriptor data through an online one.

[austinvach]

Good point. Thanks for the reply.

[thashm]

If we can create a verified descriptor backup/hardcopy that we can scan every time we need to send or receive a transaction, can we then introduce a feature for the seed signer to verify receive and change addresses against the descriptor?

Apart from buying an old thinkpad and removing the cellular and wifi chip, harddrive and battery, using tailsOS, and never using this laptop for anything else or ever connecting it in the future to the internet or using it for anything else, and then running an offline saved html of ian colemans bip39 page, typing in the seeds of each co signer + passphrase and using this to verify the xpubs of each cosigner, to ensure the descriptor is correct that was generated from the wallet software initially (sparrow or specter), what other way is there to verify the xpub hardcopy initially?

[jdlcdl]

...a feature for the seed signer to verify receive and change addresses against the descriptor

Unless I'm missing something, this seems like a good idea and a reasonable request. I'm going to look into this.

Did you know that for multisig wallets, you can already use Address Explorer (for manual verification, not ideal i know) by going to Tools / Address explorer / Scan wallet descriptor? (Must enable Address Explorer in Advanced Settings first).

Others, please chime in if this seems like a bad idea, but my thoughts are:

• Verify Address as a feature feels a little "unfinished" without being able to do so having only the wallet descriptor.
• Address Explorer does too, for similar reasons.
• Both would be, in my mind, valuable "plausible deniability that a seed backup is nearby" use cases, so I support any real world use cases that allow someone to be using seedsigner while their seeds are not in the immediate vicinity.

[bitcoinheiro]

Would be great to be able to store the coordinator backup (descriptor of the multisig wallet) to the microSD flash storage. This could also serve as a backup of the setup to that cosigner. Quick scan the coordinator, confirm fingerprints, store to flash for quick recovery when needed.

[SeedSigner]

I think that story a copy of the coordinator backup / multisig descriptor on the MicroSD is a reasonable idea, given that the information is private but not secret. However I believe it should always be stored in another location / format, preferably analog. At boot, the wallet descriptor(s) could be loaded into memory, and the microsd card removed as usual, with them on-board for the session. The tricky part is how to update the software on the microsd card without over-writing the descriptor, and ideally user settings would persist as well. This considerations are a bit beyond this issue, but those are my 2 sats.

[bitcoinheiro]

The tricky part is how to update the software on the microsd card without over-writing the descriptor, and ideally user settings would persist as well.

I was under the impression that with the current version I could remove the microSD after boot and just insert another microSD to store/retrieve the information when needed (@DesobedienteTecnologico) - the simplest way would be to be able to do this after boot, in separate sd media that can be hidden for privacy

[DesobedienteTecnologico]

The tricky part is how to update the software on the microsd card without over-writing the descriptor, and ideally user settings would persist as well.

I was under the impression that with the current version I could remove the microSD after boot and just insert another microSD to store/retrieve the information when needed (@DesobedienteTecnologico) - the simplest way would be to be able to do this after boot, in separate sd media that can be hidden for privacy

Actually you can use another MicroSD to store data there. The unique requirement right now is to have a FAT32 partition MicroSD.

If I'm right you can try right now to store your settings in another MicroSD: https://github.com/SeedSigner/seedsigner/blob/49ea8a21926169a942f0c795c94b733b87b74d55/src/seedsigner/models/settings.py#L13-L1

1. Boot SeedSigner
2. Swap the MicroSD for a new empty one
3. Enable persistent data
4. Add some new config, like Testnet
5. Poweroff
6. Plug your MicroSD in your PC and check if the file was created in that MicroSD

Hope it helps.