path: root/0c/e9512370077e7dbc6c8613e0df5f4e2f2b0f60

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 27F92C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 00:55:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id F15352035E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 00:55:01 +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 uY1b1sWd5AJz
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 00:55:00 +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 137402010E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 00:55:00 +0000 (UTC)
Received: by mail-ej1-f45.google.com with SMTP id gx22so6318055ejb.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 20 Sep 2020 17:54:59 -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=uMFilW3givvqQjfQ+g7Zjw04x1T3ODOxWQ02PujzG1k=;
 b=VbBO9bhA4k6C7KLeouq0D+MVyXWkXrkQd9VNEcPOYjc3UdEvstRXG4ktR1W9VeAV4i
 g/xtBBEGsKkXbI7/g3VCKMtfsF6SOPAKTPjcb7/NP1oPdLDztSChwQHQD3AQBOywoO94
 xbcWc/o2zMfLVfaU8YdnalveCi0fDwri7ASC4q08qzA0K3Vqawxj1sp5PU2eGb+tVS0o
 xggk+8bioKE22NyZ0lonMPjnsRlZpz4Fg43sk+TNpxqJeqgRd6bVHeJ0tbbMTjuHYxsC
 3nA2NTr0zRFNKhXespoC+E3hnFThactIuyi0g2qKjxDYZoag6+AW+pacZ1a/Z4mgc+vo
 g6Xg==
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=uMFilW3givvqQjfQ+g7Zjw04x1T3ODOxWQ02PujzG1k=;
 b=Sy8+oIgACFpBw9DVMZu8TmXA3MuLiD45gEbpk5NHVidN5criTcP/oOYfXAMbnghj4L
 dtQn7rGSTbc2xHhURBaLtI+UjZd0FdKboilGzptYj9MDBK4gSo6CnOhkP6Zy8qVJEO41
 Pt9Xz0R9UX1KkaTsgEbVfsVhO7huzOVw8VcTocsuWjzZ3tFcEFnWhd6pqV8eihhTZhV9
 6uCquhF+/etwMdvTo1amfHZXOuJrJ3pzUua8ZIFLJE+V2EhrgSjTHfe5r2NSv8x9I9F/
 vFgupDFeqlQ0NiZYZxcL3NOPe9M+Gx6V8YJMlOu7/lQTIIKKkyU4HG999xIUbdJAllol
 DGjQ==
X-Gm-Message-State: AOAM530WWO2K3WVbGLFkU/fgnJ1TurAt9FKIf76bwK68DfF+Im4FtW05
 FBZr1d9HvNQANHz0RQwaRCPF/sD/iI9Yk2Kjqijn
X-Google-Smtp-Source: ABdhPJyKhh61+lSGWvbGAFo7SzBbrHZZexVvN6zCXVylQk2FAOHxp5PCSxwq+rgtsE2R6TgBdjGGZqPgEgxfd5pH12Y=
X-Received: by 2002:a17:906:8690:: with SMTP id
 g16mr46424867ejx.187.1600649698420; 
 Sun, 20 Sep 2020 17:54:58 -0700 (PDT)
MIME-Version: 1.0
References: <CAJvkSseOx8mwYowLEnfKVEUuM5xsiYkbLdAvtaYxPpu4jY9pCg@mail.gmail.com>
 <2Abk4Gqv5hJyGtA8Gg1WCP5RNuyUFkmRn1uUKp_mdUaXrRTz4SDBTPi0MGU7D5jj36VSzrqsIiO5lMR4gGRApRX2jyp8vXDeHBnFt-6ca-g=@protonmail.com>
In-Reply-To: <2Abk4Gqv5hJyGtA8Gg1WCP5RNuyUFkmRn1uUKp_mdUaXrRTz4SDBTPi0MGU7D5jj36VSzrqsIiO5lMR4gGRApRX2jyp8vXDeHBnFt-6ca-g=@protonmail.com>
From: Tom Trevethan <tom@commerceblock.com>
Date: Mon, 21 Sep 2020 01:54:47 +0100
Message-ID: <CAJvkSse5GDxzrDc0OeNSoHV90tsSvr-oCgY_P+p4O4T6PDUNpA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000af473f05afc84cf7"
X-Mailman-Approved-At: Mon, 21 Sep 2020 00:57:29 +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 00:55:02 -0000

--000000000000af473f05afc84cf7
Content-Type: text/plain; charset="UTF-8"

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.

Tom

