Author: Rusty Russell 2016-02-10 01:15:16
Published on: 2016-02-10T01:15:16+00:00
In a discussion on the Lightning Network, Rusty Russell suggests that all outputs to A in A's commit transaction must be delayed (via OP_CSV) and this includes HTLC outputs. He further explains that the "HTLC Receiver Redeemscript" is actually something like R-VALUE & OP_CSV & SIG-PAYEE OR HTLC-TIMEOUT & SIG-PAYER OR REVOCATION-B & SIG A. The problem arises when Eve becomes unresponsive on one channel and Alice has to broadcast her commit transaction containing the HTLC before the CLTV of the HTLC times out, or else Eve can try to claim the HTLC funds. Rusty explains that if A insists that B use a 30-day CSV, A can't ask B to accept an HTLC with less than 31 days lifetime.He further elaborates that even if we assume always-on, always connected nodes, systems can fail, and manual intervention may be needed to restore them. So, we need to take into account that downtime / DoS attack may cause theft escalation which we don't want. Finally, he suggests that c-lightning requests a CSV timeout of 1 day, allows requests of up to 2 days. It only allows HTLCS of up to 5 days in the future, but it wants a 6-hour window minimum. If we want to allow CSV timeouts of 5 days, HTLC timeout decrements of up to 1 day per node over 20 hops, that means we need to allow HTLC timeouts of 26 days.
Updated on: 2023-05-23T18:24:20.021379+00:00