From aj at erisian.com.au  Wed Oct 10 08:25:46 2018
From: aj at erisian.com.au (Anthony Towns)
Date: Wed, 10 Oct 2018 18:25:46 +1000
Subject: [Lightning-dev] eltoo: A Simplified update Mechanism for
 Lightning and Off-Chain Contracts
In-Reply-To: <874ljsitvx.fsf@gmail.com>
References: <874ljsitvx.fsf@gmail.com>
Message-ID: <20181010082546.76h34hw7bmtse4wq@erisian.com.au>

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