On Wed, Sep 16, 2020 at 2:04 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Tom,
>
>
> > Here is a high-level description of how this blinding can operate - with
> the aim that the conductor does learn how the ownership of individual coins
> has changed.
> > For example, imagine 4 individuals (A,B,C and D) who own equal value
> statecoins utxo1, utxo2, utxo3 and utxo4 respectively. They want to swap
> ownership privately, trusting the conductor/SCE to enforce atomicity. In
> other words, the conductor will randomly assign each statecoin to one of
> the owners (the mix), but will not be able to gain knowledge of that
> assignment.
> > 1. A,B,C and D signal their participation by signing the swap_token
> (which has details of the swap) with the proof-key of their input coin. (A
> statecoin address is formed of a concatenation of the proof key and backup
> address).
> > 2. Each of A,B,C and D then generate a new statecoin address (where they
> what to receive the swapped coin), which they blind (encrypt) and sign with
> the proof key of their input coin: add1, add2, add3 and add4 and send to
> the conductor.
> > 3. The conductor authenticates each signature and then signs each
> payload (i.e. the blinded destination addresses) with a blinded signature
> scheme and returns these signatures to A,B,C and D.
> > 4. Each of A,B,C and D then reconnects over TOR with a new identity.
> > 5. Each of A,B,C and D then send their unblinded destination address
> with the conductor signature to the conductor (the conductor now knows that
> these 4 addresses belong to A,B,C and D, but not which ones map to each
> input.)
> > 6. The conductor randomly assigns each address to one of utxo1, utxo2,
> utxo3 and utxo4 (e.g. utxo1:add3, utxo2:add1, utxo3:add4 and utxo4:add2)
> and requests each participant to initiate the transfer to the given address.
> > 7. Each participant then finalises each transfer - if any transfer fails
> (due to a participant disappearing or acting maliciously) then all
> transfers are reverted - here atomicity is guaranteed by the SCE.
>
> Okay, I suppose this is much too high-level a view, and I have no idea
> what you mean by "statecoin" exactly.
>
> Let me try to fill in the details and correct me if I am wrong okay?
>
> I imagine that the `add1` etc. are implemented as 2-of-2 between the
> purported owner and the tr\*sted signing module.
> The owner of that address can easily create this knowing only the pubkey
> of the tr\*sted signing module.
>
> The initial `utxo1`... are also in similar 2-of-2s.
>
> (they cannot be unilateral control, since then a participant can broadcast
> a replacement transaction, even without RBF, almost directly to miners.)
>
> So when the coordinator talks to Alice, who owns `utxo1` and destination
> `addr1`, it provides partially-signed transactions of `utxo#:addr#`.
> Alice then checks that its `addr1` is on one of those transactions, with
> the correct amount, then provides a signature for the `utxo1:addr#`
> transaction.
>
> However, then the coordinator, who happens to be in cahoots with Bob,
> Charlie, and Dave, simply broadcasts that transaction without soliciting
> the `utxo#:addr1` transaction.
>
> So it seems to me that this requires tr\*st that the coordinator is not
> going to collude with other participants.
> 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.
> The plan by belcher_ is potentially compatible with using watchtowers that
> can be used for both CoinSwap and Lightning as well (if we design it well)
> with the watchtower potentially not even learning whether it is watching a
> CoinSwap or a Lightning channel.
>
> Though of course I could be misunderstanding the scheme itself.
> Is my understanding correct?
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"ltr">Hi ZmnSCPxj,<div><br></div><div>Thanks for the reply.=C2=
=A0</div><div><br></div><div>&gt; Okay, I suppose this is much too high-lev=
el a view, and I have no idea what you mean by &quot;statecoin&quot; exactl=
y.</div><div><br></div><div>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 s=
erver) i.e. can be transferred off-chain.=C2=A0</div><div><br></div><div>Al=
so, should have been clear that `addr1` is the &#39;statecoin=C2=A0address&=
#39; which is different from the on-chain address (the shared public key th=
e 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 the=C2=
=A0statechain - it is not related to the onchain address/pubkey and control=
led by the owner only.=C2=A0</div><div><br></div><div>&gt; So it seems to m=
e that this requires tr\*st that the coordinator is not going to collude wi=
th other participants.</div><div><br></div><div>This is correct. The SE als=
o 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-custodia=
l.=C2=A0</div><div><br></div><div>&gt; This is strictly worse than say Wasa=
bi, where the coordinator colluding with other participants only allows the=
 coordinator to break privacy, not outright steal funds.<br>&gt; It seems t=
