Good morning Jim,

> If my understanding is correct though, this construction would significantly increase the safe CLTV delta requirements because HTLCs cannot be timed out immediately on the settlement transaction. Consider a case where node B receives an HTLC from A and forwards to C. If the HTLC offered to C times out and C does not fail the HTLC off-chain, Lightning currently guarantees that the CLTV delta is sufficient that I may close the channel to C on-chain and claim the timed-out HTLC before my upstream HTLC to A times out. If the CLTV delta is too small, I may fail the upstream HTLC as soon as it times out, and then C may still claim the downstream HTLC with the preimage on-chain. With eltoo, when B closes the downstream channel on-chain, it must wait the CSV timeout on the update transaction before locking in the timed-out HTLC. This effectively means the CLTV delta has to be greater than the CSV timeout, plus some extra (whereas it is currently safe to make it significantly shorter). Is that true or am I missing something?

I believe this is quite true; indeed only the LN-penalty/Poon-Dryja channels do not have this drawback, as Decker-Wattenhofer invalidation trees also have the same drawback that the CSV and CLTV add up.

However the worst-case invalidation tree total CSV timeouts under Decker-Wattenhofer can grow quite massive; it seems the new eltoo Decker-Russell-Osuntokun CSV timeouts can be shorter.

Regards,
ZmnSCPxj