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