path: root/b0/6d4d7e4effb4d7cf9508aff79f7e983f4ab2d8

Return-Path: <rsomsen@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4841AC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 11:34:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 3548185335
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 11:34:32 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id hldJomuvfI8q
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 11:34:31 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com
 [209.85.208.53])
 by whitealder.osuosl.org (Postfix) with ESMTPS id C08EE84AE3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 11:34:30 +0000 (UTC)
Received: by mail-ed1-f53.google.com with SMTP id r16so10803289edw.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 04:34:30 -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=Ttyzz+3eKcToR7koq25INkoytVyiojXTksIJ2+Kv4zI=;
 b=gs1wx2Xsi1ImzFXCwJbPPvp3vri4S+zJdk+ge8ZvTmlgw2JiGsdARnKKcbvcSz2317
 ZQLA0uRqUuDk8Sc98zI9EzlnPwxwbYtciTrRv3Y+9NJDKP28TuEzO7D0ewQuk3CCwHQ4
 I859/4UInXIe82JciNHBO1Lz1fNJxcwbQARZn+Q/mr17QonjZVlTRBwPtZsQQHg7RV5O
 ebnDD1s3YdJKzeT45oUumsmL0x/3GPj2hpB+SbMWznYgjb6o0ybhZjx+jTTVkWfVlWnp
 awoga0uC663WbVjK/KDx55/U975mwHpYPwrV9g0L47PTymxgrsC8uUbLwIlHAKZiBMhi
 Hk0w==
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=Ttyzz+3eKcToR7koq25INkoytVyiojXTksIJ2+Kv4zI=;
 b=InJKKBJ+CJZB4cwnP2p6QIoB11rhnrsn1c5XrolC4R+LJ/H9jViwSGSBdNQR4bpHtq
 jAM90f2yX1ri+1mE2VJks7XtQQrnLqCnkThopTRPHDX3/Y6j2OYx32RLOjB4fgLZXNR9
 LlHXWz78Xztsio322JKDkgzdj7pyFyiLiXH/WdXVXbpNrvYwvOf591WLDKASPy3Jv1J1
 doNCqYrtKH7EQw6NOJQSbxqhIxhmJq5LRdGDHF1T6xfOJLHpCEgFEigvsEd2PaDNqq3v
 0GrCWLBoZkCqZ1FW/MDcG+l3fBgo0dZzay6ijZMySvr62+QMS83RTuGObIhLkEZpRQfU
 yFXQ==
X-Gm-Message-State: AGi0PuZGQJDdaAeX00unrp2etCd5dqiGtbQJLfGDzS9tPecjvM75RRZ0
 ooY8XqWPuCT06EtXMjjHW4ZQvNofzOTQ2pjuBKnDNPNL
X-Google-Smtp-Source: APiQypJMerCkbdVmS1M0in0Qk92AsMXMX3ib3eM5EgNyjRCN+ePrnXSm6vud3F9oinrjaxaO6rnbHvOFYP8TrY12GWg=
X-Received: by 2002:a05:6402:120a:: with SMTP id
 c10mr16355120edw.15.1589283268785; 
 Tue, 12 May 2020 04:34:28 -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>
In-Reply-To: <CAPv7TjYqC73zRQq2yQy9RpeHUUexjSS23uU9VwJvvoRr50p2vA@mail.gmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Tue, 12 May 2020 13:34:17 +0200
Message-ID: <CAPv7TjaJk5gsyZsZBfbKmjDF5-ijqcONEMtkowb1Y=2D38vRow@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000aefa5505a571d83f"
X-Mailman-Approved-At: Tue, 12 May 2020 11:35:10 +0000
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 11:34:32 -0000

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

Hi Lloyd,

>In my opinion, this protocol is theoretical breakthrough as well as a
practical protocol. Well done!

Thanks for the kind praise, and for providing a summary of what you think
makes the protocol useful. Your different perspective is undoubtedly useful
for others who are trying to understand it.

>We might call this a "Forced Refund *TLC"

Good description, I like it.

>The advantages that Ruben's two tx protocol has over this is that
timelocks and monitoring is only needed on one of the chains.

Well put, and I agree with your point that the traditional 4 tx protocol
can also be turned into 2 tx with an online requirement. One minor thing to
add is that this would make the 4 tx protocol more clunky in the
non-cooperative case (a 4 tx timeout). In the SAS protocol it comes at no
cost.

Cheers,
Ruben

On Tue, May 12, 2020 at 1:30 PM Ruben Somsen <rsomsen@gmail.com> wrote:

