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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
