From 68c2c4455933ccbb924a9297d85e78eb39576814 Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Wed, 5 May 2021 02:17:02 +0000 Subject: [PATCH] Correct MIN_FINAL_CLTV_EXPIRY to match our enforced requirements Our enforced requirements for HTLC acceptance is that we have at least HTLC_FAIL_BACK_BUFFER blocks before the HTLC expires. When we receive an HTLC, the HTLC would be "already expired" if its `cltv_expiry` is current-block + 1 (ie the next block could broadcast the commitment transaction and time out the HTLC). From there, we want an extra HTLC_FAIL_BACK_BUFFER in blocks, plus an extra block or two to account for any differences in the view of the current height before send or while the HTLC is transiting the network. --- lightning/src/ln/channelmanager.rs | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs index f134f74aa1..dfcb85110f 100644 --- a/lightning/src/ln/channelmanager.rs +++ b/lightning/src/ln/channelmanager.rs @@ -578,7 +578,10 @@ pub(super) const CLTV_FAR_FAR_AWAY: u32 = 6 * 24 * 7; //TODO? /// Minimum CLTV difference between the current block height and received inbound payments. /// Invoices generated for payment to us must set their `min_final_cltv_expiry` field to at least /// this value. -pub const MIN_FINAL_CLTV_EXPIRY: u32 = HTLC_FAIL_BACK_BUFFER; +// Note that we fail if exactly HTLC_FAIL_BACK_BUFFER + 1 was used, so we need to add one for +// any payments to succeed. Further, we don't want payments to fail if a block was found while +// a payment was being routed, so we add an extra block to be safe. +pub const MIN_FINAL_CLTV_EXPIRY: u32 = HTLC_FAIL_BACK_BUFFER + 3; // Check that our CLTV_EXPIRY is at least CLTV_CLAIM_BUFFER + ANTI_REORG_DELAY + LATENCY_GRACE_PERIOD_BLOCKS, // ie that if the next-hop peer fails the HTLC within