David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2018-06-19 📝 Original message: Hi, I finished a re-read ...

📅 Original date posted:2018-06-19
📝 Original message:
Hi,

I finished a re-read of y'alls excellent paper describing Eltoo, and
there was something that confused me:

> If the update transaction represents the last agreed upon state it can
> use relatively low fees being certain that it will not be replaced.

I don't understand why this is "certain"? State_2 can't replace State_3
on the block chain (ignoring reorgs) because S_2's nLockTime of n+2
doesn't satisify S_3's CLTV-enforced minimum state number/locktime of
n+4. But in the mempool this constraint doesn't hold: if S_3 is in the
mempool, S_2 can simply pay more fees than S_3 for RBF replacement.

A mempool replacement of S_3 with S_2 also invalidates the transaction
containing S_3 until one of the participants rewrites it from binding to
State_1's outpoint to binding to S_2's outpoint.

Unless I'm misunderstanding, this could perhaps be clarified to make
clear that, even in the case of a cooperative close, monitoring for old
states needs to continue until the final state has whatever number of
confirmations a participant deems sufficient to make it immutable.

Thanks,

-Dave

P.S.: The paper I re-read was the version (as of yesterday) at blockstream.com/eltoo.pdf

$ grep -a CreationDate eltoo.pdf
/CreationDate (D:20180502232831+02'00')
$ sha256sum eltoo.pdf
aa630d637e4e1aedd91249d52609ab75b2eef2da8e4146e74f30e63c96fb7c26 eltoo.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180619/1c533520/attachment.sig>;