public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Dmitry Petukhov <dp@simplexum.com>
To: Ruben Somsen <rsomsen@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] TLA+ specification for Succint Atomic Swap
Date: Thu, 14 May 2020 09:52:15 +0500	[thread overview]
Message-ID: <20200514095215.4ea20666@simplexum.com> (raw)
In-Reply-To: <CAPv7TjbZVYTztQLd2dxjzFajhPTg23iWtapkVBzz+z0q=pH2rw@mail.gmail.com>

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


  reply	other threads:[~2020-05-14  4:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13 17:02 [bitcoin-dev] TLA+ specification for Succint Atomic Swap Dmitry Petukhov
2020-05-13 19:03 ` Ruben Somsen
2020-05-14  4:52   ` Dmitry Petukhov [this message]
2020-05-14  5:31     ` Ruben Somsen
2020-05-14  7:08       ` Dmitry Petukhov
2020-05-14 11:41         ` Ruben Somsen
2020-06-01 11:38 ` Dmitry Petukhov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200514095215.4ea20666@simplexum.com \
    --to=dp@simplexum.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=rsomsen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox