summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRuben Somsen <rsomsen@gmail.com>2020-05-12 13:30:38 +0200
committerbitcoindev <bitcoindev@gnusha.org>2020-05-12 11:30:54 +0000
commit168a34e454bc3068e03b4dd2459cdb647892460f (patch)
tree1736fe6f9f19e75ce1a832ee11d051e51a651906
parent95073c665922c45041ba2ecec0d145db82ff6eac (diff)
downloadpi-bitcoindev-168a34e454bc3068e03b4dd2459cdb647892460f.tar.gz
pi-bitcoindev-168a34e454bc3068e03b4dd2459cdb647892460f.zip
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
-rw-r--r--0d/e7917185ed50fb9a8544e008b531b0c29971ae188
1 files changed, 188 insertions, 0 deletions
diff --git a/0d/e7917185ed50fb9a8544e008b531b0c29971ae b/0d/e7917185ed50fb9a8544e008b531b0c29971ae
new file mode 100644
index 000000000..7a3f688b0
--- /dev/null
+++ b/0d/e7917185ed50fb9a8544e008b531b0c29971ae
@@ -0,0 +1,188 @@
+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--
+