[Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

[Christian Decker]

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 <aj at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181011/c03ad2ea/attachment.html>