📅 Original date posted:2018-10-13
📝 Original message:
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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181013/92190e1e/attachment.html>;
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:51:48
in reply to nevent1q…589n
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:51:48Event JSON
{
"id": "e80e437d3678cb63dd4a7f4cc4adf4c6dadbef3bae4b93fcb591648edc667848",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315108,
"kind": 1,
"tags": [
[
"e",
"a0b1dd922d42a4ed88aafdc2eb54863b152f6ce85f46a4b9c4ff641a3ece4f23",
"",
"root"
],
[
"e",
"e03757fc84e27dcefa9bde09fa5e8ebcad61e2658db415e033452263f8107f6a",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-10-13\n📝 Original message:\nGreat find ZmnSCPxj, we can also have an adaptive scheme here, in which we\nstart with a single update transaction, and then at ~90% of the available\nrange we add a second. This is starting to look a bit like the DMC\ninvalidation tree :-)\nBut realistically speaking I don't think 1B updates is going to be\nexhausted any time soon, but the adaptive strategy gets the best of\nboth worlds.\n\nCheers,\nChristian\n\nOn Fri, Oct 12, 2018 at 5:21 AM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Another way would be to always have two update transactions, effectively\n\u003e creating a larger overall counter:\n\u003e\n\u003e [anchor] -\u003e [update highbits] -\u003e [update lobits] -\u003e [settlement]\n\u003e\n\u003e We normally update [update lobits] until it saturates. If lobits\n\u003e saturates we increment [update highbits] and reset [update lobits] to the\n\u003e lowest valid value.\n\u003e\n\u003e This will provide a single counter with 10^18 possible updates, which\n\u003e should be enough for a while even without reanchoring.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\n\u003e Sent with ProtonMail \u003chttps://protonmail.com\u003e Secure Email.\n\u003e\n\u003e ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐\n\u003e On Friday, October 12, 2018 1:37 AM, Christian Decker \u003c\n\u003e decker.christian at gmail.com\u003e wrote:\n\u003e\n\u003e Thanks Anthony for pointing this out, I was not aware we could\n\u003e roll keypairs to reset the state numbers.\n\u003e\n\u003e I basically thought that 1billion updates is more than I would\n\u003e ever do, since with splice-in / splice-out operations we'd be\n\u003e re-anchoring on-chain on a regular basis anyway.\n\u003e\n\u003e\n\u003e\n\u003e On Wed, Oct 10, 2018 at 10:25 AM Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\u003e\n\u003e\u003e On Mon, Apr 30, 2018 at 05:41:38PM +0200, Christian Decker wrote:\n\u003e\u003e \u003e eltoo is a drop-in replacement for the penalty based invalidation\n\u003e\u003e \u003e mechanism that is used today in the Lightning specification. [...]\n\u003e\u003e\n\u003e\u003e Maybe this is obvious, but in case it's not, re: the locktime-based\n\u003e\u003e sequencing in eltoo:\n\u003e\u003e\n\u003e\u003e \"any number above 0.500 billion is interpreted as a UNIX timestamp, and\n\u003e\u003e with a current timestamp of ~1.5 billion, that leaves about 1 billion\n\u003e\u003e numbers that are interpreted as being in the past\"\n\u003e\u003e\n\u003e\u003e I think if you had a more than a 1B updates to your channel (50 updates\n\u003e\u003e per second for 4 months?) I think you could reset the locktime by rolling\n\u003e\u003e over to use new update keys. When unilaterally closing you'd need to\n\u003e\u003e use an extra transaction on-chain to do that roll-over, but you'd save\n\u003e\u003e a transaction if you did a cooperative close.\n\u003e\u003e\n\u003e\u003e ie, rather than:\n\u003e\u003e\n\u003e\u003e [funding] -\u003e [coop close / re-fund] -\u003e [update 23M] -\u003e [HTLCs etc]\n\u003e\u003e or\n\u003e\u003e [funding] -\u003e [coop close / re-fund] -\u003e [coop close]\n\u003e\u003e\n\u003e\u003e you could have:\n\u003e\u003e [funding] -\u003e [update 1B] -\u003e [update 23,310,561 with key2] -\u003e [HTLCs]\n\u003e\u003e or\n\u003e\u003e [funding] -\u003e [coop close]\n\u003e\u003e\n\u003e\u003e You could repeat this when you get another 1B updates, making unilateral\n\u003e\u003e closes more painful, but keeping cooperative closes cheap.\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e aj\n\u003e\u003e\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181013/92190e1e/attachment.html\u003e",
"sig": "3fb03f717a53e45a46326bc46b4d6ea59dea49149ff376e3b3a029510369f7c8a456689723c71d091798bd6cbf1e5502a536fb0c05c5257d88eeb681c3490e52"
}