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>
In-Reply-To: <CAPKmR9v7xX7ASXAUkNXwjM5ExEF8xs5ihKw6MiY=RXk6o5s2Ng@mail.gmail.com>
From: Salvatore Ingala <salvatore.ingala@gmail.com>
Date: Mon, 12 Apr 2021 17:03:12 +0200
Message-ID: <CAMhCMoGWGFOuPA4iTacCP3HVudg80L+-xmjzvcGjohMhwnzVtA@mail.gmail.com>
To: Hugo Nguyen <hugo@nunchuk.io>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000af2c2705bfc7d014"
Subject: Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Precedence: list

--000000000000af2c2705bfc7d014
Content-Type: text/plain; charset="UTF-8"

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). 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). 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. I think this is basically
the same flow Michael Flaxman is suggesting here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018775.html

(Note that none of this is flow specific to Multisig wallet, as the same
flow would be unchanged for any arbitrary supported script that needs to be
"registered" on a stateless device, and can be generalized for MPC
protocols)

The only caveat I can think of is that the script registration is never
revocable if a signing key derived from the seed is used in step (2), which
might or might not be desirable. One could instead prefer to use a
different signing key that is destroyed if the device is wiped, which would
therefore need to be stored on the device. Note that the only thing that is
lost is the on-device multisig wallet registration, which could easily be
repeated from a backup.


On Sun, 11 Apr 2021 at 19:11, Hugo Nguyen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I reiterate that I strongly disagree that going stateless is the direction
> we want to pursue when it comes to multisig.
>
> In a multisig or any type of MPC smart contract, any Signer in the
> contract must know who the other co-Signers are at all times. You can
> choose to do this verification once at setup and persist this info on the
> Signer, or you'd have to re-do the verification for every single
> transaction. There is no other choice.
>

>
Signing the descriptor record is insufficient, while also introducing a
> great deal of complexity. Here are the problems:
> 1) The signature needs to be stored somewhere. Who stores it if it's not
> the Signer itself? What if it gets lost? (If the Signer stores its own
> signature, then the scheme is no longer stateless. You might as well store
> the full descriptor).
>

In the flow I describe above, the desktop wallet would indeed store the
signed descriptor record and wallet metadata. So yes, the *Signer* as in *the
party in the protocol* stores it, but not the signing device*. *The same
method could be used to store state temporarily between round 1 and 2,
where the only *state* on the hardware wallet would be the TOKEN, while
everything else is stored (encrypted and signed) on the Signer's desktop.


> 2) When the signature is "played back" to the Signer, a copy of the
> original descriptor must be included. Who stores the descriptor? What if it
> gets lost? This is an under-appreciated aspect of the stateful approach:
> every participant in the multisig has a full copy of the original contract,
> which adds resilience to the wallet backup / recovery process.
>

"Playing back" the signature and wallet's setup data to the hardware wallet
would indeed happen transparently from the Signer's wallet software. If the
Signer lost this data due to malware, faulty hardware, etc., the user would
indeed have to recover from backup, which seems ok to me.


> 3) Because the full descriptor must be "played back" for every single
> transaction, this means every detail of the contract must be shared again
> and again, indefinitely. Not only does this add overhead (engineering and
> cognitive) to the spending process, it has massive privacy implications,
> since the descriptor contains everything you need to know about the wallets
> and its participants.
>

I agree with some of these concerns, but I observe:
- The engineering overhead in handling externally-stored-signed-data is
paid once, and would mostly fall on the hardware wallet vendor. External
software only cares about storing certain data and sending it back later.
- Storing xpubs/descriptors in the desktop software that interacts with
the HWW is already common practice, and necessary for using any watch-only
wallet.

Summarizing, I argue that the stateful/stateless characteristic of a
hardware wallet does not really affect (modulo some extra work) the ability
to participate in the BSMS ceremony, whose *Signers* should indeed be
stateful.
Some more clarifications on the trust assumptions might help at clarifying
the best possible software/hardware implementation tradeoffs, either in
this or a follow-up BIP.

Best,
Salvatore Ingala

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

<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 one ought to more clearly disti=
nguish the &quot;Signer&quot; (as in: one of the parties in the multisig se=
tup), from the &quot;<i>Signing device</i>&quot; (which is likely a hardwar=
e wallet). BSMS defines a &quot;Signer&quot; as &quot;a participating membe=
r in the multisig&quot;,=C2=A0 therefore a person/entity who is likely usin=
g both a hardware wallet and some BSMS-friendly software wallet (e.g. the n=
ext version of Specter Desktop). It is therefore relevant to discuss which =
parts of the BSMS mechanism are implemented in the Signer&#39;s software wa=
llet, and which should be in the Signer&#39;s hardware wallet.</div><div>Fr=
om the discussion, it appears to me that different people might have differ=
ent 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 a=
re explicitly left out of scope).</div><div><br></div><div>I fully agree th=
at a <i>Signer</i>=C2=A0must persist the full wallet&#39;s description, and=
 should also create 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 than the seed, as I believe that it gives no substantial advan=
tage over externally stored signed data for many use cases.</div></div><div=
><br></div><div>The following is the <i>wallet registration=C2=A0flow</i> I=
 am currently working on (in the context of adding support to multisig wall=
ets 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 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=
):</div><div><br></div><div>1) The desktop wallet of the requests the HWW t=
o register a new multisig wallet. The request includes the full multisig wa=
llet description, and some extra metadata (e.g.: a name to be associated to=
 this multisig wallet).</div><div>2) The HWW validates the wallet and verif=
