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
signature.asc
Description: PGP signature
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
