path: root/ad/001f315e19eea6e691b6579ecf4200e052e9ea

Return-Path: <lloyd.fourn@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2F3FFC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 06:11:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 234482C8FA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 06:11:17 +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 jEWmOxwk4iEd
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 06:11:14 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f50.google.com (mail-io1-f50.google.com
 [209.85.166.50])
 by silver.osuosl.org (Postfix) with ESMTPS id A424F2C803
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 May 2020 06:11:14 +0000 (UTC)
Received: by mail-io1-f50.google.com with SMTP id f4so6192126iov.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 May 2020 23:11:14 -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;
 bh=MAH6/P3hNxQ6BCfiS6PUSVEM2Wu7wqhsfvY1xg/OPAo=;
 b=JDEC7zzIqScNRmG0XXRVP2xpmIR6WCDyAX5QJSbsHE9FY2VGKILlFw1gR6t4+HN3OU
 euYKG1g9kTO2zEYOluk9OOabJkPIVGbl8ITThUE8khCJ0OSy/xe8Ye/QjZkUPiABpjZE
 EZxhRUgfm3iskiczPPgs3l7g2h2J4EXhlHvr0NltWhrYRcGjPaH2LZ7/EqI3+oBDo6Hs
 ZwkVtR+5Ct0qyGSQECTpILwaW+A+RrE4F/7z5idn7X5QAMpTri6/I9fd20+kUiYlydwJ
 diQRg4ua6r06756YS9yi26BfBZlHXewARDjOavbEbSK5hAuudLxebg5kGjHGQR0bXIA3
 jxbA==
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;
 bh=MAH6/P3hNxQ6BCfiS6PUSVEM2Wu7wqhsfvY1xg/OPAo=;
 b=V1xYWOJXtpfkydWcsqV/ntuK7CU2ylwkTDN0Jza5Ab8gyjXFBQehfT2BMfXgpCkqFH
 c6sLD5g0fh19ItEBjpGAZUhxD74xZ/E4w7VFfzkzchIhgRDzrHEQ5nLkWpG7wouFeq6M
 vnNC9+aCpK5GwPzjAIBUDJsQga7Mve55/Rc94o1VM4fMeu/nlXy51aiKxepRPqyJXkyO
 jqgNyjQOt0iDQAX7Zyj6O1iRt+AqdCMOJbnxsSVtD0+ble7j7AaHcRrxzrPd6j9Ekbqr
 j3RxmbnK6hhPNrBuFCNFpPjToiL/9l8fjplij0W50RqfjjQz84qfg7zSEOu2WZ+0VS3t
 IQXw==
X-Gm-Message-State: AGi0PubNpjbXGEQgRc5qYDoEH5ZIXQjcFNl0wMZNWLLhol1kShXxb3UW
 JC2/I6un3CJg33sML+YPGMl+roCx7vBVMuYj58U=
X-Google-Smtp-Source: APiQypL4drKqYH/NK/U2Ge1ETkXs4c/cLOEm2zygpx3Vo5mj/AKX3mJYRXzrUpq9fqYkiEZK71BIi9C6Ast1i0uZ8cw=
X-Received: by 2002:a02:2704:: with SMTP id g4mr18497975jaa.77.1589263873731; 
 Mon, 11 May 2020 23:11:13 -0700 (PDT)
MIME-Version: 1.0
References: <CAPv7TjZGBbf6f1y49HLFD2eNiP5d4e+=dFGqiMFs6jaeYyH-NQ@mail.gmail.com>
In-Reply-To: <CAPv7TjZGBbf6f1y49HLFD2eNiP5d4e+=dFGqiMFs6jaeYyH-NQ@mail.gmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Tue, 12 May 2020 14:10:47 +0800
Message-ID: <CAH5Bsr1d57pzmNgakt=Q2M+Ey+PL9jUVUPeJ_aFj0L0TBAHzKw@mail.gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a5f1ea05a56d54ed"
X-Mailman-Approved-At: Tue, 12 May 2020 06:17:44 +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 06:11:17 -0000

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

Ruben,

In my opinion, this protocol is theoretical breakthrough as well as a
practical protocol. Well done! I want to try and distil the core abstract
ideas here as they appear to me. From my view, the protocol is a
combination of two existing ideas and one new one:

1. In atomic swaps you can make the refund transaction on one chain
dependent on the refund on the other using secret revelation. Thus only one
chain needs to have a timelock and the other refund can be conditioned on a
secret that is revealed when that first refund goes through. (This idea is
in the monero atomic swap [1]).
2. Secret revelations can be used to give unconstrained spending power to
one party. With an adaptor signature, rather than reveal a decryption key
for another signature, you can just make the decryption key your signing
key in the multisig so when you reveal it with the adaptor signautre the
other party gains full knowledge of the private key for the output and can
spend it arbitrarily. (this is just folklore and already what happens in
HTLCs -- though it looks like lightning people are about to get rid of the
unconstrained spend I think).

The combination of these two ideas is novel in itself. The problem with
idea (2) is that your unconstrained spending power over an output doesn't
matter much if there is a pre-signed refund transaction spending from it --
you still have to spend it before the refund becomes valid. But if you
bring in idea (1)  this problem goes away!
However, you are left with a new problem: What if the party with the
timelock never refunds? Then the funds are locked forever.

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

We might call this a "Forced Refund *TLC". Alice must claim the refund or
lose her money. This forces the refund secret revelation through
punishment. If Alice refuses to refund Bob gets the asset he wanted anyway!

