Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-13 📝 Original message: On 13 October 2018 ...
📅 Original date posted:2018-10-13
📝 Original message:
On 13 October 2018 7:12:03 pm GMT+09:00, Christian Decker <decker.christian at gmail.com> 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 <ZmnSCPxj at 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.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 <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
>>>
>>>
>>
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.
📝 Original message:
On 13 October 2018 7:12:03 pm GMT+09:00, Christian Decker <decker.christian at gmail.com> 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 <ZmnSCPxj at 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.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 <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
>>>
>>>
>>
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.