path: root/ab/3ea8262ea991be9f100d7c0de1a7286397c63d

Return-Path: <gmkarl@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1F0A3C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 22:19:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 09CA5214E6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 22:19:03 +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 4N002xrqzGTY
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 22:18:57 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com
 [209.85.166.54])
 by silver.osuosl.org (Postfix) with ESMTPS id 9102621519
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 22:18:57 +0000 (UTC)
Received: by mail-io1-f54.google.com with SMTP id z25so17276345iol.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 15:18:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=5aV9TG0f+TZvgV8yP1wvsex3b7MkVpKqFo+Qk1kkJWo=;
 b=t7bsrl8lzNQ4zMSthvIxTmxWDNxxxJNJrD0ZRehVDRpe0PTadNGf2Hz3U/o6CVjLvr
 oOx8KBw9KwFQisxq78EQ5v+zJ0sQcZlCEiJOJzSeI7Z8/uBI3gRSTW69OIiieGwKkqvR
 6reUHKPQaG9ELCxR5WOyka/fUUZR9K3r3hIXb6V8AngLRvoTfaWdyVG1CIszBIdydMgp
 YKq/1tw5ZGQcnJmPb2AZV12SRYJdqCsp895sOCfQVGrKWoFKIBJHEJwymjdWy5+0rIK2
 FMCIVPIbR8xtaKbNDdDoC17HU091HYbR1X+JSBL8xZoCnthdQmFOCQwRIlBLc+IVEMWp
 YJHg==
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;
 bh=5aV9TG0f+TZvgV8yP1wvsex3b7MkVpKqFo+Qk1kkJWo=;
 b=QSiKcCwlJ4PzeMhFuUCftcWUWi8UNxfuBJYw6xRwNc19bHGMt8Fbm9Fb++bTE6Ngh7
 Q1xRtWFaL9pfW/DQ6Ss3Ta43xg9holJ+JMA6TksugvM1DoysPKtGVECK7HgTfjT80LCQ
 66xFM4kamalqoeRmI/rMU0Zn4YJOludKwr/fJr0gRgIdQ6gpg9oMQhlo+v45PuhffUqd
 kRALPqoXIUWMCmxHtYwqbNvLaPpZY2YQi2X0Y3+bdLpxvOYlVc+l9HO5ckAUbCtUNHxQ
 fOkA0Kh56Wgcn0hvdAj0MpkdrQ7jvlPnWO6n1pD+219rUziaz62nhx1UfZCGV3pB4rpO
 m94Q==
X-Gm-Message-State: AOAM533ELJDISsuq1c33xhfO53Gt8XO613IdYKtbWTsyXYX5juENX+pU
 G2uXcU4cHDCcAtK74q3l384JyQC9vOT2JgSiC1tvcFXxqcU=
X-Google-Smtp-Source: ABdhPJzIJR/n0gGEBe+/B10iS+mqvjcBDAeKzG6TMavdXH8VRXQn/f0Aq+yBjLSHTfwpjeRzad4jsYzyQpJTaNJB2mA=
X-Received: by 2002:a02:ccae:: with SMTP id t14mr1798159jap.63.1600726736863; 
 Mon, 21 Sep 2020 15:18:56 -0700 (PDT)
MIME-Version: 1.0
References: <CAJvkSseOx8mwYowLEnfKVEUuM5xsiYkbLdAvtaYxPpu4jY9pCg@mail.gmail.com>
In-Reply-To: <CAJvkSseOx8mwYowLEnfKVEUuM5xsiYkbLdAvtaYxPpu4jY9pCg@mail.gmail.com>
From: Karl <gmkarl@gmail.com>
Date: Mon, 21 Sep 2020 18:18:44 -0400
Message-ID: <CALL-=e5AZjzndKnueNayWNQTcvSAKA=W5cR1KzKxEoVGDCGJCg@mail.gmail.com>
To: Tom Trevethan <tom@commerceblock.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000088854105afda3c9d"
X-Mailman-Approved-At: Tue, 22 Sep 2020 02:45:53 +0000
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 22:19:03 -0000

--00000000000088854105afda3c9d
Content-Type: text/plain; charset="UTF-8"

Coinswap has been a struggling goal for many years now.  Consider that
bitshares' dexbot just recently lost their funding.

Please make your projects usable before you announce you are working on
them, to keep your work safe from distraction or harm.