> Hi ZmnSCPxj,
>
> >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 relative locktimes are used as often as absolute locktimes for
> block-sniping-prevention and a decent Scriptless Script system, then all
> protocol aborts should be doable with no information leaks
>
> I see your point, interesting observation.
>
> >A sidenote as well, that if Alice typically uses an HD wallet, the UTXO
> on the LTC side would not be in that HD, and if Alice wants to cold-store
> the LTC, it should move the money as well into an HD pubkey.
>
> Agreed, I had that listed as one of the disadvantages: "Access to money is
> contingent on remembering secrets (backup complexity)"
>
> Cheers,
> Ruben
>
>
> On Tue, May 12, 2020 at 8:50 AM Lloyd Fournier <lloyd.fourn@gmail.com>
> wrote:
>
>> A quick correction to my post:
>>
>>>
>>> Here's where the truly novel part comes in. Ruben solves this by
>>> extending the standard *TLC contract:
>>> 1. Bob redeem with secret
>>> 2. Alice refund after T1
>>> 3. Bob redeem without secret after T2
>>>
>>> This is actually:
>>
>> 1. Bob redeem with redeem secret
>> 2. Alice refund after T1 with refund secret
>> 3. Bob redeem without secret after T2
>>
>> The fact that Alice reveals a secret when she refunds is crucial.
>>
>> LL
>>
>

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

<div dir=3D"ltr"><div>Hi Lloyd,</div><div><br></div><div>&gt;In my opinion,=
 this protocol is theoretical breakthrough as well as a practical protocol.=
 Well done!<br></div><div><br></div><div>Thanks for the kind praise, and fo=
r providing a summary of what you think makes the protocol useful. Your dif=
ferent perspective is undoubtedly useful for others who are trying to under=
stand it.</div><div><br></div><div>&gt;We might call this a &quot;Forced Re=
fund *TLC&quot;</div><div><br></div><div>Good description, I like it.</div>=
<div><br></div><div>&gt;The advantages that Ruben&#39;s two tx protocol has=
 over this is that timelocks and monitoring is only needed on one of the ch=
ains.=C2=A0=C2=A0=C2=A0<br></div><div><br></div><div>Well put, and I agree =
with your point that the traditional 4 tx protocol can also be turned into =
2 tx with an online requirement. One minor thing to add is that this would =
make the 4 tx protocol more clunky in the non-cooperative case (a 4 tx time=
out). In the SAS protocol it comes at no cost.</div><div><br></div><div>Che=
ers,</div><div>Ruben</div></div><br><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">On Tue, May 12, 2020 at 1:30 PM Ruben Somsen &lt;=
<a href=3D"mailto:rsomsen@gmail.com">rsomsen@gmail.com</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Z=
mnSCPxj,<br><br>&gt;Would this not work?<br><br>I considered and rejected t=
hat 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 do=
esn&#39;t particularly seem in either party&#39;s interest wait until a mom=
ent 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 p=
arty can lead to losses for both parties. I have my doubts a gain in privac=
y in the uncooperative case is worth that risk.<br><br>Of course it also re=
verts the protocol to 3 transactions, instead of 2, but regardless, not hav=
ing to watch the chain is probably more practical in many cases. As an asid=
e, if both chains support timelocks then we can ensure that the more expens=
ive chain only receives one transaction.<br><br>&gt;if relative locktimes a=
re used as often as absolute locktimes for block-sniping-prevention and a d=
ecent Scriptless Script system, then all protocol aborts should be doable w=
ith no information leaks<br><br>I see your point, interesting observation.<=
br><br>&gt;A sidenote as well, that if Alice typically uses an HD wallet, t=
he UTXO on the LTC side would not be in that HD, and if Alice wants to cold=
-store the LTC, it should move the money as well into an HD pubkey.<br><br>=
Agreed, I had that listed as one of the disadvantages: &quot;Access to mone=
y is contingent on remembering secrets (backup complexity)&quot;<div><br></=
div><div>Cheers,</div><div>Ruben</div></div><br><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 12, 2020 at 8:50 AM L=
loyd Fournier &lt;<a href=3D"mailto:lloyd.fourn@gmail.com" target=3D"_blank=
">lloyd.fourn@gmail.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-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">A quick correction=
 to my post:</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><div>H=
ere&#39;s where the truly novel part comes in. Ruben solves this by extendi=
ng the standard *TLC contract:</div><div>1. Bob redeem with secret</div><di=
v>2. Alice refund after T1</div><div>3. Bob redeem without secret after T2<=
/div><div><br></div></div></div></blockquote><div>This is actually:</div><d=
iv><br></div><div>1. Bob redeem with redeem secret</div><div>2. Alice refun=
d after T1 with refund secret</div><div>3. Bob redeem without secret after =
T2</div><div><br></div><div>The fact that Alice reveals a secret when she r=
efunds is crucial.</div><div><br></div><div>LL=C2=A0</div></div></div>
</blockquote></div>
</blockquote></div>

--000000000000aefa5505a571d83f--