path: root/7b/6d84d864bd9351a441b6d0b6b826838d0578e4

Return-Path: <tom@commerceblock.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CC77BC0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 21:52:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id C129620789
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 21:52:42 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 76bu4ZMt6KLe
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 21:52:41 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com
 [209.85.218.45])
 by silver.osuosl.org (Postfix) with ESMTPS id C464F2052E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 21:52:40 +0000 (UTC)
Received: by mail-ej1-f45.google.com with SMTP id q13so19883742ejo.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 14:52:40 -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=Ci0Sr7cGSnuM08gvSv1Ip/FaZLWnTlnzS+tYcMDvwvU=;
 b=SZDV84sHNvEeFuWMgULI76y43GH7BKSOLt9vX700y3Wjb8T7CuSbc/cDYyo8phmq2E
 cwDwEJm6+jq5wfY4nojDALGIdFy+FS/3TPEl8XJRQrBBULzom0hF7kcnwPzEJVBQ4KYk
 WgpmOa3bxAINcEoWNx3nCxi0jsbYr+L+52TUkb/Ajed0j9GZjI11Omm4y+PwVyyvG4/K
 YPVynROIU0Q8KuFNFNSnNLt6JCSpzfzZiUUA+t/ek9Emn2zWtH0nb8iE2z9Idyg+wKwl
 1OK2u5jEl/l6Du48WaHqGpiarklTSmkmy9Ds+177dIl/eslUc0Xak9YHzlcQBzj0HhUQ
 Psqw==
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=Ci0Sr7cGSnuM08gvSv1Ip/FaZLWnTlnzS+tYcMDvwvU=;
 b=ivZB2qmy9gmZlkoJgEe6EksvRZtsiFv2pu15+Ih+y1v6INLnUfaA908k7E1NAUtTyR
 DvO8Lmmx+fZqS/mscMIOS2D6WzK5CTTP7lYXPOcQquoSjGmIdekFE3eFVm/o59h8ECSh
 oNoemqHE/nUAcO5nnTAfCggDJl2sQx9cvsKe/uBn44Mo/WzWz+j+t/oz4O8EONf3lvDw
 fm/X8rJ0HH9Hq3I4WLdSs+gtubgskvN6OfMFmFMQ+jqFAu8KEBMGNRjwYepWYM6hHx92
 Me/1f6SOPHqWoS9xwITAtTcKzQQ2QmrQabZQBCxjy2jnFXbFdqivEeb4DvybPWhTuV2b
 Wldg==
X-Gm-Message-State: AOAM530qe/hZ+gLBTjqApZIXhB2hvcD9YbsjkXm0e91s1PAONkzYpVrs
 jY8eVYLAoMLr5D7eTALe8RCM97BMtcraKNCdVopd
X-Google-Smtp-Source: ABdhPJxGIO/FQiDCKP4OS0RuGNv8xUPQrywpdYccY1TERjV8VprNpJli6kyvK1ut9ArL5flTOegTiM9lfRMgvf3eycA=
X-Received: by 2002:a17:906:8690:: with SMTP id
 g16mr1545695ejx.187.1600725159088; 
 Mon, 21 Sep 2020 14:52:39 -0700 (PDT)
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>
In-Reply-To: <TC2UtcaDKCIkjtn41sIutqApciyqaGCD3SBSEWLBk4OT12siSkWIsp2LMmlmA0CLzUNuG1W8w-hB4Pq3ko1uGwbxpjxezFWKPq4C7OLUQo8=@protonmail.com>
From: Tom Trevethan <tom@commerceblock.com>
Date: Mon, 21 Sep 2020 22:52:28 +0100
Message-ID: <CAJvkSseWZYH-dOvkFXmtKJgJOfv09La8sTb4e+2nvZYKTxNafg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000007da92805afd9def9"
X-Mailman-Approved-At: Mon, 21 Sep 2020 21:58:57 +0000
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.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2020 21:52:42 -0000

--0000000000007da92805afd9def9
Content-Type: text/plain; charset="UTF-8"

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.

> 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). If users do trust
that it is doing this, then they don't need to worry about the SE being
shut down or even hacked - assuming the SE has deleted *old* keys (in the
past) then there is no way the current owner can have their funds stolen -
this is a sort of 'forward security' that makes the protocol much more
secure than a fully custodial one which stores the full key(s) at all times
(and I would argue therefore has higher trust requirements). The SE cannot
decide or be compelled to seize any specific coin without conspiring in
advance to: 1. Keep the expired key shares and 2. Collude with a previous
owner of that coin. We have designed a scheme to ensure secure deletion of
shares using HSMs, and are exploring the possibility of using remote
attestation to prove key share deletion on the HSM to users.

