Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2018-06-19 📝 Original message: "David A. Harding" <dave ...

📅 Original date posted:2018-06-19
📝 Original message:
"David A. Harding" <dave at 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