Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 61777C016F for ; Thu, 14 May 2020 05:31:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 25D26221B5 for ; Thu, 14 May 2020 05:31:30 +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 g0Wht8ZjuM8H for ; Thu, 14 May 2020 05:31:28 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by silver.osuosl.org (Postfix) with ESMTPS id 570EF20467 for ; Thu, 14 May 2020 05:31:28 +0000 (UTC) Received: by mail-ed1-f54.google.com with SMTP id g9so1336405edr.8 for ; Wed, 13 May 2020 22:31:28 -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=Eema8aaBs70VBa3ijyD9CG/XMQzE6vONIx3B4TiHlS0=; b=NCZafi68yXwQRUSD5PteoYN7sUMC6WD9hVr1gkw9Mz3Dbvqrnn3xbhwfyHEs5IYfnt 2mclbyy3xZyRMJyImeQOjHYmCzihpLCIVFDTJCUst3W5YiHmBf2Za6esC9L/a6NfGMRw eTIFh8+d1nJQshOPZ7T7PvnXAcWnrKf8Ltsx9NMrI1Ehz+AhSM9XyaNW3Hcs5ejwd8// mfoDQkj0kN1ZZG8b5PE3yUzRQUITYKlJPzBCv/pAzVwUlCfeKbes96mkC1NHfnyPiwWi FvA6ZqY5LaZzvZq3er0ZVKE1wigvwTD84iTLg4N7EDbedD+rPINrFKZU38e5P2s00I6b 5xPw== 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=Eema8aaBs70VBa3ijyD9CG/XMQzE6vONIx3B4TiHlS0=; b=copAWppxaLxwpiKR1EVHbznXthoBd01UBzM/KLXqg/cEILDihNAjkB3x5OXOElR0tn 4FWRRnBHE6xRPdeQbUikIp09eZjBc3IWDchHJnDdYURxtfRjj9UkT+Ong9USDbbNYFrB Ayz9Dmr+wSJLuF1yfQGan3qWraSv/05Re4/VDJdkgxVkCSlefJx9RdTr9Lo53q+fbuX3 UhIU1Mwe2c4pCoWjJ/jQv8V4zV5FW9FJaHTmX17pqgXYeT1DQtg2bX51kmZNiOVbrCcc JTTaSGfVTq4qwnTRq1HA0HyTSlzp5UsTaOIzqiK1v4QEkviMSs2FmmiO5fsWow86uewM E8Aw== X-Gm-Message-State: AOAM532knfSI9J/6BpAAYcgm/b/gKGEcJeGFamkIrE2nz/tzanxK1i4i DVks9LiLVjOjzQPreOx8tSWiurS4zqTsgLzWDig= X-Google-Smtp-Source: ABdhPJwRJr+/F3MDGzEvjHbYEs4L7RNFpF1IoxBt+u1Z6eziEeXNy4i7v9ovV7TnpOya45VPErqkReWxGmel8k216TM= X-Received: by 2002:a05:6402:30b4:: with SMTP id df20mr2488234edb.158.1589434286726; Wed, 13 May 2020 22:31:26 -0700 (PDT) MIME-Version: 1.0 References: <20200513220222.24953c0a@simplexum.com> <20200514095215.4ea20666@simplexum.com> In-Reply-To: <20200514095215.4ea20666@simplexum.com> From: Ruben Somsen Date: Thu, 14 May 2020 07:31:13 +0200 Message-ID: To: Dmitry Petukhov Content-Type: multipart/alternative; boundary="0000000000000ddfd505a59502db" X-Mailman-Approved-At: Thu, 14 May 2020 05:32:11 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] TLA+ specification for Succint 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: Thu, 14 May 2020 05:31:30 -0000 --0000000000000ddfd505a59502db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dmitry, >While refund_tx_1 is in the mempool, Bob gives success_tx to the friendly miner I see, so you're talking about prior to protocol completion, right after Alice sends Bob the success_tx. The reason this is not an issue is because Alice and Bob both had to misbehave in order for this to happen. Bob is misbehaving here because he should have published the success_tx before refund_tx_1 became valid, and Alice is misbehaving here because she should have sent the revoke_tx (which invalidates the success_tx) followed by refund_tx_2 (revealing her secret only AFTER Bob can no longer claim the BTC). In other words: yes, the protocol can fail if Alice and Bob together work towards that goal. A feature, not a bug. This won't happen if either of them doesn't want it to. I imagine this is difficult to model. >As I understand, this is a way to deny Alice to use refund_tx_1. That is correct, and it also denies refund_tx_2 by making the revoke_tx directly spendable by Bob. >could Bob just spend the Alice&Bob output of the very first, "commitment" transaction that locks BTC Yes, he can. This is what makes it possible to complete the protocol in merely two transactions. >Bob will receive BTC, and the LTC can be locked forever, but Bob doesn't care, he got his BTC. No, because diagram step 5 comes before step 6 -- Alice won't give her key until she learns secretBob. I hope this clarifies it! Cheers, Ruben On Thu, May 14, 2020 at 6:49 AM Dmitry Petukhov wrote: > =D0=92 Wed, 13 May 2020 21:03:17 +0200 > Ruben Somsen wrote: > > > Or perhaps you're referring to the issue ZmnSCPxj pointed out after > > that, where refund transaction #1 and the success transaction could > > both become valid at the same time. It would make sense for the test > > to pick up on that, but I believe that is ultimately also not an > > issue (see my last reply in the thread). > > This one. > > The issue as I see it: Bob can not broadcast success_tx and wait until > Alice has broadcasted refund_tx_1. While refund_tx_1 is in the mempool, > Bob gives success_tx to the friendly miner to have a chance to > invalidate success_tx. Bob already learned secretAlice, so he grabs > his LTC back. If the Bob-friendly miner has luck, success_tx is > confirmed while refund_tx_1 is invalidated, and Bob now have both LTC > and BTC, while Alice is out of her BTC. > > > >I did not understand what the destination of Alice&Bob cooperative > > >spend > > of refund_tx#1 will be > > > > This transaction can be spent by Alice & Bob right away or by Alice a > > day later (in relative time, so the tx has to confirm first). The > > Alice & Bob condition is there purely to ensure that Bob can spend > > the money before Alice once he receives her key at the end of the > > protocol. > > Ah, so this is possible because of the step 5 in the diagram: ``Alice > gives Bob her key ("Alice")'' -- As I understand, this is a way to deny > Alice to use refund_tx_1. > > Then if Alice gives her _key_ to Bob before Bob has to share secretBob > via success_tx, could Bob just spend the Alice&Bob output of the > very first, "commitment" transaction that locks BTC ? Bob will receive > BTC, and the LTC can be locked forever, but Bob doesn't care, he got > his BTC. > --0000000000000ddfd505a59502db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dmitry,

