path: root/65/dfe36ae419ce9bc1bd404fbba9e323e45cc267

Return-Path: <rsomsen@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4C5D5C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 16:30:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 3B2BD85402
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 16:30:42 +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 yJEqdRGqkLHE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 16:30:41 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f68.google.com (mail-ed1-f68.google.com
 [209.85.208.68])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 9DB39853FD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 16:30:40 +0000 (UTC)
Received: by mail-ed1-f68.google.com with SMTP id w2so11634905edx.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 09:30:40 -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
 :cc; bh=avSMU+MODG4UkHNHGoHGE1oqkBw1LI4CAgBaXgVgSIA=;
 b=pSYT7D44tGDGf2q72oEXcJltrW6PWvr3fVfesQo7P0+xf5hXdE0rEDiJE/eTPDhLfW
 GCidt5ih8Hgurq9QIW/ZTzG9iIYafh6bTPOO28vlo9AboCD01T8e7b4sa0a/BoJ+Fz66
 Fz3/3LmZzw5oP7bcgwmUjt/k7XS3yy6VqjPQAFDc5M+fJf6ZOVv5TuP8+rD7MvqKOFAM
 Qqyvqw6E16pOJsmkOW5axprdjbxXzf3YK9hDjNyBIbtkkHgK1nitAmmbDh7znttI4I21
 IYtL5Yyc3DNnHMzcR0sn6KJIpg0PT8HmybkE+uFYQW51ad0P55CgSzANTsMjDhbnXwLm
 pMWg==
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=avSMU+MODG4UkHNHGoHGE1oqkBw1LI4CAgBaXgVgSIA=;
 b=qRMms/BUHa9ruduTBcRinGM76bVeSySg3KT15BxKSruefFUA0YsMxurIbJpChv8b3d
 sLHOa/QO0vKtq1WOgwZGwDLcPr7okDtmP8zppxDS2YviNf60mrqs7k+h3uBH73CkEBPo
 xnwXc4bRXCIGVKJeoayFb0/bqznvNQXZRNq5+Jmqz4kUP33Rp/m195JVWfPxBrXmaDML
 Hcd8C4d+qnOHgmnSLoFgwGi5szG6QUtcS/l7hjIWHakTVYFefrG5ncgy/Av3A9L1pMHp
 NTqQ1gl4HzN1lP4IEe12Bt2+O7mfPjHuojeDIlVjj93luPXTsHagZEdaxc3YNGRbKYha
 EB0w==
X-Gm-Message-State: AOAM532stHGYvlmSCM3aZsdmbeJ6/p40GSb6f72wlSMwJ1V/bwnlFaze
 mYMgf3+HSk0CHXfTwv+0qbpbaHh78u6LsHTeC198bOvn
X-Google-Smtp-Source: ABdhPJwqCtBo6Nfd8WT+Dp+R9GFXWZCN3m6O5SLaG1410FFM6BRa6EfBq/leFshV294wu2KdWnV8W6w77ZGSrN+XC0Q=
X-Received: by 2002:a05:6402:30b4:: with SMTP id
 df20mr6879993edb.158.1589301038902; 
 Tue, 12 May 2020 09:30:38 -0700 (PDT)
MIME-Version: 1.0
References: <CAPv7TjZGBbf6f1y49HLFD2eNiP5d4e+=dFGqiMFs6jaeYyH-NQ@mail.gmail.com>
 <CAH5Bsr1d57pzmNgakt=Q2M+Ey+PL9jUVUPeJ_aFj0L0TBAHzKw@mail.gmail.com>
 <CAH5Bsr1paP8dmo_z6VoEHYvB_SpD4Piw91LeLJBMgFph7Qrtfg@mail.gmail.com>
 <CAPv7TjYqC73zRQq2yQy9RpeHUUexjSS23uU9VwJvvoRr50p2vA@mail.gmail.com>
 <Mpqd20ZM9-93dIIhe1yS4QEGKmzT-uuBrAn1e4omDbA1YJvXrEmZ3IZeoz90s5AHVLAdYwF0PhxgMZwqDdHxQ0UQw2eEEytngEXSsXeLM14=@protonmail.com>
In-Reply-To: <Mpqd20ZM9-93dIIhe1yS4QEGKmzT-uuBrAn1e4omDbA1YJvXrEmZ3IZeoz90s5AHVLAdYwF0PhxgMZwqDdHxQ0UQw2eEEytngEXSsXeLM14=@protonmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Tue, 12 May 2020 18:30:26 +0200
Message-ID: <CAPv7TjbfuV1YvgTS4pjr_56R_-=spb9DzPwqP1HFCBOZpSOq8Q@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000dd705d05a575fb98"
X-Mailman-Approved-At: Tue, 12 May 2020 16:31:25 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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: Tue, 12 May 2020 16:30:42 -0000

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

