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.

bitcoin-dev mailing list

Reply via email to