path: root/35/4451f96317b46655a5d21441b42537291c33ef

Return-Path: <hugo@nunchuk.io>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D8D5FC000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Apr 2021 17:55:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id C7A9383CEA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Apr 2021 17:55:49 +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: 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 OITyBFP7SVbd
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Apr 2021 17:55:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com
 [IPv6:2607:f8b0:4864:20::42c])
 by smtp1.osuosl.org (Postfix) with ESMTPS id D13C783CE5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Apr 2021 17:55:48 +0000 (UTC)
Received: by mail-pf1-x42c.google.com with SMTP id o123so9684438pfb.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 12 Apr 2021 10:55:48 -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=nu5LmoDBcSVr/JlHPPS5tWTarH86NIhUCKyT/kVyjFU=;
 b=leGvMmO9M+c0n17VPsPdvxPmylpTpxFazR3lwPMB6eC6y5Iv4haafzClM/js6msw0D
 HL3OZ49V4tBQO2PIL7DKfe2bPhtsf32AWj3g12gR779qKofdy7JagafOG3oBPvB8w8m9
 dPchnmM47ITYo11uuzeVKhqdDNA0Fj5Z1ozQKPxagenjc+HtUtUGe4DBh3/2gUmxYumW
 JIWntL5qGuy/YG29I3Y/ZcRbAquMST9z4UL8jQttI/5DDVWi5Bnw3UEyCZia21vJNO0c
 4iUsp/MAkM4hWYXgbcJwiQZU4RZHbDJhM1ZMKN9g1yo6CUAsRwPXnBtwakK3AnGOx9LF
 5kCA==
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=nu5LmoDBcSVr/JlHPPS5tWTarH86NIhUCKyT/kVyjFU=;
 b=pmnn24/nKTVzULA0IhLISp0LgtNqNhsksW8356HihKxiYt9H4rxRQCaCfJjI9aSVsh
 CC1AGH1zXlgq1HxDC12ZrS/3lmrqsbZXq7iba/tW0k9wfX8LEqKs+x9OpoAynpybYZsi
 HkindYepfMEYBRH+9hmLECLPg9jvEMd9XvPpaeMBycP7I4biHVnLLjK3ENywSbRQALCe
 WPMmGbG2byTZk1qxuI18ZypQEZiGiBNejtyBZjqHCttOnG+0R4dM2kaMkTbKhg+c3D+L
 sVa1jndwZ4rnRYbA5ki5jwplj1SAd82OoxPSbF0MEl4+WnsQQ9li/GYJtccgtUsikvIr
 4hLw==
X-Gm-Message-State: AOAM532odoc82DCxuwfJPmYQo8eOHvhU1ukdXo2q3BaSAq/giZhmS3E1
 BVgBisYpQite8jia74815YFOicxG0qubtNNNlRfKPQ==
X-Google-Smtp-Source: ABdhPJxm6QLjQb33KBJGXHYpWqTDay0wDfEWcDIDhgUirGJrVYTjesfMIHLmqIcHqDlX6ykiJZsoVWZoEZf8N76Pai8=
X-Received: by 2002:a63:d43:: with SMTP id 3mr28211407pgn.5.1618250148250;
 Mon, 12 Apr 2021 10:55:48 -0700 (PDT)
MIME-Version: 1.0
References: <CAPKmR9uyY70MhmVCh=C9DeyF2Tyxibux1E_bLPo00aW_h+OjLw@mail.gmail.com>
 <CAPKmR9v=RK7byF0z0hKiLiA=Zm3ZZKbu3vEiuBuzQSXFwa+izw@mail.gmail.com>
 <s7sT6UplllXDfiCyf2HWJvEdz-1Gp9D5bvpwtAcmXEq2sRYm99FZZXJEFs-fDuhLKyxpgEvMrKa3P5OIRznxHLUqMjMIaUs-s5CGsx7zO_Q=@protonmail.com>
 <CAPKmR9v7xX7ASXAUkNXwjM5ExEF8xs5ihKw6MiY=RXk6o5s2Ng@mail.gmail.com>
 <CAMhCMoGWGFOuPA4iTacCP3HVudg80L+-xmjzvcGjohMhwnzVtA@mail.gmail.com>
