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.



P.S.: The paper I re-read was the version (as of yesterday) at 

    $ grep -a CreationDate eltoo.pdf 
    /CreationDate (D:20180502232831+02'00')
    $ sha256sum eltoo.pdf 
    aa630d637e4e1aedd91249d52609ab75b2eef2da8e4146e74f30e63c96fb7c26  eltoo.pdf

Attachment: signature.asc
Description: PGP signature

Lightning-dev mailing list

Reply via email to