Great find ZmnSCPxj, we can also have an adaptive scheme here, in which we start with a single update transaction, and then at ~90% of the available range we add a second. This is starting to look a bit like the DMC invalidation tree :-) But realistically speaking I don't think 1B updates is going to be exhausted any time soon, but the adaptive strategy gets the best of both worlds.
Cheers, Christian On Fri, Oct 12, 2018 at 5:21 AM ZmnSCPxj <zmnsc...@protonmail.com> wrote: > Another way would be to always have two update transactions, effectively > creating a larger overall counter: > > [anchor] -> [update highbits] -> [update lobits] -> [settlement] > > We normally update [update lobits] until it saturates. If lobits > saturates we increment [update highbits] and reset [update lobits] to the > lowest valid value. > > This will provide a single counter with 10^18 possible updates, which > should be enough for a while even without reanchoring. > > Regards, > ZmnSCPxj > > > Sent with ProtonMail <https://protonmail.com> Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Friday, October 12, 2018 1:37 AM, Christian Decker < > decker.christ...@gmail.com> wrote: > > 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 Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
