From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 30158C000A for ; Fri, 9 Apr 2021 14:54:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 2035582FDE for ; Fri, 9 Apr 2021 14:54:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=nunchuk-io.20150623.gappssmtp.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWwshITgj_ob for ; Fri, 9 Apr 2021 14:54:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by smtp1.osuosl.org (Postfix) with ESMTPS id CC47082B2F for ; Fri, 9 Apr 2021 14:54:23 +0000 (UTC) Received: by mail-pl1-x629.google.com with SMTP id v8so2870151plz.10 for ; Fri, 09 Apr 2021 07:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nunchuk-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DbuJ3h9AohVcP/J94Z4cgd17RxNgCQDDSICUZe7oYTc=; b=fV++Kn1KYrVIt+DYtnvWSz2gg1JxbzDkI9RDxAjXfXG7Std33N9w6bHZHqX6OB8ngh qv9xDEypdAmMpR6vyAlBYaRBcDhb932E8k+AOuhe6IBCNS6u93Ytrk56S5PFZ/r+7aJ7 tT9+Lo+kTeicTGDaKMtwohFObo2+cFK7leVGLMS/766rh673Kvzyp7wLkxonxUe1uITV vh0KNOZgScljL6WqqPWWJw/e9JYV2lxbZmCyvuSYF363MbiEwEBc29/d75XWf6RWYdR6 XA6I+9nkeQ6Sedm9VPtr7E2Yg55Q5DuFqnZ/jT3v0yU3dQ+qHVPRN8PJUlTgGq5IVAaS mRUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DbuJ3h9AohVcP/J94Z4cgd17RxNgCQDDSICUZe7oYTc=; b=RvFgzqSn8A6ineilUCM4iMxEV91LQjrsNcV51SFOoAsoBveL1q+6CBJr45Pf0zbKAx FoGb244h/2tMI8hqRshJZ8Ktr1CF89xXwUOLJELOnHvsKkn0xhT0J55aizbw23kyYvqO kj4lfZDWsMVKdfTIJYtu+63i7lWR/wyn4T9NzkYVxixzOdfxNgQYgwVPSEHUL57rZugS vMVm2u46dvFu8u095de4OBCR/y1A3WKcpYb0DRDNV4lIPVXcriOMNcmnvtnTFXGOU21S Etu+hCo0MMwXUhbusIRQ8TXKg/AkK4ipD+sckxyK75PG2XMWgAtCq3l57i+1Bba0X/k0 dYCw== X-Gm-Message-State: AOAM531q5ngjd+fVU8YUMYU4PD+qAXtOBMXf24KT+7fc8IueD0KT0R8F ixNR/t1yPhvBGnoBL6aPswU5uHoezwaDCBA0kJTDxQ== X-Google-Smtp-Source: ABdhPJxvMEVTpEyIE4LLIg/0BigesSixJi2tvMITtJB5fZJiVJ7XyCUbctYH98Rz7P39IEX/KJ5TKm3w60s5MEPsXzA= X-Received: by 2002:a17:902:b705:b029:e6:f027:adf8 with SMTP id d5-20020a170902b705b02900e6f027adf8mr13411473pls.72.1617980063197; Fri, 09 Apr 2021 07:54:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hugo Nguyen Date: Fri, 9 Apr 2021 07:54:11 -0700 Message-ID: To: Sjors Provoost Content-Type: multipart/alternative; boundary="000000000000ebc1f005bf8b5627" X-Mailman-Approved-At: Fri, 09 Apr 2021 15:47:30 +0000 Cc: marko , Bitcoin Dev , aarondongchen@gmail.com, Peter Gray Subject: Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 14:54:25 -0000 --000000000000ebc1f005bf8b5627 Content-Type: text/plain; charset="UTF-8" (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 > > --000000000000ebc1f005bf8b5627 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

(Continue off last email: also = keep in mind, that just like BIP174, Coordinator and Signer are abstract ro= les. This means in theory a Signer can be the Coordinator too. The same cri= teria for trust applies equally to a Signer and a Coordinator.)

Th= e use case I personally find most interesting is not a multi-party setup, b= ut 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 ac= commodate both.
=C2=A0
To the list of concerns at the top of the BIP, I would add one: losing mult= isig 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.
=C2=A0

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 futur= e with musig(?) and miniscript increasingly the setup data is just as criti= cal as the seeds.

How so? Each signer device shoul= d ideally have a copy of the multisig configuration. If you lose 1 device i= n a 2-of-3, you can still spend from the wallet? Unless I'm missing som= ething here.
=C2=A0
A future standard (or extension of this one) should recommend an encryption= convention for the descriptor data, ideally such that with *any* of the se= eds you can decrypt a file that contains the full setup. That file could th= en just float redundantly around the internet and pieces of paper in variou= s locations, without compromising privacy.

Post-wa= llet-creation, each Signer can apply extra encryption on top of BSMS for th= e persistence of the configuration file any way it wants :) It doesn't = contradict with the current spec.
=C2=A0
The proposed encryption system doesn't help with that though, because i= t'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.
=C2=A0
Smaller suggestions:
* link to this new mail thread in the BIP

Will do.=
=C2=A0
* 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 conte= nt, just indicate somehow that a given field is encrypted
* although plain text files are handy for debugging, I think a binary forma= t like PSBT is much powerful. Any device that can parse and write binary PS= BT 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=C2=A0wallet c= onfiguration is a pro not a con IMO. Also helps when backing up.
=C2=A0<= /div>
* BIP48 and sorted_multi descriptors are useful in a loss-of-metadata scena= rio. The BIP uses both in the examples, but doesn't explictly endorse t= hese derivations. It also contradicts them: "If the Signer chooses the= path, it should try to avoid reusing XPUBs for different wallets.". M= aybe this is out of scope.
=C2=A0 =C2=A0* one way to resolve xpub reuse would be to make the "BIP= 48" path a function of the co-signer fingerprints and wallet threshold= , but this requires an extra communication round

W= e discussed this in the linked PR (https://github.com/nunchuk-io/bips/pull/1), and decided t= hat enforcing against path reuse is out-of-scope. We give examples of sorte= d_multi and multi because different vendors support different things.
= =C2=A0
* there should be a way for signers to communicate their capabilities, perh= aps with a different xpub for each potential scheme. E.g. there's m/48&= #39; native SegWit now, MuSig and/or or Tapleaf based multisig in the futur= e, or even generic Miniscript support.
=C2=A0
I considered Signers signaling capabilities (for a different reason), but= opted against it because it further complicates the scheme. Also BIP48-lik= e proposals are made redundant with the use of output descriptors.
=C2= =A0
* the idea of only storing the receive descriptor, not the change descripto= r, is fine by me, though I'd prefer an extension to the descriptor form= at to deal with this

That's not quite accurate= . The spec stores the top-level descriptor (XPUB/*) along with the path res= trictions (/0/*,/1/*), not the receive descriptor.

=C2=A0The path re= strictions would allow you to extend on the spec. There's also a VERSIO= N field.

Best,
Hugo
=C2=A0

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 Se= tup (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 pr= ocess.
>
> As a PR: https://github.com/bitcoin/bips/pull/1097=

--000000000000ebc1f005bf8b5627--