Date: Tue, 22 Sep 2020 01:00:43 +0000
To: Tom Trevethan <tom@commerceblock.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <KRJoyx0BjttYJnlGVY3hu2T_1bTPcpU1Vq639OYyQptXx6Xm0vkrCN-23ngBK3fs0ti2dT4i4LHIxOaxqNMACJ9N27jPqoPqzaBpxiOIH8s=@protonmail.com>
In-Reply-To: <CAJvkSseWZYH-dOvkFXmtKJgJOfv09La8sTb4e+2nvZYKTxNafg@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>
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,
>
> >=C2=A0I think the entire point of non-custodiality ***is*** trust minimi=
zation.
>
> 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-cu=
stodial and funds cannot be frozen/seized.=C2=A0

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 thei=
r finances, not focus on whether storage is "custodial" or not.

So I still suggest that, for purposes of technical discussion, we should av=
oid the term "custodial" and instead consider technical risks.

>
> > The main objection against custodiality is that someone else can preven=
t you from spending the coin.
> > If I have to tr\*st the SE to not steal the funds, is it *really* non-c=
ustodial, when after a swap, a corrupted SE can, in collusion with other pa=
rticipants, take control of the coin and prevent me from spending it as I w=
ish?
>
> 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 r=
ecords them.
Such a virtual environment could be set up by a rootkit that has been insta=
lled 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 en=
vironment and monitoring all its internal state and communications, they ca=
nnot 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 o=
f coins.

Thus, I believe this solution is inferior to these older solutions, at leas=
t in terms of financial security.

I admit the new solution is superior blockspace-wise, if you consider multi=
ple 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 obviati=
ng the blockspace savings.


The above remain true regardless of what definition of "custodial" you have=
.

Regards,
ZmnSCPxj