MIME-Version: 1.0
References: <20200513220222.24953c0a@simplexum.com>
 <CAPv7TjbZVYTztQLd2dxjzFajhPTg23iWtapkVBzz+z0q=pH2rw@mail.gmail.com>
 <20200514095215.4ea20666@simplexum.com>
In-Reply-To: <20200514095215.4ea20666@simplexum.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Thu, 14 May 2020 07:31:13 +0200
Message-ID: <CAPv7TjYY+kKHM6qzM9WKU7rB5J=RE_oaaW1XcM1Jr+ap=-pJOg@mail.gmail.com>
To: Dmitry Petukhov <dp@simplexum.com>
Content-Type: multipart/alternative; boundary="0000000000000ddfd505a59502db"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] TLA+ specification for Succint Atomic Swap
Precedence: list

--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 <dp@simplexum.com> wrote:

> =D0=92 Wed, 13 May 2020 21:03:17 +0200
> Ruben Somsen <rsomsen@gmail.com> 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

<div dir=3D"ltr">Hi Dmitry,<div><br></div><div>&gt;While refund_tx_1 is in =
the mempool, Bob gives success_tx to the friendly miner</div><div><br></div=
><div>I see, so you&#39;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&#39;t happen if either o=
f them doesn&#39;t want it to. I imagine this is difficult to model.</div><=
div><br></div><div>&gt;As I understand, this is a way to deny Alice to use =
refund_tx_1.<br></div><div><br></div><div>That is correct, and it also deni=
es refund_tx_2 by making the revoke_tx directly spendable by Bob.</div><div=
><br></div><div>&gt;could Bob just spend the Alice&amp;Bob output of the ve=
ry first, &quot;commitment&quot; transaction that locks BTC</div><div><br><=
/div><div>Yes, he can. This is what makes it possible to complete the proto=
col in merely two transactions.</div><div><br></div><div>&gt;Bob will recei=
ve BTC, and the LTC can be locked forever, but Bob doesn&#39;t care, he got=
 his BTC.</div><div><br></div><div>No, because diagram step 5 comes before =
step 6 -- Alice won&#39;t give her key until she learns secretBob.</div><di=
v><br></div><div>I hope this clarifies it!</div><div><br></div><div>Cheers,=
</div><div>Ruben</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Thu, May 14, 2020 at 6:49 AM Dmitry Petukhov &lt;<=
a href=3D"mailto:dp@simplexum.com">dp@simplexum.com</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">=D0=92 Wed, 13 May 2020 =
21:03:17 +0200<br>
Ruben Somsen &lt;<a href=3D"mailto:rsomsen@gmail.com" target=3D"_blank">rso=
msen@gmail.com</a>&gt; wrote:<br>
<br>
&gt; Or perhaps you&#39;re referring to the issue ZmnSCPxj pointed out afte=
r<br>
&gt; that, where refund transaction #1 and the success transaction could<br=
>
&gt; both become valid at the same time. It would make sense for the test<b=
r>
&gt; to pick up on that, but I believe that is ultimately also not an<br>
&gt; issue (see my last reply in the thread).<br>
<br>
This one.<br>
<br>
The issue as I see it: Bob can not broadcast success_tx and wait until<br>
Alice has broadcasted refund_tx_1. While refund_tx_1 is in the mempool,<br>
Bob gives success_tx to the friendly miner to have a chance to<br>
invalidate success_tx. Bob already learned secretAlice, so he grabs<br>
his LTC back. If the Bob-friendly miner has luck, success_tx is<br>
confirmed while refund_tx_1 is invalidated, and Bob now have both LTC<br>
and BTC, while Alice is out of her BTC.<br>
<br>
&gt; &gt;I did not understand what the destination of Alice&amp;Bob coopera=
tive<br>
&gt; &gt;spend=C2=A0 <br>
&gt; of refund_tx#1 will be<br>
&gt; <br>
&gt; This transaction can be spent by Alice &amp; Bob right away or by Alic=
e a<br>
&gt; day later (in relative time, so the tx has to confirm first). The<br>
&gt; Alice &amp; Bob condition is there purely to ensure that Bob can spend=
<br>
&gt; the money before Alice once he receives her key at the end of the<br>
&gt; protocol.<br>
<br>
Ah, so this is possible because of the step 5 in the diagram: ``Alice<br>
gives Bob her key (&quot;Alice&quot;)&#39;&#39; -- As I understand, this is=
 a way to deny<br>
Alice to use refund_tx_1.<br>
<br>
Then if Alice gives her _key_ to Bob before Bob has to share secretBob<br>
via success_tx, could Bob just spend the Alice&amp;Bob output of the<br>
very first, &quot;commitment&quot; transaction that locks BTC ? Bob will re=
ceive<br>
BTC, and the LTC can be locked forever, but Bob doesn&#39;t care, he got<br=
>
his BTC.<br>
</blockquote></div>

--0000000000000ddfd505a59502db--