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 <d...@simplexum.com> wrote: > В Thu, 14 May 2020 07:31:13 +0200 > Ruben Somsen <rsom...@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) >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