These are different properties compared to a federated sidechain, which
while lowering trust requirements with an m-of-n peg, remains custodial (if
the m-of-n collude at any point they can steal ALL the money, and if (n -
m + 1) are shut down/disappear then the money is gone forever). However, in
the same way as a federated sidechain, users retain a verifiable proof of
their unique ownership of a coin and must sign a peg-out transaction to
withdraw on-chain. The publication of this peg-out transaction is proof
that the current owner authenticated the on-chain spend, and so any absence
of this is a signal that the SE should not be trusted.

Cheers,

Tom

On Mon, Sep 21, 2020 at 2:14 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Tom,
>
> > Hi ZmnSCPxj,
> >
> > Thanks for the reply.
> >
> > > Okay, I suppose this is much too high-level a view, and I have no idea
> what you mean by "statecoin" exactly.
> >
> > Sorry, most of the protocol details are in the links, but terminology
> should be made clearer. A "statecoin" is a UTXO that is a 2-of-2 between
> the owner and SE (the tr*sted signing server) i.e. can be transferred
> off-chain.
> >
> > Also, should have been clear that `addr1` is the 'statecoin address'
> which is different from the on-chain address (the shared public key the
> bitcoin is paid to). The on-chain address does not change, whereas
> the 'statecoin address' changes with each new owner and is used to
> authenticate owners to the SE and act as proof of ownership on
> the statechain - it is not related to the onchain address/pubkey and
> controlled by the owner only.
> >
> > > So it seems to me that this requires tr\*st that the coordinator is
> not going to collude with other participants.
> >
> > This is correct. The SE also must be trusted to not actively defraud
> users. The main advantage of this scheme is that assuming the SE can be
> trusted, it is strictly non-custodial.
> >
> > > This is strictly worse than say Wasabi, where the coordinator
> colluding with other participants only allows the coordinator to break
> privacy, not outright steal funds.
> > > It seems to me that the trust-minimized CoinSwap plan by belcher_ is
> superior to this, with reduced scope for theft.
> >
> > This is true if the overriding aim is trust minimisation, but not if the
> aim is speed and cost while staying non-custodial. Off-chain SE
> transactions are near instant and orders of magnitude cheaper than
> on-chain. Probably best thought of as a non-custodial centralised mixer.
>
>
> I think the entire point of non-custodiality ***is*** trust minimization.
>
> 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?
>
> So I think touting "non-custodial" is relatively pointless if tr\*st is
> not minimized.
>
> (I am aware there is an update mechanism, either Decker-Russell-Osuntokun
> or Decker-Wattenhofer, that is anchored off he onchain transaction output,
> but anyone who can recover the raw keys for signing the funding transaction
> output --- such as a previous participant and a corrupt SE --- can very
> easily bypass the mechanism.)
>
> For example, in my previous description of [implementing investment
> aggregation](
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018055.html),
> while I admit you need tr\*st in the business owners who you are investing
> in, it does not require tr\*st in the aggregator, due to the n-of-n, which
> cannot be reconstructed by the aggregator and all other participants
> without you.
>
> Regards,
> ZmnSCPxj
>
>

--0000000000007da92805afd9def9
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><span style=
=3D"color:rgb(80,0,80)">&gt;=C2=A0</span>I think the entire point of non-cu=
stodiality ***is*** trust minimization.</div><div><br></div><div>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.=C2=A0</div><div><br></div><div>&gt; The main=
 objection against custodiality is that someone else can prevent you from s=
pending the coin.</div>&gt; If I have to tr\*st the SE to not steal the fun=
ds, 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?<div><br></div><div>I would argue that it is no=
n-custodial if the SE performs the protocol as specified (i.e. securely del=
eting expired key shares). If users do trust that it is doing this, then th=
ey don&#39;t need to worry about the SE being shut down or even hacked - as=
suming the SE has deleted *old* keys (in the past) then there is no way the=
 current owner can have their funds stolen - this is a sort of &#39;forward=
 security&#39; that makes the protocol much more secure than a fully custod=
ial one which stores the full key(s) at all times (and I would argue=C2=A0t=
herefore has higher trust requirements). The SE cannot decide or be compell=
ed to seize any specific coin without conspiring in advance to: 1. Keep the=
 expired key shares and 2. Collude with a previous owner of that coin. We h=