o me that the trust-minimized CoinSwap plan by belcher_ is superior to this=
, with reduced scope for theft.<br></div><div><br></div><div>This is true i=
f the overriding aim is trust minimisation, but not if the aim is speed and=
 cost while staying=C2=A0non-custodial. Off-chain SE transactions are near =
instant and orders of magnitude cheaper than on-chain. Probably best though=
t of as a non-custodial centralised mixer.=C2=A0</div><div><br></div><div>T=
om</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Wed, Sep 16, 2020 at 2:04 AM ZmnSCPxj &lt;<a href=3D"mailto:ZmnS=
CPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">Good morning Tom,<br>
<br>
<br>
&gt; Here is a high-level description of how this blinding can operate - wi=
th the aim that the conductor does learn how the ownership of individual co=
ins has changed.<br>
&gt; For example, imagine 4 individuals (A,B,C and D) who own equal value s=
tatecoins utxo1, utxo2, utxo3 and utxo4 respectively. They want to swap own=
ership privately, trusting the conductor/SCE to enforce atomicity. In other=
 words, the conductor will randomly assign each statecoin to one of the own=
ers (the mix), but will not be able to gain knowledge of that assignment.<b=
r>
&gt; 1. A,B,C and D signal their participation by signing the swap_token (w=
hich has details of the swap) with the proof-key of their input coin. (A st=
atecoin address is formed of a concatenation of the proof key and backup ad=
dress).<br>
&gt; 2. Each of A,B,C and D then generate a new statecoin address (where th=
ey what to receive the swapped coin), which they blind (encrypt) and sign w=
ith the proof key of their input coin: add1, add2, add3 and add4 and send t=
o the conductor.<br>
&gt; 3. The conductor authenticates each signature and then signs each payl=
oad (i.e. the blinded destination addresses) with a blinded signature schem=
e and returns these signatures to A,B,C and D.<br>
&gt; 4. Each of A,B,C and D then reconnects over TOR with a new identity.<b=
r>
&gt; 5. Each of A,B,C and D then send their unblinded destination address w=
ith the conductor signature to the conductor (the conductor now knows that =
these 4 addresses belong to A,B,C and D, but not which ones map to each inp=
ut.)<br>
&gt; 6. The conductor randomly assigns each address to one of utxo1, utxo2,=
 utxo3 and utxo4 (e.g. utxo1:add3, utxo2:add1, utxo3:add4 and utxo4:add2) a=
nd requests each participant to initiate the transfer to the given address.=
<br>
&gt; 7. Each participant then finalises each transfer - if any transfer fai=
ls (due to a participant disappearing or acting maliciously) then all trans=
fers are reverted - here atomicity is guaranteed by the SCE.<br>
<br>
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>
<br>
Let me try to fill in the details and correct me if I am wrong okay?<br>
<br>
I imagine that the `add1` etc. are implemented as 2-of-2 between the purpor=
ted owner and the tr\*sted signing module.<br>
The owner of that address can easily create this knowing only the pubkey of=
 the tr\*sted signing module.<br>
<br>
The initial `utxo1`... are also in similar 2-of-2s.<br>
<br>
(they cannot be unilateral control, since then a participant can broadcast =
a replacement transaction, even without RBF, almost directly to miners.)<br=
>
<br>
So when the coordinator talks to Alice, who owns `utxo1` and destination `a=
ddr1`, it provides partially-signed transactions of `utxo#:addr#`.<br>
Alice then checks that its `addr1` is on one of those transactions, with th=
e correct amount, then provides a signature for the `utxo1:addr#` transacti=
on.<br>
<br>
However, then the coordinator, who happens to be in cahoots with Bob, Charl=
ie, and Dave, simply broadcasts that transaction without soliciting the `ut=
xo#:addr1` transaction.<br>
<br>
So it seems to me that this requires tr\*st that the coordinator is not goi=
ng to collude with other participants.<br>
This is strictly worse than say Wasabi, where the coordinator colluding wit=
h other participants only allows the coordinator to break privacy, not outr=
ight steal funds.<br>
<br>
It seems to me that the trust-minimized CoinSwap plan by belcher_ is superi=
or to this, with reduced scope for theft.<br>
The plan by belcher_ is potentially compatible with using watchtowers that =
can be used for both CoinSwap and Lightning as well (if we design it well) =
with the watchtower potentially not even learning whether it is watching a =
CoinSwap or a Lightning channel.<br>
<br>
Though of course I could be misunderstanding the scheme itself.<br>
Is my understanding correct?<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--000000000000af473f05afc84cf7--