(Continue off last email: also keep in mind, that just like BIP174,
Coordinator and Signer are abstract roles. This means in theory a Signer
can be the Coordinator too. The same criteria for trust applies equally to
a Signer and a Coordinator.)

The use case I personally find most interesting is not a multi-party setup,
> but rather just combining a bunch of my own devices. Those might even be in
> the same room during the setup, only to be moved to my moon base later.
>

And that's fair. Both use cases (local and remote multisig) are valid and
currently being used. But IMO a standard should accommodate both.


> To the list of concerns at the top of the BIP, I would add one: losing
> multisig setup context. E.g. in the event of a fire where you only recover
> your steel engraved mnemonic(s), but no longer have the wallet descriptors.
>

Good point.


>
> If you still have all devices and know (or guess) the threshold then BIP48
> and sorted_multi descriptors will save you. But if you have a 2-of-3 setup
> and lost 1 device then without the metadata your coins are lost. In a
> future with musig(?) and miniscript increasingly the setup data is just as
> critical as the seeds.
>

How so? Each signer device should ideally have a copy of the multisig
configuration. If you lose 1 device in a 2-of-3, you can still spend from
the wallet? Unless I'm missing something here.


> A future standard (or extension of this one) should recommend an
> encryption convention for the descriptor data, ideally such that with *any*
> of the seeds you can decrypt a file that contains the full setup. That file
> could then just float redundantly around the internet and pieces of paper
> in various locations, without compromising privacy.
>

Post-wallet-creation, each Signer can apply extra encryption on top of BSMS
for the persistence of the configuration file any way it wants :) It
doesn't contradict with the current spec.


> The proposed encryption system doesn't help with that though, because it's
> based on entropy from the Coordinator, rather than from the signers.
>

They are for different purposes. The TOKEN-based encryption is only needed
temporarily for the setup.


> Smaller suggestions:
> * link to this new mail thread in the BIP
>

Will do.


> * use magic bytes so .bsms so operating systems like Android / iOs can
> open the right app for them
> * don't use separate file extensions for encrypted vs unencrypted content,
> just indicate somehow that a given field is encrypted
> * although plain text files are handy for debugging, I think a binary
> format like PSBT is much powerful. Any device that can parse and write
> binary PSBT should be able to implement a similar parser / writer for a
> binary .bsms format.
>

Will consider these points, but I prefer plaintext for wallet
configuration. Human readability for the wallet configuration is a pro not
a con IMO. Also helps when backing up.


> * BIP48 and sorted_multi descriptors are useful in a loss-of-metadata
> scenario. The BIP uses both in the examples, but doesn't explictly endorse
> these derivations. It also contradicts them: "If the Signer chooses the
> path, it should try to avoid reusing XPUBs for different wallets.". Maybe
> this is out of scope.
>    * one way to resolve xpub reuse would be to make the "BIP48" path a
> function of the co-signer fingerprints and wallet threshold, but this
> requires an extra communication round
>

We discussed this in the linked PR (
https://github.com/nunchuk-io/bips/pull/1), and decided that enforcing
against path reuse is out-of-scope. We give examples of sorted_multi and
multi because different vendors support different things.


> * there should be a way for signers to communicate their capabilities,
> perhaps with a different xpub for each potential scheme. E.g. there's m/48'
> native SegWit now, MuSig and/or or Tapleaf based multisig in the future, or
> even generic Miniscript support.
>

I considered Signers signaling capabilities (for a different reason), but
opted against it because it further complicates the scheme. Also BIP48-like
proposals are made redundant with the use of output descriptors.


> * the idea of only storing the receive descriptor, not the change
> descriptor, is fine by me, though I'd prefer an extension to the descriptor
> format to deal with this
>

That's not quite accurate. The spec stores the top-level descriptor
(XPUB/*) along with the path restrictions (/0/*,/1/*), not the receive
descriptor.

 The path restrictions would allow you to extend on the spec. There's also
a VERSION field.

Best,
Hugo


>
> Sjors
>
> > Op 5 apr. 2021, om 09:02 heeft Hugo Nguyen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
> >
> > Hi all,
> >
> > Please find below the complete draft of the Bitcoin Secure Multisig
> Setup (BSMS) BIP. The spec has gone through a number of important updates
> in the last month or so. Thanks everyone who has participated in the review
> process.
> >
> > As a PR: https://github.com/bitcoin/bips/pull/1097
>
>