path: root/81/ccd25703e6df2177d5c3c5a26a6f09fba2947f

Return-Path: <hugo@nunchuk.io>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 61569C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Apr 2021 14:10:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 40ADA605E4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Apr 2021 14:10:04 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.467
X-Spam-Level: *
X-Spam-Status: No, score=1.467 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, 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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=nunchuk-io.20150623.gappssmtp.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Ft7JmCaUrKOa
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Apr 2021 14:10:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com
 [IPv6:2607:f8b0:4864:20::530])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 538C6605A2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Apr 2021 14:10:03 +0000 (UTC)
Received: by mail-pg1-x530.google.com with SMTP id f29so3987120pgm.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 09 Apr 2021 07:10:03 -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=ezyuyaYHyfHS0GxE1GpIWsiDH/8Zg3Cj0qFkXmhFEZk=;
 b=gr60R5zG8JsGRUV6ZEx+Vd0+CNoO8+mSUBaf88O/DaugBF2q/GWUfs1Q6D+u2zidDx
 BLydlJpcIYG9GI2EaSwIXNve/PG0HWcff7mOUNanTRJ8kJ0oCECQUS+sQWwLCIbjZc/0
 vVfSi9ST8fFe5pojhC5b/SjEHBdWlN2SdfjZRFOoMTPJLzTIirW+HdgxAQfgqakA9QEB
 31nuC9bXlIbcJoOFCLUzMkJywKa92/YExlj/4dnNE96dlB2f7LEQcr8q7wrPAV2+pz/3
 th3ciWm6kBDQ5KO5EXDAISKUmPWhpOUoYo0bz+Xv3HVHrIve7sClJjhUWNdSseArHZ73
 zBiw==
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=ezyuyaYHyfHS0GxE1GpIWsiDH/8Zg3Cj0qFkXmhFEZk=;
 b=e3aj5NeJNOTbNyd2XkdsWXAp/GRTxqvvKYac1SGtrkxe7I55prqtufRi6zUw+oYIli
 R11Vv0uWwt/SPeKwOpU09SeAN2LB5w1t+VuXovRFbBTGTJaeibnp7pMN7dinIoZOQYw2
 to2sksoiidkJafIgpkuo8+zMma9dMkQ+lZ60cZrmsEbLx9SzTQWyt0OiI/yFt7CDof1b
 993CTf3Q9U6V1QmQ7mcesDqJEWmghVok3mdVNLRSzlbUnWij1Jt+EpaodCQgvqIr5HJZ
 fPPWr3ZMteaw3QbYyB0VG+2H00fD/KBfRf60UrH/x49oZS+wL0m4qHZ37IX5UOYFUj+C
 /xyw==
X-Gm-Message-State: AOAM530+j6fr4hiVkgIoCQ4GRfa8wFNOseq1wzWn2Wd1N1WlMhbdwZTb
 i35rEPS/vvalRPhG1aVSGltpOhpXUdu5+Ht5j4HDfQ==
X-Google-Smtp-Source: ABdhPJwAYxeqeTSUqaiSp6sTbHSkp5kIrngRhlKH7ocbKAIOKO7gbfd3MBqT9Y9slQRd2T25xrsh64XHilpSB8Md/xs=
X-Received: by 2002:a65:640d:: with SMTP id a13mr13144392pgv.272.1617977402741; 
 Fri, 09 Apr 2021 07:10:02 -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:09:51 -0700
Message-ID: <CAPKmR9u+Ron1AyLjPVsqNx6bWvkJMKzcF67JgP0TEEdysj78tw@mail.gmail.com>
To: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: multipart/alternative; boundary="000000000000586ed905bf8ab844"
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:10:04 -0000

--000000000000586ed905bf8ab844
Content-Type: text/plain; charset="UTF-8"

Hi Sjors
Thanks for the feedback!

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.
>

The exchange of the TOKEN is frequently mistaken as the chicken-and-egg
problem, but it is not so.

To understand why this isn't chicken-and-egg, and why the TOKEN actually
adds value, consider *the scale of the communication operation needed to
exchange the TOKEN*, and *the scale of the communication operation needed
to gather data for the creation of the multisig wallet *(with or without
the TOKEN):

1) The TOKEN itself is a single piece of data that is 64- or 96-bit. It is
small enough to be easily exchanged (even memorized) and entered into
various devices. It requires only a single round of communication, but can
protect as many rounds of communication as needed.

