Re: [bitcoin-dev] TLA+ specification for Succint Atomic Swap

[Ruben Somsen <rsomsen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3366 bytes --]

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:

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

[-- Attachment #2: Type: text/html, Size: 4146 bytes --]