From decker.christian at gmail.com Thu Oct 11 17:37:56 2018 From: decker.christian at gmail.com (Christian Decker) Date: Thu, 11 Oct 2018 19:37:56 +0200 Subject: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts In-Reply-To: <20181010082546.76h34hw7bmtse4wq@erisian.com.au> References: <874ljsitvx.fsf@gmail.com> <20181010082546.76h34hw7bmtse4wq@erisian.com.au> Message-ID: 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 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: