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

--00000000000081739705a59a2eb4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dmitry,

>But it should be noted that it is not enough that Bob publishes success_tx
before refund_tx_1 became valid. The success_tx needs to be confirmed
before refund_tx_1 became valid.

Agreed, my write-up would benefit from pointing this out more explicitly.

Cheers,
Ruben

On Thu, May 14, 2020 at 9:05 AM Dmitry Petukhov <dp@simplexum.com> wrote:

> =D0=92 Thu, 14 May 2020 07:31:13 +0200
> Ruben Somsen <rsomsen@gmail.com> wrote:
>
> > 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.
>
> Right. But it should be noted that it is not enough that Bob publishes
> success_tx before refund_tx_1 became valid. The success_tx needs to be
> confirmed before refund_tx_1 became valid.
>
> Only Bob can spend success_tx so this is unlikely to be the practical
> problem, unless the original fee of success_tx is too small and Bob
> epically screws up CPFP-ing it.
>
> > >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 somehow missed it, and steps 5 and 6 in the diagram was not modelled
> at all (on the other hand, it made the model simpler and I had
> something working relatively quick). I now made the `signers_map` into
> variable that can be changed to give Bob the ability to sign for Alice.
>
> With that change, step 6 can be modelled, but this will add a bunch of
> new txs to the model (each Alice&Bob spend will have 'Bob unilateral
> override' case)
>

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

<div dir=3D"ltr">Hi Dmitry,<div><br></div><div>&gt;But it should be noted t=
hat it is not enough that Bob publishes success_tx before refund_tx_1 becam=
e valid. The success_tx needs to be confirmed before refund_tx_1 became val=
id.<br></div><div><br></div><div>Agreed, my write-up would benefit from poi=
nting this out more explicitly.</div><div><br></div><div>Cheers,</div><div>=
Ruben</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Thu, May 14, 2020 at 9:05 AM Dmitry Petukhov &lt;<a href=3D"m=
ailto:dp@simplexum.com">dp@simplexum.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">=D0=92 Thu, 14 May 2020 07:31:13 +0=
200<br>
Ruben Somsen &lt;<a href=3D"mailto:rsomsen@gmail.com" target=3D"_blank">rso=
msen@gmail.com</a>&gt; wrote:<br>
<br>
&gt; Hi Dmitry,<br>
&gt; <br>
&gt; &gt;While refund_tx_1 is in the mempool, Bob gives success_tx to the<b=
r>
&gt; &gt;friendly miner<br>
&gt; <br>
&gt; I see, so you&#39;re talking about prior to protocol completion, right=
<br>
&gt; after Alice sends Bob the success_tx. The reason this is not an issue<=
br>
&gt; is because Alice and Bob both had to misbehave in order for this to<br=
>
&gt; happen. Bob is misbehaving here because he should have published the<b=
r>
&gt; success_tx before refund_tx_1 became valid, and Alice is misbehaving<b=
r>
&gt; here because she should have sent the revoke_tx (which invalidates<br>
&gt; the success_tx) followed by refund_tx_2 (revealing her secret only<br>
&gt; AFTER Bob can no longer claim the BTC). In other words: yes, the<br>
&gt; protocol can fail if Alice and Bob together work towards that goal. A<=
br>
&gt; feature, not a bug. This won&#39;t happen if either of them doesn&#39;=
t want<br>
&gt; it to. I imagine this is difficult to model.<br>
<br>
Right. But it should be noted that it is not enough that Bob publishes<br>
success_tx before refund_tx_1 became valid. The success_tx needs to be<br>
confirmed before refund_tx_1 became valid.<br>
<br>
Only Bob can spend success_tx so this is unlikely to be the practical<br>
problem, unless the original fee of success_tx is too small and Bob<br>
epically screws up CPFP-ing it.<br>
<br>
&gt; &gt;Bob will receive BTC, and the LTC can be locked forever, but Bob<b=
r>
&gt; &gt;doesn&#39;t=C2=A0 <br>
&gt; care, he got his BTC.<br>
&gt; <br>
&gt; No, because diagram step 5 comes before step 6 -- Alice won&#39;t give=
<br>
&gt; her key until she learns secretBob.<br>
<br>
I somehow missed it, and steps 5 and 6 in the diagram was not modelled<br>
at all (on the other hand, it made the model simpler and I had<br>
something working relatively quick). I now made the `signers_map` into<br>
variable that can be changed to give Bob the ability to sign for Alice.<br>
<br>
With that change, step 6 can be modelled, but this will add a bunch of<br>
new txs to the model (each Alice&amp;Bob spend will have &#39;Bob unilatera=
l<br>
override&#39; case)<br>
</blockquote></div>

--00000000000081739705a59a2eb4--