diff options
author | Ruben Somsen <rsomsen@gmail.com> | 2020-05-12 13:30:38 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2020-05-12 11:30:54 +0000 |
commit | 168a34e454bc3068e03b4dd2459cdb647892460f (patch) | |
tree | 1736fe6f9f19e75ce1a832ee11d051e51a651906 | |
parent | 95073c665922c45041ba2ecec0d145db82ff6eac (diff) | |
download | pi-bitcoindev-168a34e454bc3068e03b4dd2459cdb647892460f.tar.gz pi-bitcoindev-168a34e454bc3068e03b4dd2459cdb647892460f.zip |
Re: [bitcoin-dev] SAS: Succinct Atomic Swap
-rw-r--r-- | 0d/e7917185ed50fb9a8544e008b531b0c29971ae | 188 |
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>>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't particularly seem in either party'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>>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>>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:= + "Access to money is contingent on remembering secrets (backup complex= +ity)"<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 <<a href=3D"mailto:lloyd.fourn@gmail.= +com">lloyd.fourn@gmail.com</a>> 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'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-- + |