(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 > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
