ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-12 📝 Original message: Another way would be to ...
📅 Original date posted:2018-10-12
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181012/259fb8da/attachment-0001.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181012/259fb8da/attachment-0001.html>;