path: root/fe/dc135f3b30f21a6ab8b6b5d5e5153ef8062030

Return-Path: <hugo@nunchuk.io>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 30158C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Apr 2021 14:54:23 +0000 (UTC)
Received: by mail-pl1-x629.google.com with SMTP id v8so2870151plz.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAPKmR9uyY70MhmVCh=C9DeyF2Tyxibux1E_bLPo00aW_h+OjLw@mail.gmail.com>
 <CAPKmR9v=RK7byF0z0hKiLiA=Zm3ZZKbu3vEiuBuzQSXFwa+izw@mail.gmail.com>
 <DDAD27D6-57F5-4B39-AADB-B28E04E36D29@sprovoost.nl>
In-Reply-To: <DDAD27D6-57F5-4B39-AADB-B28E04E36D29@sprovoost.nl>
From: Hugo Nguyen <hugo@nunchuk.io>
Date: Fri, 9 Apr 2021 07:54:11 -0700
Message-ID: <CAPKmR9u8zc3C7QmJYg-vg5jcutS07PK-0wdvpzCqMGLgnhHCBA@mail.gmail.com>
To: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: multipart/alternative; boundary="000000000000ebc1f005bf8b5627"
X-Mailman-Approved-At: Fri, 09 Apr 2021 15:47:30 +0000
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"ltr"><div dir=3D"ltr"><br></div>(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.)<br><br><div=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>=
</blockquote><div><br>And that&#39;s fair. Both use cases (local and remote=
 multisig) are valid and currently being used. But IMO a standard should ac=
commodate both.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">
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.<br>=
</blockquote><div><br>Good point.<br>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">
<br>
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.<br></blockquote><div><br>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&#39;m missing som=
ething here.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">
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.<br></blockquote><div><br>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&#39;t =
contradict with the current spec.<br>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">
The proposed encryption system doesn&#39;t help with that though, because i=
t&#39;s based on entropy from the Coordinator, rather than from the signers=
.<br></blockquote><div><br>They are for different purposes. The TOKEN-based=
 encryption is only needed temporarily for the setup.<br>=C2=A0<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">
Smaller suggestions:<br>
* link to this new mail thread in the BIP<br></blockquote><div><br>Will do.=
<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* use magic bytes so .bsms so operating systems like Android / iOs can open=
 the right app for them<br>
* don&#39;t use separate file extensions for encrypted vs unencrypted conte=
nt, just indicate somehow that a given field is encrypted<br>
* 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.<br></blockquote><div><br>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.<br>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
* BIP48 and sorted_multi descriptors are useful in a loss-of-metadata scena=
rio. The BIP uses both in the examples, but doesn&#39;t explictly endorse t=
hese derivations. It also contradicts them: &quot;If the Signer chooses the=
 path, it should try to avoid reusing XPUBs for different wallets.&quot;. M=
aybe this is out of scope.<br>
=C2=A0 =C2=A0* one way to resolve xpub reuse would be to make the &quot;BIP=
48&quot; path a function of the co-signer fingerprints and wallet threshold=
, but this requires an extra communication round<br></blockquote><div><br>W=
e discussed this in the linked PR (<a href=3D"https://github.com/nunchuk-io=
/bips/pull/1">https://github.com/nunchuk-io/bips/pull/1</a>), 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.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* there should be a way for signers to communicate their capabilities, perh=
aps with a different xpub for each potential scheme. E.g. there&#39;s m/48&=
#39; native SegWit now, MuSig and/or or Tapleaf based multisig in the futur=
e, or even generic Miniscript support.<br></blockquote><div>=C2=A0</div><di=
v>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.<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* the idea of only storing the receive descriptor, not the change descripto=
r, is fine by me, though I&#39;d prefer an extension to the descriptor form=
at to deal with this<br></blockquote><div><br>That&#39;s not quite accurate=
. The spec stores the top-level descriptor (XPUB/*) along with the path res=
trictions (/0/*,/1/*), not the receive descriptor.<br><br>=C2=A0The path re=
strictions would allow you to extend on the spec. There&#39;s also a VERSIO=
N field.<br><br>Best,<br>Hugo<br>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">
<br>
Sjors<br>
<br>
&gt; Op 5 apr. 2021, om 09:02 heeft Hugo Nguyen via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; het volgende geschreven:<br>
&gt; <br>
&gt; Hi all,<br>
&gt; <br>
&gt; 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.<br>
&gt; <br>
&gt; As a PR: <a href=3D"https://github.com/bitcoin/bips/pull/1097" rel=3D"=
noreferrer" target=3D"_blank">https://github.com/bitcoin/bips/pull/1097</a>=
<br>
<br>
</blockquote></div></div>

--000000000000ebc1f005bf8b5627--