ave designed a scheme to ensure secure deletion of shares using HSMs, and a=
re exploring the possibility of using remote attestation to prove key share=
 deletion on the HSM to users.=C2=A0</div><div><br></div><div>These are dif=
ferent properties compared to a federated sidechain, which while lowering t=
rust requirements with an m-of-n peg, remains custodial (if the=C2=A0m-of-n=
 collude at any point they can steal ALL the money, and if (n - m=C2=A0+ 1)=
 are shut down/disappear then the money is gone forever). However, in the s=
ame way as a federated sidechain, users retain a verifiable proof of their =
unique ownership of a coin and must sign a peg-out transaction to withdraw =
on-chain. The publication of this peg-out=C2=A0transaction is proof that th=
e current owner authenticated the on-chain spend, and so any absence of thi=
s is a signal that the SE should not be trusted.=C2=A0</div><div><br></div>=
<div>Cheers,</div><div><br></div><div>Tom</div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Sep 21, 2020 at 2:14=
 AM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@proton=
mail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">Good morning Tom,<br>
<br>
&gt; Hi ZmnSCPxj,<br>
&gt;<br>
&gt; Thanks for the reply.=C2=A0<br>
&gt;<br>
&gt; &gt; Okay, I suppose this is much too high-level a view, and I have no=
 idea what you mean by &quot;statecoin&quot; exactly.<br>
&gt;<br>
&gt; Sorry, most of the protocol details are in the links, but terminology =
should be made clearer. A=C2=A0&quot;statecoin&quot; is a UTXO that is a 2-=
of-2 between the owner and SE (the tr*sted signing server) i.e. can be tran=
sferred off-chain.=C2=A0<br>
&gt;<br>
&gt; Also, should have been clear that `addr1` is the &#39;statecoin=C2=A0a=
ddress&#39; which is different from the on-chain address (the shared public=
 key the bitcoin is paid to). The on-chain address does not change, whereas=
 the=C2=A0&#39;statecoin=C2=A0address&#39; changes with each new owner and =
is used to authenticate owners to the SE and act as proof of ownership on t=
he=C2=A0statechain - it is not related to the onchain address/pubkey and co=
ntrolled by the owner only.=C2=A0<br>
&gt;<br>
&gt; &gt; So it seems to me that this requires tr\*st that the coordinator =
is not going to collude with other participants.<br>
&gt;<br>
&gt; This is correct. The SE also must be trusted to not actively defraud u=
sers. The main advantage of this scheme is that assuming the SE can be trus=
ted, it is strictly non-custodial.=C2=A0<br>
&gt;<br>
&gt; &gt; This is strictly worse than say Wasabi, where the coordinator col=
luding with other participants only allows the coordinator to break privacy=
, not outright steal funds.<br>
&gt; &gt; It seems to me that the trust-minimized CoinSwap plan by belcher_=
 is superior to this, with reduced scope for theft.<br>
&gt;<br>
&gt; This is true if the overriding aim is trust minimisation, but not if t=
he aim is speed and cost while staying=C2=A0non-custodial. Off-chain SE tra=
nsactions are near instant and orders of magnitude cheaper than on-chain. P=
robably best thought of as a non-custodial centralised mixer.=C2=A0<br>
<br>
<br>
I think the entire point of non-custodiality ***is*** trust minimization.<b=
r>
<br>
The main objection against custodiality is that someone else can prevent yo=
u from spending the coin.<br>
If I have to tr\*st the SE to not steal the funds, is it *really* non-custo=
dial, when after a swap, a corrupted SE can, in collusion with other partic=
ipants, take control of the coin and prevent me from spending it as I wish?=
<br>
<br>
So I think touting &quot;non-custodial&quot; is relatively pointless if tr\=
*st is not minimized.<br>
<br>
(I am aware there is an update mechanism, either Decker-Russell-Osuntokun o=
r Decker-Wattenhofer, that is anchored off he onchain transaction output, b=
ut anyone who can recover the raw keys for signing the funding transaction =
output --- such as a previous participant and a corrupt SE --- can very eas=
ily bypass the mechanism.)<br>
<br>
For example, in my previous description of [implementing investment aggrega=
tion](<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
20-July/018055.html" rel=3D"noreferrer" target=3D"_blank">https://lists.lin=
uxfoundation.org/pipermail/bitcoin-dev/2020-July/018055.html</a>), while I =
admit you need tr\*st in the business owners who you are investing in, it d=
oes not require tr\*st in the aggregator, due to the n-of-n, which cannot b=
e reconstructed by the aggregator and all other participants without you.<b=
r>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
</blockquote></div>

--0000000000007da92805afd9def9--