path: root/e9/ecb5ce141cd2ed0dcf48051a234d5adffe0537

Return-Path: <tom@commerceblock.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3494BC0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 13 Sep 2020 22:22:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 23E0C8574B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 13 Sep 2020 22:22:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id vOAETH4y_y-h
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 13 Sep 2020 22:22:48 +0000 (UTC)
X-Greylist: delayed 00:07:45 by SQLgrey-1.7.6
Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com
 [209.85.218.52])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 8657785550
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 13 Sep 2020 22:22:48 +0000 (UTC)
Received: by mail-ej1-f52.google.com with SMTP id i26so20480924ejb.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 13 Sep 2020 15:22:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=commerceblock-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:from:date:message-id:subject:to;
 bh=8BYGwmRIUoBaS8sLbG5Z22eZu3xRGx+mGWbbPtZff24=;
 b=N30Z0CAn+97UFF3F27cJtq1dZMKSdzOE0sni3BA9plM+YwfUGWKpL/aM4yR+Rc7yya
 O57rMXnjoXmIxTwtkHJpb+suWRR+1urEmrNSqDiM+a4ltpfbXDS4T7gbRcheU/JeORwY
 IBsP3UOnbaYk394zFmT1VQ87UkFnJI8af1fhCWn62l+G35t+Vx/3+D2tO2awhGkE3r/Y
 kTx2ZEC60NiBUpkV7yKblCEDEq0YfVxwZTLrY1Be6/ivLAt6rtb/2vOA3bYcF6q98fJ4
 K6Zb2WdXFyjGlU61B6bCmDM2zKpK21ZWAxqjjRhHj0iKAm/nXGJTGXRGx9WmsbiQc8ep
 tifw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=8BYGwmRIUoBaS8sLbG5Z22eZu3xRGx+mGWbbPtZff24=;
 b=TXl9a8hqSmjFLzbF+QEVrxHCjaMa+7e6BoxsrRjSFB8Pg+Bk+/7Nq/5GQviERSB/iz
 Eb+wmM2dcRQ2OgwONuGmFSv2E14OvMQPRqRA9QqyC5ym6hnqPc5ZmZg6vDykZ/EdfUKX
 430ayD1slXE3kPz2koOTjFFvseRQQDQxrcz8rjPsR9Uub9kXtP6qZZDk/FcsJXIhb3UA
 Mvkq8VtbGXkUYJgS0OHBiOXjkEp1IHWDE0G3rEHZT7lxdDGgsowo96yce3D4z1Yww/cD
 NMIJ9j+Y02ANFfu1xzmtT44sBxmuG+cMz1p8zkQfSA6eJvLfpXPFEHJuIbD/FBSlqh2r
 yhvg==
X-Gm-Message-State: AOAM533S971t56y0KfAcyNqKnlrw4IBj1atDNq2NwWpGR3jRZsLOpp8S
 2uLPctPQZcnZwIoG0VkS2W9m+WyE40NmVfhw+v2u0x4Md9lV
X-Google-Smtp-Source: ABdhPJzimdiTYFbLxmHfb4KfEacsIx2DNoo+kGIPKbdhBYA15Bt4eNOJvca5AmWoQKeongCZrvg0S37Mb7og0P0BYdQ=
X-Received: by 2002:a17:906:fa81:: with SMTP id
 lt1mr11618531ejb.459.1600035301027; 
 Sun, 13 Sep 2020 15:15:01 -0700 (PDT)
