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. I think this is basically the same flow Michael Flaxman is suggesting here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018775.html
(Note that none of this is flow specific to Multisig wallet, as the same flow would be unchanged for any arbitrary supported script that needs to be "registered" on a stateless device, and can be generalized for MPC protocols)
The only caveat I can think of is that the script registration is never revocable if a signing key derived from the seed is used in step (2), which might or might not be desirable. One could instead prefer to use a different signing key that is destroyed if the device is wiped, which would therefore need to be stored on the device. Note that the only thing that is lost is the on-device multisig wallet registration, which could easily be repeated from a backup.
I reiterate that I strongly disagree that going stateless is the direction we want to pursue when it comes to multisig.
In a multisig or any type of MPC smart contract, any Signer in the contract must know who the other co-Signers are at all times. You can choose to do this verification once at setup and persist this info on the Signer, or you'd have to re-do the verification for every single transaction. There is no other choice.
Signing the descriptor record is insufficient, while also introducing a great deal of complexity. Here are the problems:
1) The signature needs to be stored somewhere. Who stores it if it's not the Signer itself? What if it gets lost? (If the Signer stores its own signature, then the scheme is no longer stateless. You might as well store the full descriptor).
In the flow I describe above, the desktop wallet would indeed store the signed descriptor record and wallet metadata. So yes, the Signer as in the party in the protocol stores it, but not the signing device. The same method could be used to store state temporarily between round 1 and 2, where the only state on the hardware wallet would be the TOKEN, while everything else is stored (encrypted and signed) on the Signer's desktop.
2) When the signature is "played back" to the Signer, a copy of the original descriptor must be included. Who stores the descriptor? What if it gets lost? This is an under-appreciated aspect of the stateful approach: every participant in the multisig has a full copy of the original contract, which adds resilience to the wallet backup / recovery process.
"Playing back" the signature and wallet's setup data to the hardware wallet would indeed happen transparently from the Signer's wallet software. If the Signer lost this data due to malware, faulty hardware, etc., the user would indeed have to recover from backup, which seems ok to me.
3) Because the full descriptor must be "played back" for every single transaction, this means every detail of the contract must be shared again and again, indefinitely. Not only does this add overhead (engineering and cognitive) to the spending process, it has massive privacy implications, since the descriptor contains everything you need to know about the wallets and its participants.
I agree with some of these concerns, but I observe:
- The engineering overhead in handling externally-stored-signed-data is paid once, and would mostly fall on the hardware wallet vendor. External software only cares about storing certain data and sending it back later.
- Storing xpubs/descriptors in the desktop software that interacts with the HWW is already common practice, and necessary for using any watch-only wallet.
Summarizing, I argue that the stateful/stateless characteristic of a hardware wallet does not really affect (modulo some extra work) the ability to participate in the BSMS ceremony, whose Signers should indeed be stateful.
Some more clarifications on the trust assumptions might help at clarifying the best possible software/hardware implementation tradeoffs, either in this or a follow-up BIP.
Best,
Salvatore Ingala