rich1.0npub1uxks6rvrzqljyfp92sffgqypf8fpts0pv2dshvmmnrse76v0avlqy7wq7phttps://nostr.ae/npub1uxks6rvrzqljyfp92sffgqypf8fpts0pv2dshvmmnrse76v0avlqy7wq7pnjumphttps://nostr.ae📅 Original date posted:2021-04-09 📝 Original message:Hi all, First of all thanks for your continued work on standardising multisig setup. 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. This means I've paid less attention to the encryption scheme, so I might set TOKEN=0, but nevertheless I am skeptical about it. The first step is for the Coordinator to generate a TOKEN, presumably using its own entropy. But IIUC anyone who intercepts that token can decrypt any future step in the setup process. This suggests a chicken-egg problem where you need some pre-existing secure communications channel. 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. 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. 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. The proposed encryption system doesn't help with that though, because it's based on entropy from the Coordinator, rather than from the signers. Smaller suggestions: * link to this new mail thread in the BIP * 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. * 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 * 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. * 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 Sjors > Op 5 apr. 2021, om 09:02 heeft Hugo Nguyen via bitcoin-dev <bitcoin-dev at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210409/d254f217/attachment.sig>