From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7132AC0051 for ; Tue, 22 Sep 2020 15:32:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 4EB6B866F4 for ; Tue, 22 Sep 2020 15:32:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK9njxSWCW3x for ; Tue, 22 Sep 2020 15:32:19 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ej1-f66.google.com (mail-ej1-f66.google.com [209.85.218.66]) by whitealder.osuosl.org (Postfix) with ESMTPS id DA62A866E3 for ; Tue, 22 Sep 2020 15:32:18 +0000 (UTC) Received: by mail-ej1-f66.google.com with SMTP id i26so23457322ejb.12 for ; Tue, 22 Sep 2020 08:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=commerceblock-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5+8gNsnzfpTW0TlKb5SWz/CQG1PDECabrDC123NFXFU=; b=Qkx/wvswFVvSJUV7+2UxmIetvA8w6NFWMuOGHxyUm/Bc3LtOwb6WeasgN3uWkD1lK1 OU0U5YEbGBOZzFJg8EQNpL5Jzx9k6hdHB81IHjj7dVlpEdDbKAyDZhY/qS84ln5kWeAq fnMNet8kqkGeQtYcvmF25cBStlf+VomTn5FgIn3exjYPS84ojsy2psveU8C1QGKpl7ps wxinQxLAO9arIIMLb7Dcf90nj19dtAwU15OS4EEBOHnMpUBoB90Oz1yBYcmuLRID5/lg SRbzT3n2zOvR4SvQzfs3hcCNETt59aiF0VmZxihgzttXmdRpXcK15PnPa9oNGT7Jb77T me+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5+8gNsnzfpTW0TlKb5SWz/CQG1PDECabrDC123NFXFU=; b=Xrhxi27AVRoXd9a4grStuTS7gQP7PElrfq8MIROHCYu/+p763/iXbdM+8MSskemd3E 9CLMXbaZ0Kis4XogoeG9VT5yzB6jIGezBoM/fTuO+TbBg3jEd9CXVDKQ1+ZYl9YxIhFh pl/z3i+odOq+RmwPk+CJfoeJlIrcaujCqKAsRKdu/DrM+cwILtuqrh5zOLugeP0zkWGD jw6ej4uPaZQ04afmdsH8e9O3GhhXP/nkerIRSvUMWJfFcmLIKJy8CakSAir+/IjvLRYo LExwXrEC/LDyJuq8zYuV6LZR6NZ3vsGnSjn/e+9XQVO/YvYZnnVTxO7N4c+iYtcehVhV i5fw== X-Gm-Message-State: AOAM532rOKg/RcwrxYbUQ+6inI+81R6wgnd4vqoI6c9umvzWT5W2QlBD iYx8OzFmqe12G0IF1/KJ2X/Y53PW6ttPnxH//VQL X-Google-Smtp-Source: ABdhPJwk9GFQz9XxNZPBu6pFaFd2t90Pcu/Tv/ktOsR9NhsLJvwZg1fbxNs1PC33yCXmngtvFi6wQn1eGtfjg316RLw= X-Received: by 2002:a17:906:9a1:: with SMTP id q1mr5475030eje.30.1600788737085; Tue, 22 Sep 2020 08:32:17 -0700 (PDT) MIME-Version: 1.0 References: <2Abk4Gqv5hJyGtA8Gg1WCP5RNuyUFkmRn1uUKp_mdUaXrRTz4SDBTPi0MGU7D5jj36VSzrqsIiO5lMR4gGRApRX2jyp8vXDeHBnFt-6ca-g=@protonmail.com> In-Reply-To: From: Tom Trevethan Date: Tue, 22 Sep 2020 16:32:06 +0100 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="00000000000008f04605afe8ac4e" X-Mailman-Approved-At: Tue, 22 Sep 2020 15:38:03 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 15:32:20 -0000 --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 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
Hi ZmnSCPxj,
=

> The SE c= an run in a virtual environment that monitors deletion events and records t= hem.
> Such a virtual environment could be set up by a rootkit that h= as been installed on the SE hardware.
> 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.

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

> Compare this to,= for example, TumbleBit or Wasabi.
> 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.
>They can at most be force= d into denial-of-service, but not outright theft of coins.
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>

> I admit the new solution is superior blockspa= ce-wise, if you consider multiple mixing rounds.=C2=A0

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

Cheers,

Tom
<= /div>
O= n Tue, Sep 22, 2020 at 2:00 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
Good morning Tom,

> Hi ZmnSCPxj,
>
> >=C2=A0I think the entire point of non-custodiality ***is*** trust = minimization.
>
> 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

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 = 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 ot= her 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 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.<= br> 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
--00000000000008f04605afe8ac4e--