In-Reply-To: <CAMhCMoGWGFOuPA4iTacCP3HVudg80L+-xmjzvcGjohMhwnzVtA@mail.gmail.com>
From: Hugo Nguyen <hugo@nunchuk.io>
Date: Mon, 12 Apr 2021 10:55:36 -0700
Message-ID: <CAPKmR9uoA_tgz690GPAgYWM32UPkR5P2Nc_TigJZi-SiLYcFLw@mail.gmail.com>
To: Salvatore Ingala <salvatore.ingala@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000003e9a0a05bfca3926"
X-Mailman-Approved-At: Mon, 12 Apr 2021 18:07:04 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Mon, 12 Apr 2021 17:55:49 -0000

--0000000000003e9a0a05bfca3926
Content-Type: text/plain; charset="UTF-8"

Hello Salvatore,

On Mon, Apr 12, 2021 at 8:03 AM Salvatore Ingala <salvatore.ingala@gmail.com>
wrote:

> Hi Hugo,
>
> First of all, thank you for the impressive work on leading the
> standardization efforts!
>
> I believe one ought to more clearly distinguish the "Signer" (as in: one
> of the parties in the multisig setup), from the "*Signing device*" (which
> is likely a hardware wallet).
>

Actually, in the current spec, a "Signer" is *any software/hardware that
possesses the private keys and can sign using those keys* -- it doesn't
have to be hardware. "Signer" does not mean the human user. I will clarify
the definition and clear up any ambiguous language in the spec. Thanks for
bringing this to my attention!


> BSMS defines a "Signer" as "a participating member in the multisig",
> therefore a person/entity who is likely using both a hardware wallet and
> some BSMS-friendly software wallet (e.g. the next version of Specter
> Desktop).
>

As mentioned above, "Signer" does not refer to the user or any entity that
does not have the private keys / signing capability.


> It is therefore relevant to discuss which parts of the BSMS mechanism are
> implemented in the Signer's software wallet, and which should be in the
> Signer's hardware wallet.
> From the discussion, it appears to me that different people might have
> different expectations on what the signing device/HWW should do, so I would
> like to comment on this point specifically (while I reckon that it mostly
> falls within the realm of concerns #4 and #5 of the motivation paragraph,
> which are explicitly left out of scope).
>
> I fully agree that a *Signer* must persist the full wallet's description,
> and should also create physical backups which include the full descriptor
> and the cosigner's information. I would disagree, however, if any standards
> were to force *hardware wallets* to persist any substantial amount of
> state other than the seed, as I believe that it gives no substantial
> advantage over externally stored signed data for many use cases.
>
> The following is the *wallet registration flow* I am currently working on
> (in the context of adding support to multisig wallets at Ledger). The goal
> is to allow a *Signer* (the person) to persist a multisig setup in its
> storage, while achieving a similar level of security you would have if you
> were storing it on the hardware wallet itself (note that the following flow
> would happen as part of Round 2):
>
> 1) The desktop wallet of the requests the HWW to register a new multisig
> wallet. The request includes the full multisig wallet description, and some
> extra metadata (e.g.: a name to be associated to this multisig wallet).
> 2) The HWW validates the wallet and verifies it with the user with the
> trusted screen (as per BSMS Round 2); on confirmation, it returns a wallet
> id (which is a vendor-specific hash of all the wallet description +
> metadata) and signature
> 3) The desktop wallet stores the full wallet description/id/signature.
> (Optionally, a backup could be stored elsewhere).
>

> Whenever an operation related to the multisig wallet is required
> (verifying a receiving address, or signing a spending transaction), the HWW
> first receives and verifies all the data stored at step 3 above (without
> any user interaction). Then it proceeds exactly the same way as if it had
> always stored the multisig wallet in their own storage.
>

Now that we're clear on definitions, then it should become obvious that
redefining the "Coordinator-Signer" pair as "a Signer" does not address the
underlying problem. (What you call "the desktop wallet" here is a
Coordinator, not a Signer).

As long as the Signer does not own up the task of storing the wallet
configuration, it must rely indefinitely on others for critical data when
working in a multisig wallet, as I have explained in my last email.

Best,
Hugo


>

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

<div dir=3D"ltr"><div dir=3D"ltr">Hello=C2=A0Salvatore,</div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 12, 2021=
 at 8:03 AM Salvatore Ingala &lt;<a href=3D"mailto:salvatore.ingala@gmail.c=
