path: root/0d/e7917185ed50fb9a8544e008b531b0c29971ae

Return-Path: <rsomsen@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2F7AAC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 11:30:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 14F6326016
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 11:30:54 +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 IEOLdEz3xxWv
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 11:30:52 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com
 [209.85.208.48])
 by silver.osuosl.org (Postfix) with ESMTPS id 63E9125D07
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 11:30:52 +0000 (UTC)
Received: by mail-ed1-f48.google.com with SMTP id b91so6578347edf.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 04:30:52 -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=TQt5MCyMJhZ2bPK3CkF4iRw0AnPbfF+mEpQ2pl26Fwo=;
 b=OpcrbsmqFV7bIWnDDx7TVO7iy04xtcxVAeqZIJU+9XYOB5drqdshlzxy5stzpA5hCI
 A3dgFLXp6PYvYZhitPrs9AodVpfhf1WawaNp224jm6uObcQNgf9tbyTomfPWTMnjNa8j
 98J/x2Q/KN40X1g64XFWM/5Vb7drUnxDS2aQ3yE9g1ahPEgOAEkRfZbYOdZZfxgCcIng
 /EER5U6b5xIQwoChpisPljZTLsoyU8BXKBHPaXyC3Ggl78PO6Kan97VPs1MNjkADxoTO
 KzCnSHbyY6Wp6CEtD52/hMoqY1Ev+X9eP5vw3+czUefYuQ6ql0jqlureL8mwuN+gcdpL
 o5bA==
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=TQt5MCyMJhZ2bPK3CkF4iRw0AnPbfF+mEpQ2pl26Fwo=;
 b=XCJbafzeoKmKWC4fy2IBQX1DidE/sxLLPYd6EmAzht41jy0HCqHLNewShKvxbhZIzh
 l4pR+AI0lsJVljFy84wpEYxg4r57HRGiGMVteNvtTDOC42Y1ly20cjwu5Uv66GB9lxLz
 vi1OWX9SM8zwy5+obXYBvPshfSvgYrIIS9IAcltNWJaILQb/UKtfn/oyOQpNIm5aBOzf
 HI5hKeNI925ccDWQIk1bBw5VQVSCkPSYGVeYyF8FJ1HEmozb5DN39p6JvSQU+tCEB0Qn
 +S8LLM9XMPEbAgg0DjifnCLVhjzcxdNQRu/logAU8KlSvPQP9FF9sTqtXFOd8kDFKewY
 dVrQ==
X-Gm-Message-State: AGi0Pubn1+0eiS1neXs/wcEUlMdqwBF87TOryTpIkYO0s0qbVkIg6EUW
 /wjpoVM9APUEqJaL5YamZGhAgfDXKslsuRxxI+TJzxMw
X-Google-Smtp-Source: APiQypI4GQXdprOzL+TiXg5mw6mbA5i7sZ53gf5SShBX0VjkmbCbd1kVpjjZoRlv2Tx3q+UXGJSS80G9EJvwbiIg1x8=
X-Received: by 2002:aa7:c499:: with SMTP id m25mr16741740edq.122.1589283050133; 
 Tue, 12 May 2020 04:30:50 -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>
In-Reply-To: <CAH5Bsr1paP8dmo_z6VoEHYvB_SpD4Piw91LeLJBMgFph7Qrtfg@mail.gmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Tue, 12 May 2020 13:30:38 +0200
Message-ID: <CAPv7TjYqC73zRQq2yQy9RpeHUUexjSS23uU9VwJvvoRr50p2vA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a69cb105a571cbf8"
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:30:54 -0000

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

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
>

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

<div dir=3D"ltr">Hi ZmnSCPxj,<br><br>&gt;Would this not work?<br><br>I cons=
idered 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 acceptab=
le to me. The revoke transaction was specifically added to mitigate that is=
sue (invalidating any attempt of Bob to claim the coins and reveal his secr=
et). That said, it doesn&#39;t particularly seem in either party&#39;s inte=
rest wait until a moment where two timelocks become valid, so maybe it is n=
ot 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 do=
ubts a gain in privacy in the uncooperative case is worth that risk.<br><br=
>Of course it also reverts the protocol to 3 transactions, instead of 2, bu=
t regardless, not having to watch the chain is probably more practical in m=
any cases. As an aside, if both chains support timelocks then we can ensure=
 that the more expensive chain only receives one transaction.<br><br>&gt;if=
 relative locktimes are used as often as absolute locktimes for block-snipi=
ng-prevention and a decent Scriptless Script system, then all protocol abor=
ts should be doable with no information leaks<br><br>I see your point, inte=
resting observation.<br><br>&gt;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 i=
f 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 money is contingent on remembering secrets (backup complex=
ity)&quot;<div><br></div><div>Cheers,</div><div>Ruben</div></div><br><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May =
12, 2020 at 8:50 AM Lloyd Fournier &lt;<a href=3D"mailto:lloyd.fourn@gmail.=
com">lloyd.fourn@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">A quick correct=
ion to my post:</div><div class=3D"gmail_quote"><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"><div><br></div><di=
v>Here&#39;s where the truly novel part comes in. Ruben solves this by exte=
nding the standard *TLC contract:</div><div>1. Bob redeem with secret</div>=
<div>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=
><div><br></div><div>1. Bob redeem with redeem secret</div><div>2. Alice re=
fund after T1 with refund secret</div><div>3. Bob redeem without secret aft=
er T2</div><div><br></div><div>The fact that Alice reveals a secret when sh=
e refunds is crucial.</div><div><br></div><div>LL=C2=A0</div></div></div>
</blockquote></div>

--000000000000a69cb105a571cbf8--