ies it with the user with the trusted screen (as per BSMS Round 2); on conf=
irmation, it returns a wallet id (which is a vendor-specific hash of all th=
e wallet description=C2=A0+ metadata) and signature</div><div>3) The deskto=
p wallet stores the full wallet description/id/signature. (Optionally, a ba=
ckup could be stored elsewhere).</div><div><br></div><div>Whenever an opera=
tion related to the multisig wallet is required (verifying a receiving addr=
ess, or signing a spending transaction), the HWW first receives and verifie=
s 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 wa=
llet in their own storage. I think this is basically the same flow Michael =
Flaxman is suggesting here:=C2=A0<a href=3D"https://lists.linuxfoundation.o=
rg/pipermail/bitcoin-dev/2021-April/018775.html">https://lists.linuxfoundat=
ion.org/pipermail/bitcoin-dev/2021-April/018775.html</a></div><div><br></di=
v><div>(Note that none of this is flow specific to Multisig wallet, as the =
same flow would be unchanged for any arbitrary supported script that needs =
to be &quot;registered&quot; on a stateless device, and can be generalized =
for MPC protocols)</div><div><br></div><div>The only caveat I can think of =
is that the script registration is never revocable if a signing key derived=
 from the seed is used in step=C2=A0(2), which might or might not be desira=
ble. One could instead prefer to use a different=C2=A0signing key that=C2=
=A0is destroyed if the device is wiped, which would therefore need to be st=
ored on the device. Note that the only thing that is lost is the on-device =
multisig wallet registration, which could easily be repeated=C2=A0from a ba=
ckup.</div><div><br></div><div></div></div><div><br></div><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, 11 Apr 2021 at 19:1=
1, Hugo Nguyen via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a=
>&gt; wrote:=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"><=
div dir=3D"ltr"><div class=3D"gmail_quote"><div>I reiterate that I strongly=
 disagree that going stateless is the direction we want to pursue when it c=
omes to multisig.<br><br>In a multisig or any type of MPC smart contract, a=
ny Signer in the contract must know who the other co-Signers are at all tim=
es. You can choose to do this verification once at setup and persist this i=
nfo on the Signer, or you&#39;d have to re-do the verification for every si=
ngle transaction. There is no other choice.=C2=A0</div></div></div></blockq=
uote><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"><div dir=3D"ltr"><di=
v class=3D"gmail_quote"><div>=C2=A0</div></div></div></blockquote><blockquo=
te 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"ltr"><div class=3D"gma=
il_quote"><div>Signing the=C2=A0descriptor record is insufficient, while al=
so=C2=A0introducing a great deal of complexity. Here are the problems:<br>1=
) The signature needs to be stored somewhere. Who stores it if it&#39;s not=
 the Signer itself? What if it gets lost? (If the Signer stores its own sig=
nature, then the scheme is no longer stateless. You might as well store the=
=C2=A0full descriptor).<br></div></div></div></blockquote><div><br></div><d=
iv>In the flow I describe above, the desktop wallet would indeed store the =
signed descriptor record and wallet metadata. So yes, the <i>Signer</i>=C2=
=A0as in <i>the party in=C2=A0the protocol</i>=C2=A0stores it,=C2=A0but not=
 the signing device<i>. </i>The same method could be used to store state te=
mporarily between round 1 and 2, where the only <i>state</i>=C2=A0on the ha=
rdware wallet would be the TOKEN, while everything else is stored (encrypte=
d and signed) on the Signer&#39;s desktop.<br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_quote"><div>2) When the signature is &quot;played back&quot; to the S=
igner, a copy of the original descriptor must be included. Who stores the d=
escriptor? What if it gets lost? This is an under-appreciated aspect of the=
 stateful approach: every participant in the multisig has a full copy of th=
e original contract, which adds resilience to the wallet backup / recovery =
process.<br></div></div></div></blockquote><div><br></div><div>&quot;Playin=
g back&quot; the signature and wallet&#39;s setup data to the hardware wall=
et would indeed happen transparently from the Signer&#39;s wallet software.=
 If the Signer lost this data due to malware, faulty hardware, etc., the=C2=
=A0user would indeed have to recover from backup, which seems ok to me.</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"gmail_quote"><div>3) Because the full descriptor m=
ust be &quot;played back&quot; for every single transaction, this means eve=
ry detail of the contract must be shared again and again,=C2=A0indefinitely=
. Not only does this add overhead (engineering and cognitive) to the spendi=
ng process, it has massive privacy implications, since the descriptor conta=
ins everything you need to know about the wallets and its participants.<br>=
</div></div></div></blockquote><div><br></div><div>I agree with some of the=
se concerns, but I observe:</div><div>- The engineering overhead in handlin=
g externally-stored-signed-data is paid once, and would mostly fall on the =
hardware wallet vendor. External software only cares about storing certain =
data and sending it back later.</div><div>- Storing xpubs/descriptors in th=
e desktop software that interacts with the=C2=A0HWW is already common pract=
ice,=C2=A0and necessary for using any watch-only wallet.</div><div><br></di=
v><div>Summarizing, I argue that the stateful/stateless characteristic of a=
 hardware wallet does not really affect (modulo some extra work) the abilit=
y to participate in the BSMS ceremony, whose <i>Signers</i>=C2=A0should ind=
eed be stateful.</div><div>Some more clarifications on the trust assumption=
s might help at clarifying the best possible software/hardware implementati=
on tradeoffs, either in this or a follow-up BIP.</div><div><br></div><div>B=
est,</div><div>Salvatore Ingala</div></div></div>

--000000000000af2c2705bfc7d014--