Hi Hugo,

First of all, thank you for the impressive work on leading the standardization efforts!

I believe one ought to more clearly distinguish the "Signer" (as in: one of the parties in the multisig setup), from the "Signing device" (which is likely a hardware wallet).

BSMS defines a "Signer" as "a participating member in the multisig",  therefore a person/entity who is likely using both a hardware wallet and some BSMS-friendly software wallet (e.g. the next version of Specter Desktop).

It is therefore relevant to discuss which parts of the BSMS mechanism are implemented in the Signer's software wallet, and which should be in the Signer's hardware wallet.

From the discussion, it appears to me that different people might have different expectations on what the signing device/HWW should do, so I would like to comment on this point specifically (while I reckon that it mostly falls within the realm of concerns #4 and #5 of the motivation paragraph, which are explicitly left out of scope).

I fully agree that a Signer must persist the full wallet's description, and should also create physical backups which include the full descriptor and the cosigner's information. I would disagree, however, if any standards were to force hardware wallets to persist any substantial amount of state other than the seed, as I believe that it gives no substantial advantage over externally stored signed data for many use cases.

The following is the wallet registration flow I am currently working on (in the context of adding support to multisig wallets at Ledger). The goal is to allow a Signer (the person) to persist a multisig setup in its storage, while achieving a similar level of security you would have if you were storing it on the hardware wallet itself (note that the following flow would happen as part of Round 2):

1) The desktop wallet of the requests the HWW to register a new multisig wallet. The request includes the full multisig wallet description, and some extra metadata (e.g.: a name to be associated to this multisig wallet).

2) The HWW validates the wallet and verifies it with the user with the trusted screen (as per BSMS Round 2); on confirmation, it returns a wallet id (which is a vendor-specific hash of all the wallet description + metadata) and signature

3) The desktop wallet stores the full wallet description/id/signature. (Optionally, a backup could be stored elsewhere).

Whenever an operation related to the multisig wallet is required (verifying a receiving address, or signing a spending transaction), the HWW first receives and verifies all the data stored at step 3 above (without any user interaction). Then it proceeds exactly the same way as if it had always stored the multisig wallet in their own storage.