MIME-Version: 1.0
From: Tom Trevethan <tom@commerceblock.com>
Date: Sun, 13 Sep 2020 23:14:50 +0100
Message-ID: <CAJvkSseOx8mwYowLEnfKVEUuM5xsiYkbLdAvtaYxPpu4jY9pCg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000bf09f905af393fcd"
X-Mailman-Approved-At: Sun, 13 Sep 2020 23:11:10 +0000
Subject: [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: Sun, 13 Sep 2020 22:22:50 -0000

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

We are designing an off-chain coin-swap protocol that will work with the
statechain implementation we are developing (
https://github.com/commerceblock/mercury). The general idea is that coins
deposited with a statechain entity (statecoins) can be transacted
peer-to-peer off-chain in a way that the statechain entity (SCE) is
trusted, but the statecoins always remain in the custody of the owners. A
statecoin swapping service would enable owners to mix their coins with
other users, giving the same privacy benefits of on-chain CoinSwap
protocols, but by being off-chain statecoin swaps would be much faster and
cheaper.

The swapping service (conductor) would not have custody of the statecoins
at any point. The aim is to have the conductor coordinate the swap amongst
a group of statecoins (i.e. determine the which statecoin should be sent to
which new random owner in the group) without being able to learn the link
between owners and their provided addresses. To do this we will use a blind
signature scheme in a similar way to the zerolink protocol.

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.

The interesting problem we have with this protocol is how to assign blame
in the case that one or more participants in the swap causes it to fail, so
that the corresponding statecoins can be penalized (prevented from
participating in further swaps for some timeout) to make any DoS attack
costly. In the case of an on-chain coinjoin, this is easy: whoever didn't
sign their input is to blame. However, in our statechain system a statecoin
transfer is a two stage process (to update the private key shares): the
sender performs an operation with the SCE (transfer_sender) and then sends
an encrypted value to the receiver, who then performs the second operation
with the SCE (transfer_reciever) which updates the UTXO private key shares
for the new owner (
https://github.com/commerceblock/mercury/blob/master/doc/statechains.md for
more details). If the second stage fails (i.e. the values used for the key
update protocol are wrong) this could be due to either the sender sending a
bad/manipulated value to the receiver, or the receiver using bad values in
the second operation with the SCE. Essentially, either the sender or the
receiver can cause the transfer to fail, and it is not possible to
determine which one is malicious without revealing the encrypted value sent
between the sender and receiver (which must be kept secret from the SCE).

All this means that if a multi-party coinswap fails, we will know which
statecoin was involved in the failure, but we cannot determine whether the
sender or receiver of that coin caused the failure. One potential solution
to this is to have each sender generate a zero knowledge proof that the
encrypted value sent to the receiver is correct/valid (see last section in
https://github.com/commerceblock/mercury/blob/master/doc/swaps.md for more
details) which can be used to assign blame in a failure. This proof could
be generated and verified using a zkSNARK/zkSTARK framework, but this is
not trivial to implement and would likely add significant computational
burden to user wallets to generate proofs - so we would like to avoid this
if possible, and we are trying to come up with a simpler solution.

Any comments on the above are welcome, and happy to provide more details if
anyone is interested.

Cheers,

Tom

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

<div dir=3D"ltr">We are designing an off-chain coin-swap protocol that will=
 work with the statechain implementation we are developing (<a href=3D"http=
s://github.com/commerceblock/mercury">https://github.com/commerceblock/merc=
ury</a>). The general idea is that coins deposited with a statechain entity=
 (statecoins) can be transacted peer-to-peer off-chain in a way that the st=
atechain entity (SCE) is trusted, but the statecoins always remain in the c=
ustody of the owners. A statecoin swapping service would enable owners to m=
ix their coins with other users, giving the same privacy benefits of on-cha=
in CoinSwap protocols, but by being off-chain statecoin swaps would be much=
 faster and cheaper. <br><br>The swapping service (conductor) would not hav=
e custody of the statecoins at any point. The aim is to have the conductor =
coordinate the swap amongst a group of statecoins (i.e. determine the which=
 statecoin should be sent to which new random owner in the group) without b=
eing able to learn the link between owners and their provided addresses. To=
 do this we will use a blind signature scheme in a similar way to the zerol=
ink protocol.<br><br>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.<br>For example, imagine 4 individuals (A,B=
,C and D) who own equal value statecoins utxo1, utxo2, utxo3 and utxo4 resp=
ectively. They want to swap ownership privately, trusting the conductor/SCE=
 to enforce atomicity. In other words, the conductor will randomly assign e=
ach statecoin to one of the owners (the mix), but will not be able to gain =
knowledge of that assignment.<br>1. A,B,C and D signal their participation =
by signing the swap_token (which has details of the swap) with the proof-ke=
y of their input coin. (A statecoin address is formed of a concatenation of=
 the proof key and backup address).<br>2. Each of A,B,C and D then generate=
 a new statecoin address (where they what to receive the swapped coin), whi=
ch they blind (encrypt) and sign with the proof key of their input coin: ad=
d1, add2, add3 and add4 and send to the conductor.<br>3. The conductor auth=
enticates each signature and then signs each payload (i.e. the blinded dest=
ination addresses) with a blinded signature scheme and returns these signat=
ures to A,B,C and D.<br>4. Each of A,B,C and D then reconnects over TOR wit=
h a new identity.<br>5. Each of A,B,C and D then send their unblinded desti=
nation 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.)<br>6. The conductor randomly assigns each address to o=
ne of utxo1, utxo2, utxo3 and utxo4 (e.g. utxo1:add3, utxo2:add1, utxo3:add=
4 and utxo4:add2) and requests each participant to initiate the transfer to=
 the given address. <br>7. Each participant then finalises each transfer - =
if any transfer fails (due to a participant disappearing or acting maliciou=
sly) then all transfers are reverted - here atomicity is guaranteed by the =
SCE. <br><br>The interesting problem we have with this protocol is how to a=
ssign blame in the case that one or more participants in the swap causes it=
 to fail, so that the corresponding statecoins can be penalized (prevented =
from participating in further swaps for some timeout) to make any DoS attac=
k costly. In the case of an on-chain coinjoin, this is easy: whoever didn&#=
39;t sign their input is to blame. However, in our statechain system a stat=
ecoin transfer is a two stage process (to update the private key shares): t=
he sender performs an operation with the SCE (transfer_sender) and then sen=
ds an encrypted value to the receiver, who then performs the second operati=
on with the SCE (transfer_reciever) which updates the UTXO private key shar=
es for the new owner (<a href=3D"https://github.com/commerceblock/mercury/b=
lob/master/doc/statechains.md">https://github.com/commerceblock/mercury/blo=
b/master/doc/statechains.md</a> for more details). If the second stage fail=
s (i.e. the values used for the key update protocol are wrong) this could b=
e due to either the sender sending a bad/manipulated value to the receiver,=
 or the receiver using bad values in the second operation with the SCE. Ess=
entially, either the sender or the receiver can cause the transfer to fail,=
 and it is not possible to determine which one is malicious without reveali=
ng the encrypted value sent between the sender and receiver (which must be =
kept secret from the SCE). <br><br>All this means that if a multi-party coi=
nswap fails, we will know which statecoin was involved in the failure, but =
we cannot determine whether the sender or receiver of that coin caused the =
failure. One potential solution to this is to have each sender generate a z=
ero knowledge proof that the encrypted value sent to the receiver is correc=
t/valid (see last section in <a href=3D"https://github.com/commerceblock/me=
rcury/blob/master/doc/swaps.md">https://github.com/commerceblock/mercury/bl=
ob/master/doc/swaps.md</a> for more details) which can be used to assign bl=
ame in a failure. This proof could be generated and verified using a zkSNAR=
K/zkSTARK framework, but this is not trivial to implement and would likely =
add significant computational burden to user wallets to generate proofs - s=
o we would like to avoid this if possible, and we are trying to come up wit=
h a simpler solution. <br><br>Any comments on the above are welcome, and ha=
ppy to provide more details if anyone is interested. <br><br>Cheers,<br><br=
>Tom<br></div>

--000000000000bf09f905af393fcd--