The resulting protocol you get from applying these ideas is three
transactions. At the end, one party has their funds in a non HD key output
but if they want that they can just transfer it to an HD output in which
case you get four transactions again. Thus I consider this to be a strict
improvement over the four transaction protocol. Furthermore, one of the
chains does not need a timelock. This is remarkable as the four transaction
atomic swap is one of the most basic and most studied protocols. I
considered it to be kind of "perfect" in a way. It just goes to show that
this field is still very new and there are still things to discover in what
we think is the most well trodden ground.

I don't want to ignore that Ruben presents us with a two transaction
protocol. He made a nice video explaining it here:
https://www.youtube.com/watch?v=TlCxpdNScCA. It is harder to see the
elegance of the idea in the two tx protocol because it involves revocation
and relative timelocks etc. Actually, it is straightforward to naively
achieve a two tx atomic swap with payment channels:
1. Alice and Bob set up payment channels to each other on different chains
2. They atomic swap the balances of the channels off-chain using HTLCs
using the standard protocol.
3. Since one party exclusively owns the funds in each channel the party
with no funds simply reveals their key in the funding OP_CHECKMULTISIG to
the other
4. Both parties now watch the chain to see if the other tries to post a
commitment transactions.

The advantages that Ruben's two tx protocol has over this is that timelocks
and monitoring is only needed on one of the chains. This is nothing to
scoff at but for me the three tx protocol is the most elegant expression of
the idea and the two tx protocol is a more optimised version that might
make sense in some circumstances.

[1] https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/README.md

LL

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

<div dir=3D"ltr"><div dir=3D"ltr"><div>Ruben,</div><div><br></div><div dir=
=3D"ltr">In my opinion, this protocol is theoretical breakthrough as well a=
s a practical protocol. Well done! I want to try and distil the core abstra=
ct ideas here as they appear to me. From my view, the protocol is a combina=
tion of two existing ideas and one new one:</div><div><br></div><div>1. In =
atomic swaps you can make the refund transaction on one chain dependent on =
the refund on the other using secret revelation. Thus only one chain needs =
to have a timelock and the other refund can be conditioned on a secret that=
 is revealed when that first refund goes through. (This idea is in the mone=
ro atomic swap [1]).</div><div>2. Secret revelations can be used to give un=
constrained spending power to one party. With an adaptor signature, rather =
than reveal a decryption key for another signature, you can just make the d=
ecryption key your signing key in the multisig so when you reveal it with t=
he adaptor signautre the other party gains full knowledge of the private ke=
y for the output and can spend it arbitrarily. (this is just folklore and a=
lready what happens in HTLCs -- though it looks like lightning people are a=
bout to get rid of the unconstrained spend I think).</div><div><br></div><d=
iv>The combination of these two ideas is novel in itself. The problem with =
idea (2) is that your unconstrained spending power over an output doesn&#39=
;t matter much if there is a pre-signed refund transaction spending from it=
 -- you still have to spend it before the refund becomes valid. But if you =
bring in idea (1)=C2=A0 this problem goes away!</div><div>However, you are =
left with a new problem: What if the party with the timelock never refunds?=
 Then the funds are locked forever.</div><div><br></div><div>Here&#39;s whe=
re the truly novel part comes in. Ruben solves this by extending the standa=
rd *TLC contract:</div><div>1. Bob redeem with secret</div><div>2. Alice re=
fund after T1</div><div>3. Bob redeem without secret after T2</div><div><br=
></div><div>We might call this a &quot;Forced Refund *TLC&quot;. Alice must=
 claim the refund or lose her money. This forces the refund secret revelati=
on through punishment. If Alice refuses to refund Bob gets the asset he wan=
ted anyway!</div><div><br></div><div>The resulting protocol you get from ap=
plying these ideas is three transactions. At the end, one party has their f=
unds in a non HD key output but if they want that they can just transfer it=
 to an HD output in which case you get four transactions again. Thus I cons=
ider this to be a strict improvement over the four transaction protocol. Fu=
rthermore, one of the chains does not need a timelock. This is remarkable a=
s the four transaction atomic swap is one of the most basic and most studie=
d protocols. I considered it to be kind of &quot;perfect&quot; in a way. It=
 just goes to show that this field is still very new and there are still th=
ings to discover in what we think is the most well trodden ground.</div><di=
v><br></div><div>I don&#39;t want to ignore that Ruben presents us with a t=
wo transaction protocol. He made a nice video explaining it here: <a href=
=3D"https://www.youtube.com/watch?v=3DTlCxpdNScCA">https://www.youtube.com/=
watch?v=3DTlCxpdNScCA</a>. It is harder to see the elegance of the idea in =
the two tx protocol because it involves revocation and relative timelocks e=
tc. Actually, it is straightforward to naively achieve a two tx atomic swap=
 with payment channels:</div><div>1. Alice and Bob set up payment channels =
to each other on different chains</div><div>2. They atomic swap the balance=
s of the channels off-chain using HTLCs using the standard protocol.</div><=
div>3. Since one party exclusively owns the funds in each channel the party=
 with no funds simply reveals their key in the funding OP_CHECKMULTISIG to =
the other</div><div>4. Both parties now watch the chain to see if the other=
 tries to post a commitment transactions.</div><div><br></div><div>The adva=
ntages that Ruben&#39;s two tx protocol has over this is that timelocks and=
 monitoring is only needed on one of the chains. This is nothing to scoff a=
t but for me the three tx protocol is the most elegant expression of the id=
ea and the two tx protocol is a more optimised version that might make sens=
e in=C2=A0some circumstances.</div><div><br></div><div>[1]=C2=A0<a href=3D"=
https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/README.md">https:=
//github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/README.md</a></div><div=
><br>LL</div></div></div>

--000000000000a5f1ea05a56d54ed--