Thanks Anthony for pointing this out, I was not aware we could roll keypairs to reset the state numbers.
I basically thought that 1billion updates is more than I would ever do, since with splice-in / splice-out operations we'd be re-anchoring on-chain on a regular basis anyway. On Wed, Oct 10, 2018 at 10:25 AM Anthony Towns <a...@erisian.com.au> wrote: > On Mon, Apr 30, 2018 at 05:41:38PM +0200, Christian Decker wrote: > > eltoo is a drop-in replacement for the penalty based invalidation > > mechanism that is used today in the Lightning specification. [...] > > Maybe this is obvious, but in case it's not, re: the locktime-based > sequencing in eltoo: > > "any number above 0.500 billion is interpreted as a UNIX timestamp, and > with a current timestamp of ~1.5 billion, that leaves about 1 billion > numbers that are interpreted as being in the past" > > I think if you had a more than a 1B updates to your channel (50 updates > per second for 4 months?) I think you could reset the locktime by rolling > over to use new update keys. When unilaterally closing you'd need to > use an extra transaction on-chain to do that roll-over, but you'd save > a transaction if you did a cooperative close. > > ie, rather than: > > [funding] -> [coop close / re-fund] -> [update 23M] -> [HTLCs etc] > or > [funding] -> [coop close / re-fund] -> [coop close] > > you could have: > [funding] -> [update 1B] -> [update 23,310,561 with key2] -> [HTLCs] > or > [funding] -> [coop close] > > You could repeat this when you get another 1B updates, making unilateral > closes more painful, but keeping cooperative closes cheap. > > Cheers, > aj > >
_______________________________________________ Lightning-dev mailing list Lightningemail@example.com https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev