MIME-Version: 1.0
References: <CAJvkSseOx8mwYowLEnfKVEUuM5xsiYkbLdAvtaYxPpu4jY9pCg@mail.gmail.com>
 <2Abk4Gqv5hJyGtA8Gg1WCP5RNuyUFkmRn1uUKp_mdUaXrRTz4SDBTPi0MGU7D5jj36VSzrqsIiO5lMR4gGRApRX2jyp8vXDeHBnFt-6ca-g=@protonmail.com>
 <CAJvkSse5GDxzrDc0OeNSoHV90tsSvr-oCgY_P+p4O4T6PDUNpA@mail.gmail.com>
 <TC2UtcaDKCIkjtn41sIutqApciyqaGCD3SBSEWLBk4OT12siSkWIsp2LMmlmA0CLzUNuG1W8w-hB4Pq3ko1uGwbxpjxezFWKPq4C7OLUQo8=@protonmail.com>
 <CAJvkSseWZYH-dOvkFXmtKJgJOfv09La8sTb4e+2nvZYKTxNafg@mail.gmail.com>
 <KRJoyx0BjttYJnlGVY3hu2T_1bTPcpU1Vq639OYyQptXx6Xm0vkrCN-23ngBK3fs0ti2dT4i4LHIxOaxqNMACJ9N27jPqoPqzaBpxiOIH8s=@protonmail.com>
In-Reply-To: <KRJoyx0BjttYJnlGVY3hu2T_1bTPcpU1Vq639OYyQptXx6Xm0vkrCN-23ngBK3fs0ti2dT4i4LHIxOaxqNMACJ9N27jPqoPqzaBpxiOIH8s=@protonmail.com>
From: Tom Trevethan <tom@commerceblock.com>
Date: Tue, 22 Sep 2020 16:32:06 +0100
Message-ID: <CAJvkSsfJ-ep_WA1gCCBUeLUF4FKoXiCQ+t+c6KnOUQx8xEbH_Q@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000008f04605afe8ac4e"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure
 in a two-stage transfer protocol.
Precedence: list

--00000000000008f04605afe8ac4e
Content-Type: text/plain; charset="UTF-8"

Hi ZmnSCPxj,

> The SE can run in a virtual environment that monitors deletion events and
records them.
> Such a virtual environment could be set up by a rootkit that has been
installed on the SE hardware.
> Thus, even if the SE is honest, corruption of the hardware it is running
on can allow recovery of old privkeys and violation of the tr\*st
assumption.

This is true, but this threat can be mitigated with secured infrastructure
and the use of hardware security modules/trusted execution environments
that enable secure (and potentially attestable) deletion.

> Compare this to, for example, TumbleBit or Wasabi.
> In those cases, even if the service providing the mixing is corrupted by
a rootkit on the hardware running the honest service software in a virtual
environment and monitoring all its internal state and communications, they
cannot lead to loss of funds even with cooperation of previous participants.
>They can at most be forced into denial-of-service, but not outright theft
of coins.

Yes, I agree. But on the other side of the scale is a comparison with
centralised mixing services, which remain extremely popular.

> I admit the new solution is superior blockspace-wise, if you consider
multiple mixing rounds.

The aim of the solution is to replicate the UX (in terms of speed) of a
completely centralised mixer (i.e. where the server(s) explicitly holds the
full key(s) to the deposits being swapped) but in a way that makes theft
more difficult (requiring collusion with previous owners), has an in-built
mechanism for users to get back their funds if the service is shut
down/blown-up, provides users with proof of ownership/theft, and with the
same privacy guarantees as the above mentioned trust-minimised protocols.

Cheers,

Tom

On Tue, Sep 22, 2020 at 2:00 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Tom,
>
> > Hi ZmnSCPxj,
> >
> > > I think the entire point of non-custodiality ***is*** trust
> minimization.
> >
> > There are also legal and regulatory implications. It is much easier for
> a service to operate without requiring its users to be KYCed if it is
> non-custodial and funds cannot be frozen/seized.
>
> Complying with the letter of the law without complying to its spirit seems
> rather hair-splitting to me.
>
> Ideally, a law regarding any financial mechanisms would judge based on how
> much control the purported owner has over the actual coin and what risks it
> would entail for them, and protect citizens against risk of damage to their
> finances, not focus on whether storage is "custodial" or not.
>
> So I still suggest that, for purposes of technical discussion, we should
> avoid the term "custodial" and instead consider technical risks.
>
> >
> > > The main objection against custodiality is that someone else can
> prevent you from spending the coin.
> > > If I have to tr\*st the SE to not steal the funds, is it *really*
> non-custodial, when after a swap, a corrupted SE can, in collusion with
> other participants, take control of the coin and prevent me from spending
> it as I wish?
> >
> > I would argue that it is non-custodial if the SE performs the protocol
> as specified (i.e. securely deleting expired key shares).
>
> The SE can run in a virtual environment that monitors deletion events and
> records them.
> Such a virtual environment could be set up by a rootkit that has been
> installed on the SE hardware.
> Thus, even if the SE is honest, corruption of the hardware it is running
> on can allow recovery of old privkeys and violation of the tr\*st
> assumption.
>
> Compare this to, for example, TumbleBit or Wasabi.
> In those cases, even if the service providing the mixing is corrupted by a
> rootkit on the hardware running the honest service software in a virtual
> environment and monitoring all its internal state and communications, they
> cannot lead to loss of funds even with cooperation of previous participants.
> They can at most be forced into denial-of-service, but not outright theft
> of coins.
>
> Thus, I believe this solution is inferior to these older solutions, at
> least in terms of financial security.
>
> I admit the new solution is superior blockspace-wise, if you consider
> multiple mixing rounds.
> However, multiple mixing rounds under this solution have increased
> exposure to the risk of theft noted above, and thus it would be better,
> risk-wise, to immediately withdraw after every round, and potentially seek
> other SEs (to reduce risks arising from a particular SE being corrupted),
> thus obviating the blockspace savings.
>
>
> The above remain true regardless of what definition of "custodial" you
> have.
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"ltr"><span style=3D"color:rgb(80,0,80)">Hi ZmnSCPxj,</span><br>=
<div><span style=3D"color:rgb(80,0,80)"><br></span></div><div>&gt; The SE c=
an run in a virtual environment that monitors deletion events and records t=
hem.<br>&gt; Such a virtual environment could be set up by a rootkit that h=
as been installed on the SE hardware.<br>&gt; Thus, even if the SE is hones=
t, corruption of the hardware it is running on can allow recovery of old pr=
ivkeys and violation of the tr\*st assumption.<span style=3D"color:rgb(80,0=
,80)"><br></span></div><div><br></div><div>This is true, but this threat ca=
n be mitigated with secured infrastructure and the use of hardware security=
 modules/trusted execution environments that enable secure (and potentially=
 attestable) deletion.=C2=A0</div><div><br></div><div>&gt; Compare this to,=
 for example, TumbleBit or Wasabi.<br>&gt; In those cases, even if the serv=
