From aj at erisian.com.au Sat Oct 13 11:40:30 2018 From: aj at erisian.com.au (Anthony Towns) Date: Sat, 13 Oct 2018 20:40:30 +0900 Subject: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts In-Reply-To: References: <874ljsitvx.fsf@gmail.com> <20181010082546.76h34hw7bmtse4wq@erisian.com.au> Message-ID: <6B311A73-C21C-42DF-A059-3E88EC725791@erisian.com.au> On 13 October 2018 7:12:03 pm GMT+09:00, Christian Decker wrote: >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 >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 Secure Email. >> >> ??????? Original Message ??????? >> On Friday, October 12, 2018 1:37 AM, Christian Decker < >> decker.christian at 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 >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 >>> >>> >> Hmm - the range grows by one every second though, so as long as you don't go through a billion updates per second, you can go to 100% of the range, knowing that by the time you have to increment, you'll have 115% of the original range available, meaning you never need more than two transactions (until locktime overflows anyway) for the commitment, even at 900MHz transaction rates... Cheers, aj -- Sent from my phone.