"David A. Harding" <d...@dtrt.org> writes: > 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.
That is true, we can't prevent S_2 to make it into the blockchain, but we can make sure it doesn't have any effect (aside from wasting some fees), by simply binding S_3 to it immediately afterwards. So if S_3 is the last agreed upon state, we can bind it to the funding output or any intermediate ones, i.e., when an intermediate update makes it into the blockchain. Eventually S_3, bound to some prior update output and ideally directly to the funding output, will make it into the blockchain at which point the game is over. Intermediate updates may have leaked into the blockchain, but did not unlock the intermediate settlement path and the blockchain was paid with the fees attached to the intermediate updates. > 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. It should be noted that anyone can perform the rewriting, and it's easy to do so, by just following the funding output and knowing the final update. > 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. Good point, we did not mention that finality has to be ensured, and that in a case of a reorg that unconfirms the update we might have to perform additional rewrites. This is similar to LN-penalty where we actually need to make sure that the penalty transaction is final and doesn't get reorged out. Cheers, Christian _______________________________________________ Lightning-dev mailing list Lightningemail@example.com https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev