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"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Precedence: list

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