path: root/b2/cd71c0ce5ca70bf5c8780bd525584d782613ca

Return-Path: <rsomsen@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2B8A8C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 May 2020 11:41:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 1A28E888E5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 May 2020 11:41:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id C3dhIX0BgUWs
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 May 2020 11:41:49 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com
 [209.85.208.51])
 by hemlock.osuosl.org (Postfix) with ESMTPS id 0A278888B6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 May 2020 11:41:49 +0000 (UTC)
Received: by mail-ed1-f51.google.com with SMTP id bs4so2105639edb.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 May 2020 04:41:48 -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=Qz8HUvwai8YkAA7Utlu+CjU422AFWmmMcp0LJNceeyM=;
 b=IYHKM4MHYitVbTiQmUWC90IqQZyzUITWzcvYWnkUqZA6IjuaCRXi9ZbN1jP3jq7WGu
 qE37gn8OOEy+3zooVkSCzpPWZbHwndeJewFBmuLdO4zsEyi1zFAHu2oKfof6Zz0uZGt8
 Tbszg8/DxyzjmIadKKdz5AgBk5flRjXMpJwbUrWgurVFIa+6WyHlxw3BpWHthLVV0dEW
 COOTMmEdDSrIOK9j4w9LY/moAm9gZ6300j+zFte9VITz1PSVRT3IJ640YokZZRN42aTp
 GfzSKY9oDlVsKx6dBJWq3D5jhh7UDHvbEns5pMDvw6GVOkvWlHqDyror2dXXbj63Sou4
 EhYw==
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=Qz8HUvwai8YkAA7Utlu+CjU422AFWmmMcp0LJNceeyM=;
 b=BO91+YXBNn/ep7DpBijOqZ7dOkJvwVR2eKOigORCQ/3Xr91/Wgv06Nzqk3RWJy0LeO
 sk38UK6aVLTRYDJdvvnkz2iZSEu2RF91yku7wsP1RT48r10t7do8FzRwxNs7sFSwA+Iz
 5FCYgYL09dPsCVag0BIf3EJhfiqKqyyiz89AwulT7/Y51Ta9Q8/jz9n5A3JKJtFuvi4n
 F52utLKVbLjn4DTLHYKgtqcDQ49230lQptK/Ocj7lXGsRYvUGXd8+feqD1YFTakWfrWd
 k0x/EZYC9P3kI0RMMii6vm+CSCYQLqMc1BaYyjC+1Z0IlRvNsqEOd2uWCJau2nmPHv1x
 p8Ow==
X-Gm-Message-State: AOAM531EaT9Km0r6QO05fbvn/Byg8JY7vqRk0xg01RvR5/ukuZDoRH2l
 m+R1olXL7DAxLvnassx4NWEw3tmc1zV2sfeRelA=
X-Google-Smtp-Source: ABdhPJwMiyIwn0PS23Y/UtjA0MW8cTmRBTPVd6h+bzs+weDB5nGpaYVErfvQHx4et/HTxYoDm5X6MfXG+/DNzvkQiEo=
X-Received: by 2002:a50:9b58:: with SMTP id a24mr3289648edj.256.1589456507333; 
 Thu, 14 May 2020 04:41:47 -0700 (PDT)
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"
X-Mailman-Approved-At: Thu, 14 May 2020 11:42:45 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2020 11:41:50 -0000

--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--