om">salvatore.ingala@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi Hugo,</div><div><br>=
</div><div>First of all, thank=C2=A0you for the impressive work on leading =
the standardization efforts!</div><div><br></div><div><div><div>I believe o=
ne ought to more clearly distinguish the &quot;Signer&quot; (as in: one of =
the parties in the multisig setup), from the &quot;<i>Signing device</i>&qu=
ot; (which is likely a hardware wallet).</div></div></div></div></blockquot=
e><div><br>Actually, in the current spec, a &quot;Signer&quot; is <b>any so=
ftware/hardware that possesses the private keys and can sign using those ke=
ys</b> -- it doesn&#39;t have to be hardware. &quot;Signer&quot; does not m=
ean the human user. I will clarify the definition and clear up any ambiguou=
s language in the spec. Thanks for bringing this to my attention!<br>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv><div><div> BSMS defines a &quot;Signer&quot; as &quot;a participating me=
mber in the multisig&quot;,=C2=A0 therefore a person/entity who is likely u=
sing both a hardware wallet and some BSMS-friendly software wallet (e.g. th=
e next version of Specter Desktop). </div></div></div></div></blockquote><d=
iv><br>As mentioned above, &quot;Signer&quot; does not refer to the user or=
 any entity that does not have the private keys / signing capability.<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"><div dir=3D"l=
tr"><div><div><div>It is therefore relevant to discuss which parts of the B=
SMS mechanism are implemented in the Signer&#39;s software wallet, and whic=
h should be in the Signer&#39;s hardware wallet.</div><div>From the discuss=
ion, it appears to me that different people might have different expectatio=
ns on what the signing device/HWW should do, so I would like to comment on =
this point specifically (while I reckon that it mostly falls within the rea=
lm of concerns #4 and #5 of the motivation paragraph, which are explicitly =
left out of scope).</div><div><br></div><div>I fully agree that a <i>Signer=
</i>=C2=A0must persist the full wallet&#39;s description, and should also c=
reate physical backups which include the full descriptor and the cosigner&#=
39;s information. I would disagree, however, if any standards were to force=
 <i>hardware wallets</i> to persist any substantial amount of state other t=
han the seed, as I believe that it gives no substantial advantage over exte=
rnally stored signed data for many use cases.</div></div><div><br></div><di=
v>The following is the <i>wallet registration=C2=A0flow</i> I am currently =
working on (in the context of adding support to multisig wallets at Ledger)=
. The goal is to allow a=C2=A0<i>Signer</i>=C2=A0(the person) to persist a =
multisig setup in its storage, while achieving a similar=C2=A0level of secu=
rity you would have if you were storing it on the hardware wallet itself (n=
ote that the following flow would happen as part of Round 2):</div><div><br=
></div><div>1) The desktop wallet of the requests the HWW to register a new=
 multisig wallet. The request includes the full multisig wallet description=
, and some extra metadata (e.g.: a name to be associated to this multisig w=
allet).</div><div>2) The HWW validates the wallet and verifies it with the =
user with the trusted screen (as per BSMS Round 2); on confirmation, it ret=
urns a wallet id (which is a vendor-specific hash of all the wallet descrip=
tion=C2=A0+ metadata) and signature</div><div>3) The desktop wallet stores =
the full wallet description/id/signature. (Optionally, a backup could be st=
ored elsewhere).</div></div></div></blockquote><div></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div><br></div><div>=
Whenever an operation related to the multisig wallet is required (verifying=
 a receiving address, or signing a spending transaction), the HWW first rec=
eives and verifies all the data stored at step 3 above (without any user in=
teraction). Then it proceeds exactly the same way as if it had always store=
d the multisig wallet in their own storage.</div></div></div></blockquote><=
div><br>Now that we&#39;re clear on definitions, then it should become obvi=
ous that redefining the &quot;Coordinator-Signer&quot; pair as &quot;a Sign=
er&quot; does not address the underlying problem. (What you call &quot;the =
desktop wallet&quot; here is a Coordinator, not a Signer).<br><br>As long a=
s the Signer does not own up the task of storing the wallet configuration, =
it must rely indefinitely on others for critical data when working in a mul=
tisig wallet,=C2=A0as I have explained in my last email.=C2=A0<br><br>Best,=
<br>Hugo<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>

--0000000000003e9a0a05bfca3926--