From 49239904f822a2792fc4957090240cb516173853 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 f134f74aa1f..8d3d5261898 100644 --- a/lightning/src/ln/channelmanager.rs +++ b/lightning/src/ln/channelmanager.rs @@ -575,10 +575,13 @@ pub(crate) const MAX_LOCAL_BREAKDOWN_TIMEOUT: u16 = 2 * 6 * 24 * 7; pub const MIN_CLTV_EXPIRY_DELTA: u16 = 6*7; pub(super) const CLTV_FAR_FAR_AWAY: u32 = 6 * 24 * 7; //TODO? +// 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. /// 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; +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