Hi ZmnSCPxj,

>If the shortened refund transaction exists (labeled "refund transaction
#1" in the SVG) then the same issue still occurs

Yes, but there is one crucial difference: at that point in the protocol
(Bob has the success transaction and then stops cooperating) Alice and Bob
both had the opportunity not to take that path. Bob could have sent the
success transaction, and Alice could have waited and sent the revoke
transaction. They would essentially be "colluding" to fail.

>Without the refund#1 in your proposal, Bob refusing cooperation after
Alice puts the BTC into lock for 3 days and 2 further onchain transactions

I'm not sure if I correctly understood what you're saying, but it's as
follows:

Refund #1 can only safely be used before the signed success tx is given to
Bob. The cost to Alice at this point if Bob aborts is two on-chain
transactions while Bob hasn't put anything on-chain yet.

Refund #2 needs to be used after Bob receives the signed success tx. The
cost to Alice is now three transactions, but Bob also went-on-chain by this
point, so causing this wasn't costless to Bob and is thus a similar failure
mode.

>my formulation allows any of the result transactions to be CPFP directly
by their beneficiaries

Yes, that is indeed very nice. The way I set it up, insufficient fees can
unfortunately cause delays, but they should not be able to cause losses.

>there is still an onlineness requirement in case Bob does not complete the
protocol

Yes, that is very much the design. Alice needs to be on time with claiming
her refund (and revealing her secret), otherwise Bob takes it.

>I have not seen the 2-tx variant video yet, as I prefer to read than listen

The video is not required, it just restates what is in the write-up. I
personally find it easier to understand concepts from video, but I seem to
be in the minority when I ask other devs about this. But let me reiterate
one part you might be confused about (though you probably mostly get it
already):

The online requirement I was alluding to doesn't expire, and is
specifically how the 2 tx SAS protocol is performed. Bob never broadcasts
the success transaction (unless he prefers not to have to be online, i.e.
the 3 tx SAS protocol) and instead Alice and Bob swap their keys: first Bob
hands over secretAlice, then Alice hands over her key. Now the swap is
complete, but Bob has to remain online to make sure Alice never attempts to
broadcast her refund tx. It doesn't expire either because of the relative
timelocks.

Just take a look at the slide 6m8s into the video:
https://youtu.be/TlCxpdNScCA?t=6m8s

I also agree with your observation that alternatively Bob can just spend
before the timelock expires.

>Regardless, the overall protocol of using 3 clauses in the swap, and
reusing the privkey as the payment secret demanded by the pointlocks, is
still a significant innovation.

I'm glad you like it :)

>In the context of CoinSwap, a proposal is that a CoinSwap server would
provide swapping service to incoming clients.

That is an excellent use case that takes good advantage of the asymmetry of
SAS. I completely agree with your observation that the "Bob" side is
perfect for servers (online and/or spending again soon) and the "Alice"
side is perfect for clients (settled in 1 tx). I similarly hope that this
may pave the way for a practical implementation of Payswap between
merchants and customers!

Cheers,
Ruben

On Tue, May 12, 2020 at 5:06 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Ruben,
>
> > >Would this not work?
> >
> > I considered and rejected that model for the following reason: there are
> moments where both Alice and Bob can claim the BTC. If they both attempt to
> do so, it also reveals both secrets, causing the LTC to also be claimable
> by both parties. This chaotic scenario is a failure mode that did not seem
> acceptable to me. The revoke transaction was specifically added to mitigate
> that issue (invalidating any attempt of Bob to claim the coins and reveal
> his secret). That said, it doesn't particularly seem in either party's
> interest wait until a moment where two timelocks become valid, so maybe it
> is not quite as bad as I thought. However, it still means that the
> incompetence/malevolence of one party can lead to losses for both parties.
> I have my doubts a gain in privacy in the uncooperative case is worth that
> risk.
> >
> > Of course it also reverts the protocol to 3 transactions, instead of 2,
> but regardless, not having to watch the chain is probably more practical in
> many cases. As an aside, if both chains support timelocks then we can
> ensure that the more expensive chain only receives one transaction.
>
> If the shortened refund transaction exists (labeled "refund transaction
> #1" in the SVG) then the same issue still occurs: after 1 day it is
> possible for either success or refund#1 to be broadcasted, leading to
> revelation of both secrets, leading to the same failure mode you described.
>
> Without the refund#1 in your proposal, Bob refusing cooperation after
> Alice puts the BTC into lock for 3 days and 2 further onchain transactions
> (with the refund#2 transaction being relative-locked, meaning it cannot be
> used to CPFP the revoke transaction; my formulation allows any of the
> result transactions to be CPFP directly by their beneficiaries).
>
> It seems to me that there is still an onlineness requirement in case Bob
> does not complete the protocol: once the revoke tx becomes valid an online
> Bob can cheat an offline Alice by broadcasting the revoke tx (which, if my
> understanding of the protocol is correct, the signatures are shared to both
> Alice and Bob).
> So Alice needs to be online starting at 2 days to 3 days in order to
> ensure it reclaims it funds.
>
> I have not seen the 2-tx variant video yet, as I prefer to read than
> listen, but I will also check it if I can find an opportunity.
>
> Regardless, the overall protocol of using 3 clauses in the swap, and
> reusing the privkey as the payment secret demanded by the pointlocks, is
> still a significant innovation.
>
>
>
> In the context of CoinSwap, a proposal is that a CoinSwap server would
> provide swapping service to incoming clients.
> Using my counterproposal, the Bob position can be taken by the server and
> the Alice position taken by the client.
> In this context, the L1 can be made reasonably close in the future and L2
> far in the future, in which case Alice the client can be "weakly offline"
> most of the time until L2, and even in a protocol abort would be able to
> recover its funds.
> If the protocol completes, the server Bob can claim its funds before L1,
> and (with knowledge of Alice[0]) can immediately put it in a new funding tx
> for a new incoming client before L1, which is a fine tradeoff for server
> Bob since presumably Bob is always online.
>
> Regards,
> ZmnSCPxj
>
>
>

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

<div dir=3D"ltr">Hi ZmnSCPxj,<div><br></div><div>&gt;If the shortened refun=
d transaction exists (labeled &quot;refund transaction #1&quot; in the SVG)=
 then the same issue still occurs=C2=A0</div><div><br></div><div>Yes, but t=
here is one crucial difference: at that point in the protocol (Bob has the =
success transaction and then stops cooperating) Alice and Bob both had the =
opportunity not to take that path. Bob could have sent the success transact=
ion, and Alice could have waited and sent the revoke transaction. They woul=
d essentially be &quot;colluding&quot; to fail.</div><div><br></div><div>&g=
t;Without the refund#1 in your proposal, Bob refusing cooperation after Ali=
ce puts the BTC into lock for 3 days and 2 further onchain transactions</di=
v><div><br></div><div>I&#39;m not sure if I correctly understood what you&#=
39;re saying, but it&#39;s as follows:</div><div><br></div><div>Refund #1 c=
an only safely be used before the signed success tx is given to Bob. The co=
st to Alice at this point if Bob aborts is two on-chain transactions while =
Bob hasn&#39;t put anything on-chain yet.</div><div><br></div><div>Refund #=
2 needs to be used after Bob receives the signed success tx. The cost to Al=
ice is now three transactions, but Bob also went-on-chain by this point, so=
 causing this wasn&#39;t costless to Bob and is thus a similar failure mode=
.</div><div><br></div><div>&gt;my formulation allows any of the result tran=
sactions to be CPFP directly by their beneficiaries=C2=A0=C2=A0<br></div><d=
iv><br></div><div>Yes, that is indeed very nice. The way I set it up, insuf=
ficient fees can unfortunately cause delays, but they should not be able to=
 cause losses.</div><div><br></div><div>&gt;there is still an onlineness re=
quirement in case Bob does not complete the protocol</div><div><br></div><d=
iv>Yes, that is very much the design. Alice needs to be on time with claimi=
ng her refund (and revealing her secret), otherwise Bob takes it.</div><div=
><br></div><div>&gt;I have not seen the 2-tx variant video yet, as I prefer=
 to read than listen</div><div><br></div><div>The video is not required, it=
 just restates what is in the write-up. I personally find it easier to unde=
rstand concepts from video, but I seem to be in the minority when I ask oth=
er devs about this. But let me reiterate one part you might be confused abo=
ut (though you probably mostly get it already):<br></div><div><br></div><di=
v>The online requirement I was alluding to doesn&#39;t expire, and is speci=
fically how the 2 tx SAS protocol is performed. Bob never broadcasts the su=
ccess transaction (unless he prefers not to have to be online, i.e. the 3 t=
x SAS protocol) and instead Alice and Bob swap their keys: first Bob hands =
over secretAlice, then Alice hands over her key. Now the swap is complete, =
but Bob has to remain online to make sure Alice never attempts to broadcast=
 her refund tx. It doesn&#39;t expire either because of the relative timelo=
cks.</div><div><br></div><div>Just take a look at the slide 6m8s into the v=
ideo:=C2=A0<a href=3D"https://youtu.be/TlCxpdNScCA?t=3D6m8s">https://youtu.=
be/TlCxpdNScCA?t=3D6m8s</a></div><div><br></div><div>I also agree with your=
 observation that alternatively Bob can just spend before the timelock expi=
res.</div><div><br></div><div>&gt;Regardless, the overall protocol of using=
 3 clauses in the swap, and reusing the privkey as the payment secret deman=
ded by the pointlocks, is still a significant innovation.</div><div><br></d=
iv><div>I&#39;m glad you like it :)=C2=A0</div><div><br></div><div>&gt;In t=
he context of CoinSwap, a proposal is that a CoinSwap server would provide =
swapping service to incoming clients.</div><div><br></div><div>That is an e=
xcellent use case that takes good advantage of the asymmetry of SAS. I comp=
letely agree with your observation that the &quot;Bob&quot; side is perfect=
 for servers (online and/or spending again soon) and the &quot;Alice&quot; =
side is perfect for clients (settled in 1 tx). I similarly hope that this m=
ay pave the way for a practical implementation of Payswap between merchants=
 and customers!<br></div><div><br></div><div>Cheers,</div><div>Ruben</div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Tue, May 12, 2020 at 5:06 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@prot=
onmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">Good morning Ruben,<br>
<br>
&gt; &gt;Would this not work?<br>
&gt;<br>
&gt; I considered and rejected that model for the following reason: there a=
re moments where both Alice and Bob can claim the BTC. If they both attempt=
 to do so, it also reveals both secrets, causing the LTC to also be claimab=
le by both parties. This chaotic scenario is a failure mode that did not se=
em acceptable to me. The revoke transaction was specifically added to mitig=
ate that issue (invalidating any attempt of Bob to claim the coins and reve=
al his secret). That said, it doesn&#39;t particularly seem in either party=
&#39;s interest wait until a moment where two timelocks become valid, so ma=
ybe it is not quite as bad as I thought. However, it still means that the i=
ncompetence/malevolence of one party can lead to losses for both parties. I=
 have my doubts a gain in privacy in the uncooperative case is worth that r=
isk.<br>
&gt;<br>
&gt; Of course it also reverts the protocol to 3 transactions, instead of 2=
, but regardless, not having to watch the chain is probably more practical =
in many cases. As an aside, if both chains support timelocks then we can en=
sure that the more expensive chain only receives one transaction.<br>
<br>
If the shortened refund transaction exists (labeled &quot;refund transactio=
n #1&quot; in the SVG) then the same issue still occurs: after 1 day it is =
possible for either success or refund#1 to be broadcasted, leading to revel=
ation of both secrets, leading to the same failure mode you described.<br>
<br>
Without the refund#1 in your proposal, Bob refusing cooperation after Alice=
 puts the BTC into lock for 3 days and 2 further onchain transactions (with=
 the refund#2 transaction being relative-locked, meaning it cannot be used =
to CPFP the revoke transaction; my formulation allows any of the result tra=
nsactions to be CPFP directly by their beneficiaries).<br>
<br>
It seems to me that there is still an onlineness requirement in case Bob do=
es not complete the protocol: once the revoke tx becomes valid an online Bo=
b can cheat an offline Alice by broadcasting the revoke tx (which, if my un=
derstanding of the protocol is correct, the signatures are shared to both A=
lice and Bob).<br>
So Alice needs to be online starting at 2 days to 3 days in order to ensure=
 it reclaims it funds.<br>
<br>
I have not seen the 2-tx variant video yet, as I prefer to read than listen=
, but I will also check it if I can find an opportunity.<br>
<br>
Regardless, the overall protocol of using 3 clauses in the swap, and reusin=
g the privkey as the payment secret demanded by the pointlocks, is still a =
significant innovation.<br>
<br>
<br>
<br>
In the context of CoinSwap, a proposal is that a CoinSwap server would prov=
ide swapping service to incoming clients.<br>
Using my counterproposal, the Bob position can be taken by the server and t=
he Alice position taken by the client.<br>
In this context, the L1 can be made reasonably close in the future and L2 f=
ar in the future, in which case Alice the client can be &quot;weakly offlin=
e&quot; most of the time until L2, and even in a protocol abort would be ab=
le to recover its funds.<br>
If the protocol completes, the server Bob can claim its funds before L1, an=
d (with knowledge of Alice[0]) can immediately put it in a new funding tx f=
or a new incoming client before L1, which is a fine tradeoff for server Bob=
 since presumably Bob is always online.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
<br>
</blockquote></div>

--000000000000dd705d05a575fb98--