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.