2) The data needed to create the multisig wallet, on the other hand, are
quite involving:
(a) Each Signer needs to share its XPUB, which cannot be memorized
(b) The XPUBs also come with their own metadata
(c) The creation of the wallet requires at least two rounds of
communications since the Signers need to voluntarily share their XPUBs
first, only then can a Coordinator combine the XPUBs into a single multisig
script and pass back the configuration to the Signers. (Note that without a
Coordinator, you'll need O(N^2) rounds of communication).
(d) Because Signers are typically off-line cold storage, the paths between
the Signers / the Signers <> Coordinator likely involve multiple hops
through various media, such as unsecure USB connection. This is the way
most multisig solutions are currently being implemented. It means the XPUBs
and the multisig configuration are vulnerable to leaking and/or
modifications.

Note that (d) is especially problematic for remote multisig setups. The
more remote, the more potential hops along the way, the more problematic.

So you can see that *the TOKEN ultimately reduces the problem of sharing a
large amount of sensitive data back and forth, to the sharing of a single,
small piece of data upfront.* An added advantage of this approach is that
if the parties fail to establish a shared TOKEN, the scheme fails with no
harm done.

The Coordinator, on the other hand, adds value by solving the O(n^2)
communication problem. Some minimal amount of trust is needed for the
Coordinator, but this can be greatly mitigated by a number of ways that we
have defined in the spec, such as:
* Signers must check that their XPUBs are included in the final descriptor
* Signers must display to the user the multisig configuration: M/N,
relative position(s) of XPUBs, etc.
* Signers must display the full descriptor upon user request for manual
inspection - this one is important because it means that the new scheme
cannot be worse than the status quo.
* Signers are recommended to display a preview of the first receive
address(es).

All in all, the Coordinator's role helps ease the setup process, while its
ability to pull off any shenanigans is greatly limited.

Best,
Hugo

--000000000000586ed905bf8ab844
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div>Hi Sjors</div><div>Thanks =
for the feedback! <br><div><br></div></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 first step is for the Coordinator to generate a TOKEN=
, presumably using its own entropy. But IIUC anyone who intercepts that tok=
en can decrypt any future step in the setup process. This suggests a chicke=
n-egg problem where you need some pre-existing secure communications channe=
l.<br></blockquote><div><br>The exchange of the TOKEN is frequently mistake=
n as the chicken-and-egg problem, but it is not so.</div><div><div><br>To u=
nderstand why this isn&#39;t chicken-and-egg, and why the TOKEN actually ad=
ds value, consider <b>the scale of the communication operation needed to ex=
change the TOKEN</b>, and <b>the scale of the communication operation neede=
d to gather data for the creation of the multisig wallet </b>(with or witho=
ut the TOKEN):<br><br>1) The TOKEN itself is a single piece of data that is=
 64- or 96-bit. It is small enough to be easily exchanged (even memorized) =
and entered into various devices. It requires only a single round of commun=
ication,=C2=A0but can protect as many rounds of communication as needed.<br=
><br>2) The data needed to create the multisig wallet, on the other hand, a=
re quite involving:</div><div>(a) Each Signer needs to share its XPUB, whic=
h cannot be memorized<br>(b) The XPUBs also come with their own metadata<br=
>(c) The creation of the wallet requires at least two rounds of communicati=
ons since the Signers need to voluntarily share their XPUBs first, only the=
n can a Coordinator combine the XPUBs into a single multisig script and pas=
s back the configuration to the Signers. (Note that without a Coordinator, =
you&#39;ll need O(N^2) rounds of communication).=C2=A0<br>(d) Because Signe=
rs are typically off-line cold storage, the paths between the=C2=A0Signers =
/ the=C2=A0Signers &lt;&gt; Coordinator likely involve multiple hops throug=
h various media, such as unsecure USB connection. This is the way most mult=
isig solutions are currently being implemented. It means the XPUBs and the =
multisig configuration are vulnerable to leaking and/or modifications.<br><=
br>Note that (d) is especially problematic for remote multisig setups. The =
more remote, the more potential hops along the way, the more problematic.<b=
r><br>So you can see that <b>the TOKEN ultimately=C2=A0reduces the problem =
of sharing a large amount of sensitive data back and forth, to the sharing =
of a single, small piece of data upfront.</b> An added advantage of this ap=
proach is that if the parties fail to establish a shared TOKEN, the scheme =
fails with no harm done.<br><br>The Coordinator, on the other hand, adds va=
lue by solving the O(n^2) communication problem. Some minimal amount of tru=
st is needed for the Coordinator, but this can be greatly mitigated by a nu=
mber of ways that we have defined in the spec, such as:<br>* Signers must c=
heck that their XPUBs are included in the final descriptor<br>* Signers mus=
t display to the user the multisig configuration: M/N, relative position(s)=
 of XPUBs, etc.<br>* Signers must display the full descriptor upon user req=
uest for manual inspection - this one is important because it means that th=
e new scheme cannot be worse than the status quo.<br>* Signers are recommen=
ded to display a preview of the first receive address(es).</div><div><br>Al=
l in all, the Coordinator&#39;s role helps ease the setup process, while it=
s ability to pull off any shenanigans is greatly limited.<br><br></div></di=
v><div>Best,<br>Hugo=C2=A0</div></div></div>

--000000000000586ed905bf8ab844--