From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2F3FFC016F for ; 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 ; 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 ; 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 ; Tue, 12 May 2020 06:11:14 +0000 (UTC) Received: by mail-io1-f50.google.com with SMTP id f4so6192126iov.11 for ; 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: In-Reply-To: From: Lloyd Fournier Date: Tue, 12 May 2020 14:10:47 +0800 Message-ID: To: Ruben Somsen , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Ruben,

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:

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]).
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).

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)=C2=A0 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 whe= re the truly novel part comes in. Ruben solves this by extending the standa= rd *TLC contract:
1. Bob redeem with secret
2. Alice re= fund 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 revelati= on through punishment. If Alice refuses to refund Bob gets the asset he wan= ted anyway!

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 "perfect" 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.

I don't want to ignore that Ruben presents us with a t= wo transaction protocol. He made a nice video explaining it here: https://www.youtube.com/= watch?v=3DTlCxpdNScCA. 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:
1. Alice and Bob set up payment channels = to each other on different chains
2. They atomic swap the balance= s of the channels off-chain using HTLCs using the standard protocol.
<= 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
4. Both parties now watch the chain to see if the other= tries to post a commitment transactions.

The adva= ntages 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 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.


LL --000000000000a5f1ea05a56d54ed--