ice providing the mixing is corrupted by a rootkit on the hardware running =
the honest service software in a virtual environment and monitoring all its=
 internal state and communications, they cannot lead to loss of funds even =
with cooperation of previous participants.<br>&gt;They can at most be force=
d into denial-of-service, but not outright theft of coins.<br></div><div><b=
r></div><div>Yes, I agree. But on the other side of the scale is a comparis=
on with centralised mixing services, which remain extremely popular.=C2=A0<=
/div><div><br></div><div>&gt; I admit the new solution is superior blockspa=
ce-wise, if you consider multiple mixing rounds.=C2=A0<br></div><div><br></=
div><div>The aim of the solution is to replicate the UX (in terms of speed)=
 of a completely centralised mixer (i.e. where the server(s) explicitly hol=
ds the full key(s) to the deposits being swapped) but in a way that makes t=
heft more difficult (requiring collusion=C2=A0with previous owners), has an=
 in-built mechanism for users to get back their funds if the service is shu=
t down/blown-up, provides users with proof of ownership/theft, and with the=
 same privacy guarantees as the above mentioned trust-minimised protocols.=
=C2=A0</div><div><br></div><div>Cheers,</div><div><br></div><div>Tom</div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Tue, Sep 22, 2020 at 2:00 AM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@prot=
onmail.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning Tom,<br>
<br>
&gt; Hi ZmnSCPxj,<br>
&gt;<br>
&gt; &gt;=C2=A0I think the entire point of non-custodiality ***is*** trust =
minimization.<br>
&gt;<br>
&gt; There are also legal and regulatory implications. It is much easier fo=
r a service to operate without requiring its users to be KYCed if it is non=
-custodial and funds cannot be frozen/seized.=C2=A0<br>
<br>
Complying with the letter of the law without complying to its spirit seems =
rather hair-splitting to me.<br>
<br>
Ideally, a law regarding any financial mechanisms would judge based on how =
much control the purported owner has over the actual coin and what risks it=
 would entail for them, and protect citizens against risk of damage to thei=
r finances, not focus on whether storage is &quot;custodial&quot; or not.<b=
r>
<br>
So I still suggest that, for purposes of technical discussion, we should av=
oid the term &quot;custodial&quot; and instead consider technical risks.<br=
>
<br>
&gt;<br>
&gt; &gt; The main objection against custodiality is that someone else can =
prevent you from spending the coin.<br>
&gt; &gt; If I have to tr\*st the SE to not steal the funds, is it *really*=
 non-custodial, when after a swap, a corrupted SE can, in collusion with ot=
her participants, take control of the coin and prevent me from spending it =
as I wish?<br>
&gt;<br>
&gt; I would argue that it is non-custodial if the SE performs the protocol=
 as specified (i.e. securely deleting expired key shares).<br>
<br>
The SE can run in a virtual environment that monitors deletion events and r=
ecords them.<br>
Such a virtual environment could be set up by a rootkit that has been insta=
lled on the SE hardware.<br>
Thus, even if the SE is honest, corruption of the hardware it is running on=
 can allow recovery of old privkeys and violation of the tr\*st assumption.=
<br>
<br>
Compare this to, for example, TumbleBit or Wasabi.<br>
In those cases, even if the service providing the mixing is corrupted by a =
rootkit on the hardware running the honest service software in a virtual en=
vironment and monitoring all its internal state and communications, they ca=
nnot lead to loss of funds even with cooperation of previous participants.<=
br>
They can at most be forced into denial-of-service, but not outright theft o=
f coins.<br>
<br>
Thus, I believe this solution is inferior to these older solutions, at leas=
t in terms of financial security.<br>
<br>
I admit the new solution is superior blockspace-wise, if you consider multi=
ple mixing rounds.<br>
However, multiple mixing rounds under this solution have increased exposure=
 to the risk of theft noted above, and thus it would be better, risk-wise, =
to immediately withdraw after every round, and potentially seek other SEs (=
to reduce risks arising from a particular SE being corrupted), thus obviati=
ng the blockspace savings.<br>
<br>
<br>
The above remain true regardless of what definition of &quot;custodial&quot=
; you have.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--00000000000008f04605afe8ac4e--