{"type":"rich","version":"1.0","author_name":"npub1jqxs4ftunmm8qjyw9s80hpcayewkjfhpxund29l9qvzy7xqx4duq85jqeg","author_url":"https://nostr.ae/npub1jqxs4ftunmm8qjyw9s80hpcayewkjfhpxund29l9qvzy7xqx4duq85jqeg","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-04-09\n📝 Original message:(Continue off last email: also keep in mind, that just like BIP174,\nCoordinator and Signer are abstract roles. This means in theory a Signer\ncan be the Coordinator too. The same criteria for trust applies equally to\na Signer and a Coordinator.)\n\nThe use case I personally find most interesting is not a multi-party setup,\n\u003e but rather just combining a bunch of my own devices. Those might even be in\n\u003e the same room during the setup, only to be moved to my moon base later.\n\u003e\n\nAnd that's fair. Both use cases (local and remote multisig) are valid and\ncurrently being used. But IMO a standard should accommodate both.\n\n\n\u003e To the list of concerns at the top of the BIP, I would add one: losing\n\u003e multisig setup context. E.g. in the event of a fire where you only recover\n\u003e your steel engraved mnemonic(s), but no longer have the wallet descriptors.\n\u003e\n\nGood point.\n\n\n\u003e\n\u003e If you still have all devices and know (or guess) the threshold then BIP48\n\u003e and sorted_multi descriptors will save you. But if you have a 2-of-3 setup\n\u003e and lost 1 device then without the metadata your coins are lost. In a\n\u003e future with musig(?) and miniscript increasingly the setup data is just as\n\u003e critical as the seeds.\n\u003e\n\nHow so? Each signer device should ideally have a copy of the multisig\nconfiguration. If you lose 1 device in a 2-of-3, you can still spend from\nthe wallet? Unless I'm missing something here.\n\n\n\u003e A future standard (or extension of this one) should recommend an\n\u003e encryption convention for the descriptor data, ideally such that with *any*\n\u003e of the seeds you can decrypt a file that contains the full setup. That file\n\u003e could then just float redundantly around the internet and pieces of paper\n\u003e in various locations, without compromising privacy.\n\u003e\n\nPost-wallet-creation, each Signer can apply extra encryption on top of BSMS\nfor the persistence of the configuration file any way it wants :) It\ndoesn't contradict with the current spec.\n\n\n\u003e The proposed encryption system doesn't help with that though, because it's\n\u003e based on entropy from the Coordinator, rather than from the signers.\n\u003e\n\nThey are for different purposes. The TOKEN-based encryption is only needed\ntemporarily for the setup.\n\n\n\u003e Smaller suggestions:\n\u003e * link to this new mail thread in the BIP\n\u003e\n\nWill do.\n\n\n\u003e * use magic bytes so .bsms so operating systems like Android / iOs can\n\u003e open the right app for them\n\u003e * don't use separate file extensions for encrypted vs unencrypted content,\n\u003e just indicate somehow that a given field is encrypted\n\u003e * although plain text files are handy for debugging, I think a binary\n\u003e format like PSBT is much powerful. Any device that can parse and write\n\u003e binary PSBT should be able to implement a similar parser / writer for a\n\u003e binary .bsms format.\n\u003e\n\nWill consider these points, but I prefer plaintext for wallet\nconfiguration. Human readability for the wallet configuration is a pro not\na con IMO. Also helps when backing up.\n\n\n\u003e * BIP48 and sorted_multi descriptors are useful in a loss-of-metadata\n\u003e scenario. The BIP uses both in the examples, but doesn't explictly endorse\n\u003e these derivations. It also contradicts them: \"If the Signer chooses the\n\u003e path, it should try to avoid reusing XPUBs for different wallets.\". Maybe\n\u003e this is out of scope.\n\u003e    * one way to resolve xpub reuse would be to make the \"BIP48\" path a\n\u003e function of the co-signer fingerprints and wallet threshold, but this\n\u003e requires an extra communication round\n\u003e\n\nWe discussed this in the linked PR (\nhttps://github.com/nunchuk-io/bips/pull/1), and decided that enforcing\nagainst path reuse is out-of-scope. We give examples of sorted_multi and\nmulti because different vendors support different things.\n\n\n\u003e * there should be a way for signers to communicate their capabilities,\n\u003e perhaps with a different xpub for each potential scheme. E.g. there's m/48'\n\u003e native SegWit now, MuSig and/or or Tapleaf based multisig in the future, or\n\u003e even generic Miniscript support.\n\u003e\n\nI considered Signers signaling capabilities (for a different reason), but\nopted against it because it further complicates the scheme. Also BIP48-like\nproposals are made redundant with the use of output descriptors.\n\n\n\u003e * the idea of only storing the receive descriptor, not the change\n\u003e descriptor, is fine by me, though I'd prefer an extension to the descriptor\n\u003e format to deal with this\n\u003e\n\nThat's not quite accurate. The spec stores the top-level descriptor\n(XPUB/*) along with the path restrictions (/0/*,/1/*), not the receive\ndescriptor.\n\n The path restrictions would allow you to extend on the spec. There's also\na VERSION field.\n\nBest,\nHugo\n\n\n\u003e\n\u003e Sjors\n\u003e\n\u003e \u003e Op 5 apr. 2021, om 09:02 heeft Hugo Nguyen via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e het volgende geschreven:\n\u003e \u003e\n\u003e \u003e Hi all,\n\u003e \u003e\n\u003e \u003e Please find below the complete draft of the Bitcoin Secure Multisig\n\u003e Setup (BSMS) BIP. The spec has gone through a number of important updates\n\u003e in the last month or so. Thanks everyone who has participated in the review\n\u003e process.\n\u003e \u003e\n\u003e \u003e As a PR: https://github.com/bitcoin/bips/pull/1097\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210409/754162ae/attachment-0001.html\u003e"}