Date: Thu, 24 Sep 2020 00:19:48 +0000
To: Tom Trevethan <tom@commerceblock.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <CYPuSF4lMyhP0L21Z5fC45i_nIMdh2XLrFio4-BE3ci6YQ5CYbpjjq-aaimP3AuwND4ah6yN5PWcDGuKvg_jkBxwsXA9aWfQmK9YjJrB-RA=@protonmail.com>
In-Reply-To: <CAJvkSsfJ-ep_WA1gCCBUeLUF4FKoXiCQ+t+c6KnOUQx8xEbH_Q@mail.gmail.com>
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>
 <CAJvkSsfJ-ep_WA1gCCBUeLUF4FKoXiCQ+t+c6KnOUQx8xEbH_Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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

Good morning Tom,

> Hi ZmnSCPxj,
>
> > The SE can run in a virtual environment that monitors deletion events a=
nd records them.
> > Such a virtual environment could be set up by a rootkit that has been i=
nstalled on the SE hardware.
> > Thus, even if the SE is honest, corruption of the hardware it is runnin=
g on can allow recovery of old privkeys and violation of the tr\*st assumpt=
ion.
>
> This is true, but this threat can be mitigated with secured infrastructur=
e and the use of hardware security modules/trusted execution environments t=
hat enable secure (and potentially attestable) deletion.=C2=A0
>
> > Compare this to, for example, TumbleBit or Wasabi.
> > In those cases, even if the service providing the mixing is corrupted b=
y a rootkit on the hardware running the honest service software in a virtua=
l environment and monitoring all its internal state and communications, the=
y cannot lead to loss of funds even with cooperation of previous participan=
ts.
> >They can at most be forced into denial-of-service, but not outright thef=
t of coins.
>
> Yes, I agree. But on the other side of the scale is a comparison with cen=
tralised mixing services, which remain extremely popular.=C2=A0
>
> > I admit the new solution is superior blockspace-wise, if you consider m=
ultiple mixing rounds.=C2=A0
>
> The aim of the solution is to replicate the UX (in terms of speed) of a c=
ompletely 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 mo=
re difficult (requiring collusion=C2=A0with previous owners), has an in-bui=
lt 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 p=
rivacy guarantees as the above mentioned trust-minimised protocols.=C2=
=A0

I believe the slowness of TumbleBit and Wasabi have less to do with securit=
y than with gathering enough participants to get a reasonable anonymity set=
.

If the statechain entity itself does not participate and put up funds that =
its clients can acquire quickly, than a similar waiting period would be nec=
essary anyway to gather enough participants to make the swapping worthwhile=
.
This would then fail your goal of speed.

If the statechain entity *does* act as a participant, then a client could a=
cquire a new coin fairly quickly (as the statechain entity would be a "part=
icipant of last resort" with which it could swap right now), but the "previ=
ous participant" in that case would be the statechain entity itself, making=
 its ability to outright steal funds absolutely certain, and thus not much =
better than a mixer that provides "put money in this address, I will send y=
ou money in your address" service.
(unless I can do a cut-and-choose on the hardware, i.e. buy multiple instan=
ces and reverse-engineer all except a randomly-selected one to check for ha=
rdware defects that may allow extraction of privkeys, and then use the hard=
ware that remains, I do not think the security of TEEs/HSMs is at all high.
And the TEE/HSM would be directly possessed by the statechain entity and no=
t me, presumably I as client of the statechain entity cannot audit that, so=
 ---)

If you are going to have a maker-taker model, where takers spend money to g=
et immediate swaps for the time that makers spend waiting, then I suggest t=
hat the SwapMarket plan by Chris Belcher would only require some number of =
confirmations of various transactions to get superior security, which would=
 be a better tradeoff than what statechains provide.


Regards,
ZmnSCPxj