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