[Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

[Corné Plooy]

Hi Christian, ZmnSCPxj ,


>> - The CSV-encumberance on settlement transactions, which are the ones
>> which carry the contracts in the channel, affects all
>> absolute-timelocked contracts transported on the channel.  Compare to
>> Poon-Dryja, where commitment transactions themselves are unencumbered
>> by CSV, and we simply insert the revocation to spends of the contracts
>> being transported (i.e. the reason why we have HTLC-success and
>> HTLC-timeout transactions in BOLT spec).
> True, but as I argued in another mail, this is a fixed offset, that is
> in the same range as today's CLTV deltas for some nodes. So for the
> network of today using eltoo is roughly equivalent of adding another hop
> to our path :-)

Let me think how this is supposed to work (I can't find that other mail
you're referring to):

I assume the HTLC outputs are in the settlement transaction. In case of
a unilateral close while there are HTLCs present, the following sequence
happens:
1. The trigger transaction is broadcasted.
2. One or more update transactions are broadcasted. These are not
affected by the CSV condition and can be confirmed immediately. Once the
last update transaction gets confirmed, its CSV clock for the settlement
transaction starts.
3. The settlement transaction (containing HTLCs) can be broadcasted, but
it will not be confirmed before the CSV time-out of the last update
transaction.
4. At this point, the HTLC conditions become relevant. Before the HTLC
time-out, the receiving side can access the funds with the preimage.
After the timeout, the sending side can access the funds without the
preimage.

If the HTLC time-out is before the start of step 4, then the sending
side can try to get the funds back, even if the preimage was already
released much earlier. For the safety of the receiving side, this
situation must be avoided. So, if T is the (absolute) HTLC time-out
time, S is the CSV time-out period and C is the expected worst-case time
involved in confirming everything, then the receiving side of a HTLC
must drop the channel on-chain before T - S - C. Obviously, HTLCs for
which this time has already passed on creation must be rejected.
Dropping on-chain is no longer needed if the HTLC is removed by a
channel update before T - S - C.

What happens in case of a transaction time-out? Let's number the nodes
0, 1, ... on the route, and Tn the HTLC time-out between nodes n and
n+1. For simplicity, assume the same S+C for all channels. If node n
becomes unresponsive after accepting its incoming HTLC, then two moments
in time are relevant:
* T(n-1)
* T(n-2) - S - C
In case T(n-1) happens first, node n-1 knows it doesn't have to pay
outgoing funds, so it can cooperatively cancel the incoming HTLC. This
will propagate back immediately, keeping all channels open.
In case T(n-2) - S - C happens first, node n-1 has to close its channel
with n-2. On-chain, the HTLC conditions continue to apply, so for the
rest, nothing changes. As soon as T(n-1) is reached, node n-1 knows the
transaction has timed out, but it no longer has a way to propagate this
knowledge to node n-2. For node n-2, two times are relevant:
* T(n-2)
* T(n-3) - S - C
... and the same steps are repeated. In this case, a transaction
time-out leads to closing all channels on the route. This is a major DoS
attack vector, and must be prevented.

Therefore, we must set T(n-1) > T(n-2) - S - C, so the HTLC time-out
increment must be at least S+C.

Theoretically, it seems workable. What would be a practical value for S
(the CSV time-out)? In the absence of watch towers, you'd want to set it
to at least a couple of weeks, to allow yourself to go off-line on
holiday without worrying about computer issues. However, a time-out
increment of a couple of weeks *per hop* for the HTLCs adds up really
quickly to unpractical values. Maybe the conclusion simply is that we
really really need watchtowers? Otherwise, only professional parties
that can manage near-100% uptime can safely perform transaction routing.

CJP