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