On Sun, Sep 13, 2020, 7:11 PM Tom Trevethan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto"><div>Coinswap has been a struggling goal for many years n=
ow.=C2=A0 Consider that bitshares&#39; dexbot just recently lost their fund=
ing.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Please make your pr=
ojects usable before you announce you are working on them, to keep your wor=
k safe from distraction or harm.<br><br><div class=3D"gmail_quote" dir=3D"a=
uto"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Sep 13, 2020, 7:11 PM To=
m Trevethan via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">We are designing an off-ch=
ain coin-swap protocol that will work with the statechain implementation we=
 are developing (<a href=3D"https://github.com/commerceblock/mercury" targe=
t=3D"_blank" rel=3D"noreferrer">https://github.com/commerceblock/mercury</a=
>). The general idea is that coins deposited with a statechain entity (stat=
ecoins) can be transacted peer-to-peer off-chain in a way that the statecha=
in entity (SCE) is trusted, but the statecoins always remain in the custody=
 of the owners. A statecoin swapping service would enable owners to mix the=
ir coins with other users, giving the same privacy benefits of on-chain Coi=
nSwap protocols, but by being off-chain statecoin swaps would be much faste=
r and cheaper. <br><br>The swapping service (conductor) would not have cust=
ody of the statecoins at any point. The aim is to have the conductor coordi=
nate the swap amongst a group of statecoins (i.e. determine the which state=
coin should be sent to which new random owner in the group) without being a=
ble to learn the link between owners and their provided addresses. To do th=
is we will use a blind signature scheme in a similar way to the zerolink pr=
otocol.<br><br>Here is a high-level description of how this blinding can op=
erate - with the aim that the conductor does learn how the ownership of ind=
ividual coins has changed.<br>For example, imagine 4 individuals (A,B,C and=
 D) who own equal value statecoins utxo1, utxo2, utxo3 and utxo4 respective=
ly. They want to swap ownership privately, trusting the conductor/SCE to en=
force atomicity. In other words, the conductor will randomly assign each st=
atecoin to one of the owners (the mix), but will not be able to gain knowle=
dge of that assignment.<br>1. A,B,C and D signal their participation by sig=
ning the swap_token (which has details of the swap) with the proof-key of t=
heir input coin. (A statecoin address is formed of a concatenation of the p=
roof 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), which the=
y blind (encrypt) and sign with the proof key of their input coin: add1, ad=
d2, add3 and add4 and send to the conductor.<br>3. The conductor authentica=
tes each signature and then signs each payload (i.e. the blinded destinatio=
n addresses) with a blinded signature scheme and returns these signatures t=
o A,B,C and D.<br>4. Each of A,B,C and D then reconnects over TOR with a ne=
w identity.<br>5. Each of A,B,C and D then send their unblinded destination=
 address with the conductor signature to the conductor (the conductor now k=
nows that these 4 addresses belong to A,B,C and D, but not which ones map t=
o each input.)<br>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 g=
iven address. <br>7. Each participant then finalises each transfer - if any=
 transfer fails (due to a participant disappearing or acting maliciously) t=
hen all transfers are reverted - here atomicity is guaranteed by the SCE. <=
br><br>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 fa=
il, so that the corresponding statecoins can be penalized (prevented from p=
articipating in further swaps for some timeout) to make any DoS attack cost=
ly. In the case of an on-chain coinjoin, this is easy: whoever didn&#39;t s=
ign 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 sen=
der performs an operation with the SCE (transfer_sender) and then sends an =
encrypted value to the receiver, who then performs the second operation wit=
h the SCE (transfer_reciever) which updates the UTXO private key shares for=
 the new owner (<a href=3D"https://github.com/commerceblock/mercury/blob/ma=
ster/doc/statechains.md" target=3D"_blank" rel=3D"noreferrer">https://githu=
b.com/commerceblock/mercury/blob/master/doc/statechains.md</a> for more det=
ails). If the second stage fails (i.e. the values used for the key update p=
rotocol are wrong) this could be due to either the sender sending a bad/man=
ipulated value to the receiver, or the receiver using bad values in the sec=
ond 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 o=
ne is malicious without revealing the encrypted value sent between the send=
er and receiver (which must be kept secret from the SCE). <br><br>All this =
means that if a multi-party coinswap fails, we will know which statecoin wa=
s involved in the failure, but we cannot determine whether the sender or re=
ceiver of that coin caused the failure. One potential solution to this is t=
o have each sender generate a zero knowledge proof that the encrypted value=
 sent to the receiver is correct/valid (see last section in <a href=3D"http=
s://github.com/commerceblock/mercury/blob/master/doc/swaps.md" target=3D"_b=
lank" rel=3D"noreferrer">https://github.com/commerceblock/mercury/blob/mast=
er/doc/swaps.md</a> for more details) which can be used to assign blame in =
a failure. This proof could be generated and verified using a zkSNARK/zkSTA=
RK framework, but this is not trivial to implement and would likely add sig=
nificant computational burden to user wallets to generate proofs - so we wo=
uld like to avoid this if possible, and we are trying to come up with a sim=
pler solution. <br><br>Any comments on the above are welcome, and happy to =
provide more details if anyone is interested. <br><br>Cheers,<br><br>Tom<br=
></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>

--00000000000088854105afda3c9d--