>While refund_tx_1 is in = the mempool, Bob gives success_tx to the friendly miner

I see, so you're talking about prior to protocol completion, righ= t after Alice sends Bob the success_tx. The reason this is not an issue is = because Alice and Bob both had to misbehave in order for this to happen. Bo= b is misbehaving here because he should have published the success_tx befor= e refund_tx_1 became valid, and Alice is misbehaving here because she shoul= d have sent the revoke_tx (which invalidates the success_tx) followed by re= fund_tx_2 (revealing her secret only AFTER Bob can no longer claim the BTC)= . In other words: yes, the protocol can fail if Alice and Bob together work= towards that goal. A feature, not a bug. This won't happen if either o= f them doesn't want it to. I imagine this is difficult to model.
<= div>
>As I understand, this is a way to deny Alice to use = refund_tx_1.

That is correct, and it also deni= es refund_tx_2 by making the revoke_tx directly spendable by Bob.

>could Bob just spend the Alice&Bob output of the ve= ry first, "commitment" transaction that locks BTC

<= /div>
Yes, he can. This is what makes it possible to complete the proto= col in merely two transactions.

>Bob will recei= ve BTC, and the LTC can be locked forever, but Bob doesn't care, he got= his BTC.

No, because diagram step 5 comes before = step 6 -- Alice won't give her key until she learns secretBob.

I hope this clarifies it!

Cheers,=
Ruben

On Thu, May 14, 2020 at 6:49 AM Dmitry Petukhov <<= a href=3D"mailto:dp@simplexum.com">dp@simplexum.com> wrote:
=D0=92 Wed, 13 May 2020 = 21:03:17 +0200
Ruben Somsen <rso= msen@gmail.com> wrote:

> Or perhaps you're referring to the issue ZmnSCPxj pointed out afte= r
> that, where refund transaction #1 and the success transaction could > both become valid at the same time. It would make sense for the test > to pick up on that, but I believe that is ultimately also not an
> issue (see my last reply in the thread).

This one.

The issue as I see it: Bob can not broadcast success_tx and wait until
Alice has broadcasted refund_tx_1. While refund_tx_1 is in the mempool,
Bob gives success_tx to the friendly miner to have a chance to
invalidate success_tx. Bob already learned secretAlice, so he grabs
his LTC back. If the Bob-friendly miner has luck, success_tx is
confirmed while refund_tx_1 is invalidated, and Bob now have both LTC
and BTC, while Alice is out of her BTC.

> >I did not understand what the destination of Alice&Bob coopera= tive
> >spend=C2=A0
> of refund_tx#1 will be
>
> This transaction can be spent by Alice & Bob right away or by Alic= e a
> day later (in relative time, so the tx has to confirm first). The
> Alice & Bob condition is there purely to ensure that Bob can spend=
> the money before Alice once he receives her key at the end of the
> protocol.

Ah, so this is possible because of the step 5 in the diagram: ``Alice
gives Bob her key ("Alice")'' -- As I understand, this is= a way to deny
Alice to use refund_tx_1.

Then if Alice gives her _key_ to Bob before Bob has to share secretBob
via success_tx, could Bob just spend the Alice&Bob output of the
very first, "commitment" transaction that locks BTC ? Bob will re= ceive
BTC, and the LTC can be locked forever, but Bob doesn't care, he got his BTC.
--0000000000000ddfd505a59502db--