Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4841AC016F for ; Tue, 12 May 2020 11:34:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 3548185335 for ; Tue, 12 May 2020 11:34:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hldJomuvfI8q for ; Tue, 12 May 2020 11:34:31 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by whitealder.osuosl.org (Postfix) with ESMTPS id C08EE84AE3 for ; Tue, 12 May 2020 11:34:30 +0000 (UTC) Received: by mail-ed1-f53.google.com with SMTP id r16so10803289edw.5 for ; Tue, 12 May 2020 04:34:30 -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=Ttyzz+3eKcToR7koq25INkoytVyiojXTksIJ2+Kv4zI=; b=gs1wx2Xsi1ImzFXCwJbPPvp3vri4S+zJdk+ge8ZvTmlgw2JiGsdARnKKcbvcSz2317 ZQLA0uRqUuDk8Sc98zI9EzlnPwxwbYtciTrRv3Y+9NJDKP28TuEzO7D0ewQuk3CCwHQ4 I859/4UInXIe82JciNHBO1Lz1fNJxcwbQARZn+Q/mr17QonjZVlTRBwPtZsQQHg7RV5O ebnDD1s3YdJKzeT45oUumsmL0x/3GPj2hpB+SbMWznYgjb6o0ybhZjx+jTTVkWfVlWnp awoga0uC663WbVjK/KDx55/U975mwHpYPwrV9g0L47PTymxgrsC8uUbLwIlHAKZiBMhi Hk0w== 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=Ttyzz+3eKcToR7koq25INkoytVyiojXTksIJ2+Kv4zI=; b=InJKKBJ+CJZB4cwnP2p6QIoB11rhnrsn1c5XrolC4R+LJ/H9jViwSGSBdNQR4bpHtq jAM90f2yX1ri+1mE2VJks7XtQQrnLqCnkThopTRPHDX3/Y6j2OYx32RLOjB4fgLZXNR9 LlHXWz78Xztsio322JKDkgzdj7pyFyiLiXH/WdXVXbpNrvYwvOf591WLDKASPy3Jv1J1 doNCqYrtKH7EQw6NOJQSbxqhIxhmJq5LRdGDHF1T6xfOJLHpCEgFEigvsEd2PaDNqq3v 0GrCWLBoZkCqZ1FW/MDcG+l3fBgo0dZzay6ijZMySvr62+QMS83RTuGObIhLkEZpRQfU yFXQ== X-Gm-Message-State: AGi0PuZGQJDdaAeX00unrp2etCd5dqiGtbQJLfGDzS9tPecjvM75RRZ0 ooY8XqWPuCT06EtXMjjHW4ZQvNofzOTQ2pjuBKnDNPNL X-Google-Smtp-Source: APiQypJMerCkbdVmS1M0in0Qk92AsMXMX3ib3eM5EgNyjRCN+ePrnXSm6vud3F9oinrjaxaO6rnbHvOFYP8TrY12GWg= X-Received: by 2002:a05:6402:120a:: with SMTP id c10mr16355120edw.15.1589283268785; Tue, 12 May 2020 04:34:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ruben Somsen Date: Tue, 12 May 2020 13:34:17 +0200 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000aefa5505a571d83f" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 11:34:32 -0000 --000000000000aefa5505a571d83f Content-Type: text/plain; charset="UTF-8" Hi Lloyd, >In my opinion, this protocol is theoretical breakthrough as well as a practical protocol. Well done! Thanks for the kind praise, and for providing a summary of what you think makes the protocol useful. Your different perspective is undoubtedly useful for others who are trying to understand it. >We might call this a "Forced Refund *TLC" Good description, I like it. >The advantages that Ruben's two tx protocol has over this is that timelocks and monitoring is only needed on one of the chains. Well put, and I agree with your point that the traditional 4 tx protocol can also be turned into 2 tx with an online requirement. One minor thing to add is that this would make the 4 tx protocol more clunky in the non-cooperative case (a 4 tx timeout). In the SAS protocol it comes at no cost. Cheers, Ruben On Tue, May 12, 2020 at 1:30 PM Ruben Somsen wrote: > 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 > 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 >> > --000000000000aefa5505a571d83f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Lloyd,

>In my opinion,= this protocol is theoretical breakthrough as well as a practical protocol.= Well done!

Thanks for the kind praise, and fo= r providing a summary of what you think makes the protocol useful. Your dif= ferent perspective is undoubtedly useful for others who are trying to under= stand it.

>We might call this a "Forced Re= fund *TLC"

Good description, I like it.
=

>The advantages that Ruben's two tx protocol has= over this is that timelocks and monitoring is only needed on one of the ch= ains.=C2=A0=C2=A0=C2=A0

Well put, and I agree = with your point that the traditional 4 tx protocol can also be turned into = 2 tx with an online requirement. One minor thing to add is that this would = make the 4 tx protocol more clunky in the non-cooperative case (a 4 tx time= out). In the SAS protocol it comes at no cost.

Che= ers,
Ruben

On Tue, May 12, 2020 at 1:30 PM Ruben Somsen <= rsomsen@gmail.com> wrote:
Hi Z= mnSCPxj,

>Would this not work?

I considered and rejected t= hat 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 do= esn't particularly seem in either party's interest wait until a mom= ent 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 p= arty can lead to losses for both parties. I have my doubts a gain in privac= y in the uncooperative case is worth that risk.

Of course it also re= verts the protocol to 3 transactions, instead of 2, but regardless, not hav= ing to watch the chain is probably more practical in many cases. As an asid= e, if both chains support timelocks then we can ensure that the more expens= ive chain only receives one transaction.

>if relative locktimes a= re used as often as absolute locktimes for block-sniping-prevention and a d= ecent Scriptless Script system, then all protocol aborts should be doable w= ith no information leaks

I see your point, interesting observation.<= br>
>A sidenote as well, that if Alice typically uses an HD wallet, t= he 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 mone= y is contingent on remembering secrets (backup complexity)"

Cheers,
Ruben


On Tue, May 12, 2020 at 8:50 AM L= loyd Fournier <lloyd.fourn@gmail.com> wrote:
A quick correction= to my post:

H= ere's where the truly novel part comes in. Ruben solves this by extendi= ng the standard *TLC contract:
1. Bob redeem with secret
2. Alice refund after T1
3. Bob redeem without secret after T2<= /div>

This is actually:

1. Bob redeem with redeem secret
2. Alice refun= d after T1 with refund secret
3. Bob redeem without secret after = T2

The fact that Alice reveals a secret when she r= efunds is crucial.

LL=C2=A0
--000000000000aefa5505a571d83f--