From: Hugo Nguyen <hugo@nunchuk•io>
To: Sjors Provoost <sjors@sprovoost•nl>
Cc: marko <marko@shiftcrypto•ch>,
Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>,
aarondongchen@gmail•com, Peter Gray <peter@coinkite•com>
Subject: Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Date: Fri, 9 Apr 2021 07:54:11 -0700 [thread overview]
Message-ID: <CAPKmR9u8zc3C7QmJYg-vg5jcutS07PK-0wdvpzCqMGLgnhHCBA@mail.gmail.com> (raw)
In-Reply-To: <DDAD27D6-57F5-4B39-AADB-B28E04E36D29@sprovoost.nl>
[-- Attachment #1: Type: text/plain, Size: 5063 bytes --]
(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
>
>
[-- Attachment #2: Type: text/html, Size: 7136 bytes --]
next prev parent reply other threads:[~2021-04-09 14:54 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-08 23:14 Hugo Nguyen
2021-02-09 9:33 ` Craig Raw
[not found] ` <CAPR5oBNWGLcnw97yPJBCgrj=EwoNdxz_RS9HM6EMpuX2-90JnQ@mail.gmail.com>
2021-02-09 9:45 ` Hugo Nguyen
[not found] ` <CACrqygA1JRA293joYOxxpSepiuFD=uVvQQy3wpuosYyLQHff-A@mail.gmail.com>
2021-02-09 9:38 ` Christopher Allen
2021-02-09 10:05 ` Hugo Nguyen
[not found] ` <CACrqygDhuateDtJMBSWd9sGRu1yzrZBw2yZ75OyKD1Xmzix3Cw@mail.gmail.com>
2021-02-09 10:58 ` Hugo Nguyen
2021-02-11 13:25 ` Pavol Rusnak
2021-02-11 13:45 ` Hugo Nguyen
2021-02-11 16:29 ` Dmitry Petukhov
2021-02-11 19:11 ` Hugo Nguyen
2021-02-11 19:11 ` Hugo Nguyen
2021-02-11 22:29 ` Christopher Allen
2021-02-12 12:31 ` Hugo Nguyen
2021-02-12 13:48 ` Peter D. Gray
2021-02-12 16:55 ` Hugo Nguyen
2021-02-12 17:42 ` Dmitry Petukhov
2021-02-12 17:48 ` Dmitry Petukhov
2021-02-12 17:54 ` Hugo Nguyen
2021-02-14 10:37 ` Dmitry Petukhov
2021-02-14 11:28 ` Dmitry Petukhov
2021-02-15 8:44 ` Hugo Nguyen
2021-02-15 13:53 ` Craig Raw
2021-02-15 14:19 ` Hugo Nguyen
2021-02-15 16:45 ` Hugo Nguyen
2021-04-05 7:02 ` Hugo Nguyen
2021-04-09 12:07 ` Sjors Provoost
2021-04-09 14:09 ` Hugo Nguyen
2021-04-09 14:54 ` Hugo Nguyen [this message]
2021-04-09 15:33 ` Sjors Provoost
2021-04-10 19:32 ` Robert Spigler
2021-04-11 2:34 ` Michael.flaxman
2021-04-11 16:45 ` Hugo Nguyen
2021-04-12 15:03 ` Salvatore Ingala
2021-04-12 17:55 ` Hugo Nguyen
2021-04-12 18:45 ` Christopher Allen
2021-04-12 20:43 ` Robert Spigler
2021-04-10 13:53 ` Erik Aronesty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPKmR9u8zc3C7QmJYg-vg5jcutS07PK-0wdvpzCqMGLgnhHCBA@mail.gmail.com \
--to=hugo@nunchuk$(echo .)io \
--cc=aarondongchen@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=marko@shiftcrypto$(echo .)ch \
--cc=peter@coinkite$(echo .)com \
--cc=sjors@sprovoost$(echo .)nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox