Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-10 📝 Original message: On Mon, Apr 30, 2018 at ...
📅 Original date posted:2018-10-10
📝 Original message:
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
📝 Original message:
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