Correct and update confirmation target constant definitions by TheBlueMatt · Pull Request #3608 · lightningdevkit/rust-lightning

TheBlueMatt · 2025-02-18T13:44:17Z

In the process of #3340 I noticed a bunch of our confirmation target constants don't make sense anymore post-anchor (and one of our checks made no sense ever). So here we update them, taking this opportunity to also increase a few windows.

wpaulino

CI has a few test failures that need to be fixed

wpaulino · 2025-02-24T21:26:09Z

Feel free to squash

TheBlueMatt · 2025-02-24T21:40:06Z

Squashed without changes.

wpaulino · 2025-02-24T23:18:06Z

Needs rustfmt

TheBlueMatt · 2025-02-25T19:46:37Z

Grrr, done.

valentinewallace · 2025-03-04T21:12:43Z

+// in with enough time left to fail the corresponding HTLC back to our inbound edge before they
+// force-close on us.
+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have


s/after expiry/before expiry?

No after. We FC a channel several blocks after an HTLC expires.

valentinewallace · 2025-03-04T21:13:31Z

+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have
+// 2*MAX_BLOCKS_FOR_CONF + ANTI_REORG_DELAY left to get two transactions on chain and the second
+// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the


suggestion:
Suggested change
// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the
// fully locked in before the inbound peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the

That reads kinda confusing to me? Makes it sound like the channel was inbound from the peer, rather than the HTLC was relayed inbound from the peer?

valentinewallace · 2025-03-04T21:39:25Z

 /// If an HTLC expires within this many blocks, force-close the channel to broadcast the
 /// HTLC-Success transaction.


"HTLC-Success transaction" phrasing seems to suggest this const is only used in the context of channels with inbound HTLC(s) where we have the preimage. But it seems to be used for inbounds where we don't have the preimage as well, and/or other contexts? I wonder if this could be clarified?

Not directly? Its only used directly as !htlc_outbound && htlc.cltv_expiry <= height + CLTV_CLAIM_BUFFER && self.payment_preimages.contains_key(&htlc.payment_hash) and indirectly to calculate HTLC_FAIL_BACK_BUFFER which is the same concept.

The `CHECK_CLTV_EXPIRY_SANITY_2` check actually made no sense - its use of `2*CLTV_CLAIM_BUFFER` implicitly assumed that we were failing HTLCs `CLTV_CLAIM_BUFFER` after they expired, which is nonsense. Instead, we improve the readability of the docs on `_CHECK_CLTV_EXPIRY_SANITY` and add a new `_CHECK_CLTV_EXPIRY_OFFCHAIN` that correctly tests for what the `CHECK_CLTV_EXPIRY_SANITY_2` check was supposed to look at.

Over the years we've built up a few tests which rely on block count constants but without making direct references to those constants. Here we fix three such tests to ensure changing block count constants in the next commit do not break tests.

`test_duplicate_payment_hash_one_failure_one_success` makes a number of assumptions which rely on our specific CLTV constants, which we intend to change. Specifically, it relies on forwarding two HTLCs, one which goes one hop longer, and that it can close the channel with both HTLCs sitting on chain with enough time to claim that it doesn't give up on them but also that they get claimed in separate transactions. Here we clean up, simplify, and better document the test such that it is more resilient to future CLTV constant changes.

`CLTV_CLAIM_BUFFER`'s definition stated "this is an upper bound on how many blocks we think it can take us to get a transaction confirmed". This was mostly okay for pre-anchor channels, where we broadcasted HTLC claim transactions at the same time as the commitment transactions themselves, but for anchor channels we can no longer do that - HTLC transactions are always CSV 1'd. Further, when we do go to broadcast HTLC transactions, we start the feerate estimate for them back at the users' feerate estimator, rather than whatever feerate we ended up using to get the commitment transaction confirmed. While we should maybe consider changing that, for now that means that we really need to run the whole "get a transaction confirmed" process from start to finish *twice* in order to claim an HTLC. Thus, `CLTV_CLAIM_BUFFER` is here redefined to be two times "the upper bound on how many blocks we think it can take for us to get a transaction confirmed", with a new `MAX_BLOCKS_FOR_CONF` constant defining the expected max blocks.

In the previous commit it was observed that we actually have to run the whole "get a transaction confirmed" process from start to finish twice to claim an HTLC on an anchor channel. This leaves us with only 9 blocks to get each transaction confirmed, which is quite aggressive. Here we double this threshold, force-closing channels which have an expiring HTLC 36 blocks before expiry instead of 18. We also increase the minimum CLTV expiry delta to 48 to ensure we have at least a few blocks after the transactions get confirmed before we need to fail the inbound edge of a forwarded HTLC back. We do not change the default CLTV expiry delta of 72 blocks.

TheBlueMatt · 2025-03-05T19:23:02Z

Cleaned up the commit history with the following additional diff, plus rebased.

diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 66f004356..d01d25bbc 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -2816,3 +2816,3 @@ pub(crate) const MAX_LOCAL_BREAKDOWN_TIMEOUT: u16 = 2 * 6 * 24 * 7;
/// The minimum number of blocks between an inbound HTLC's CLTV and the corresponding outbound
-/// HTLC's CLTV. The current default represents roughly seven hours of blocks at six blocks/hour.+/// HTLC's CLTV. The current default represents roughly eight hours of blocks at six blocks/hour.
///
@@ -2845,3 +2845,3 @@ pub const MIN_FINAL_CLTV_EXPIRY_DELTA: u16 = HTLC_FAIL_BACK_BUFFER as u16 + 3;
// force-close on us.
-// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our+// In other words, if the next-hop peer fails HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have

TheBlueMatt · 2025-02-18T13:44:17Z

In the process of #3340 I noticed a bunch of our confirmation target constants don't make sense anymore post-anchor (and one of our checks made no sense ever). So here we update them, taking this opportunity to also increase a few windows.

wpaulino

CI has a few test failures that need to be fixed

wpaulino · 2025-02-24T21:26:09Z

Feel free to squash

TheBlueMatt · 2025-02-24T21:40:06Z

Squashed without changes.

wpaulino · 2025-02-24T23:18:06Z

Needs rustfmt

TheBlueMatt · 2025-02-25T19:46:37Z

Grrr, done.

valentinewallace · 2025-03-04T21:12:43Z

+// in with enough time left to fail the corresponding HTLC back to our inbound edge before they
+// force-close on us.
+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have


s/after expiry/before expiry?

No after. We FC a channel several blocks after an HTLC expires.

valentinewallace · 2025-03-04T21:13:31Z

+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have
+// 2*MAX_BLOCKS_FOR_CONF + ANTI_REORG_DELAY left to get two transactions on chain and the second
+// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the


suggestion:
Suggested change
// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the
// fully locked in before the inbound peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the

That reads kinda confusing to me? Makes it sound like the channel was inbound from the peer, rather than the HTLC was relayed inbound from the peer?

valentinewallace · 2025-03-04T21:39:25Z

 /// If an HTLC expires within this many blocks, force-close the channel to broadcast the
 /// HTLC-Success transaction.


"HTLC-Success transaction" phrasing seems to suggest this const is only used in the context of channels with inbound HTLC(s) where we have the preimage. But it seems to be used for inbounds where we don't have the preimage as well, and/or other contexts? I wonder if this could be clarified?

Not directly? Its only used directly as !htlc_outbound && htlc.cltv_expiry <= height + CLTV_CLAIM_BUFFER && self.payment_preimages.contains_key(&htlc.payment_hash) and indirectly to calculate HTLC_FAIL_BACK_BUFFER which is the same concept.

The `CHECK_CLTV_EXPIRY_SANITY_2` check actually made no sense - its use of `2*CLTV_CLAIM_BUFFER` implicitly assumed that we were failing HTLCs `CLTV_CLAIM_BUFFER` after they expired, which is nonsense. Instead, we improve the readability of the docs on `_CHECK_CLTV_EXPIRY_SANITY` and add a new `_CHECK_CLTV_EXPIRY_OFFCHAIN` that correctly tests for what the `CHECK_CLTV_EXPIRY_SANITY_2` check was supposed to look at.

Over the years we've built up a few tests which rely on block count constants but without making direct references to those constants. Here we fix three such tests to ensure changing block count constants in the next commit do not break tests.

`test_duplicate_payment_hash_one_failure_one_success` makes a number of assumptions which rely on our specific CLTV constants, which we intend to change. Specifically, it relies on forwarding two HTLCs, one which goes one hop longer, and that it can close the channel with both HTLCs sitting on chain with enough time to claim that it doesn't give up on them but also that they get claimed in separate transactions. Here we clean up, simplify, and better document the test such that it is more resilient to future CLTV constant changes.

`CLTV_CLAIM_BUFFER`'s definition stated "this is an upper bound on how many blocks we think it can take us to get a transaction confirmed". This was mostly okay for pre-anchor channels, where we broadcasted HTLC claim transactions at the same time as the commitment transactions themselves, but for anchor channels we can no longer do that - HTLC transactions are always CSV 1'd. Further, when we do go to broadcast HTLC transactions, we start the feerate estimate for them back at the users' feerate estimator, rather than whatever feerate we ended up using to get the commitment transaction confirmed. While we should maybe consider changing that, for now that means that we really need to run the whole "get a transaction confirmed" process from start to finish *twice* in order to claim an HTLC. Thus, `CLTV_CLAIM_BUFFER` is here redefined to be two times "the upper bound on how many blocks we think it can take for us to get a transaction confirmed", with a new `MAX_BLOCKS_FOR_CONF` constant defining the expected max blocks.

In the previous commit it was observed that we actually have to run the whole "get a transaction confirmed" process from start to finish twice to claim an HTLC on an anchor channel. This leaves us with only 9 blocks to get each transaction confirmed, which is quite aggressive. Here we double this threshold, force-closing channels which have an expiring HTLC 36 blocks before expiry instead of 18. We also increase the minimum CLTV expiry delta to 48 to ensure we have at least a few blocks after the transactions get confirmed before we need to fail the inbound edge of a forwarded HTLC back. We do not change the default CLTV expiry delta of 72 blocks.

TheBlueMatt · 2025-03-05T19:23:02Z

Cleaned up the commit history with the following additional diff, plus rebased.

diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 66f004356..d01d25bbc 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -2816,3 +2816,3 @@ pub(crate) const MAX_LOCAL_BREAKDOWN_TIMEOUT: u16 = 2 * 6 * 24 * 7;
/// The minimum number of blocks between an inbound HTLC's CLTV and the corresponding outbound
-/// HTLC's CLTV. The current default represents roughly seven hours of blocks at six blocks/hour.+/// HTLC's CLTV. The current default represents roughly eight hours of blocks at six blocks/hour.
///
@@ -2845,3 +2845,3 @@ pub const MIN_FINAL_CLTV_EXPIRY_DELTA: u16 = HTLC_FAIL_BACK_BUFFER as u16 + 3;
// force-close on us.
-// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our+// In other words, if the next-hop peer fails HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have

TheBlueMatt · 2025-02-18T13:44:17Z

In the process of #3340 I noticed a bunch of our confirmation target constants don't make sense anymore post-anchor (and one of our checks made no sense ever). So here we update them, taking this opportunity to also increase a few windows.

wpaulino

CI has a few test failures that need to be fixed

wpaulino · 2025-02-24T21:26:09Z

Feel free to squash

TheBlueMatt · 2025-02-24T21:40:06Z

Squashed without changes.

wpaulino · 2025-02-24T23:18:06Z

Needs rustfmt

TheBlueMatt · 2025-02-25T19:46:37Z

Grrr, done.

valentinewallace · 2025-03-04T21:12:43Z

+// in with enough time left to fail the corresponding HTLC back to our inbound edge before they
+// force-close on us.
+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have


s/after expiry/before expiry?

No after. We FC a channel several blocks after an HTLC expires.

valentinewallace · 2025-03-04T21:13:31Z

+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have
+// 2*MAX_BLOCKS_FOR_CONF + ANTI_REORG_DELAY left to get two transactions on chain and the second
+// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the


suggestion:
Suggested change
// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the
// fully locked in before the inbound peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the

That reads kinda confusing to me? Makes it sound like the channel was inbound from the peer, rather than the HTLC was relayed inbound from the peer?

valentinewallace · 2025-03-04T21:39:25Z

 /// If an HTLC expires within this many blocks, force-close the channel to broadcast the
 /// HTLC-Success transaction.


"HTLC-Success transaction" phrasing seems to suggest this const is only used in the context of channels with inbound HTLC(s) where we have the preimage. But it seems to be used for inbounds where we don't have the preimage as well, and/or other contexts? I wonder if this could be clarified?

Not directly? Its only used directly as !htlc_outbound && htlc.cltv_expiry <= height + CLTV_CLAIM_BUFFER && self.payment_preimages.contains_key(&htlc.payment_hash) and indirectly to calculate HTLC_FAIL_BACK_BUFFER which is the same concept.

The `CHECK_CLTV_EXPIRY_SANITY_2` check actually made no sense - its use of `2*CLTV_CLAIM_BUFFER` implicitly assumed that we were failing HTLCs `CLTV_CLAIM_BUFFER` after they expired, which is nonsense. Instead, we improve the readability of the docs on `_CHECK_CLTV_EXPIRY_SANITY` and add a new `_CHECK_CLTV_EXPIRY_OFFCHAIN` that correctly tests for what the `CHECK_CLTV_EXPIRY_SANITY_2` check was supposed to look at.

Over the years we've built up a few tests which rely on block count constants but without making direct references to those constants. Here we fix three such tests to ensure changing block count constants in the next commit do not break tests.

`test_duplicate_payment_hash_one_failure_one_success` makes a number of assumptions which rely on our specific CLTV constants, which we intend to change. Specifically, it relies on forwarding two HTLCs, one which goes one hop longer, and that it can close the channel with both HTLCs sitting on chain with enough time to claim that it doesn't give up on them but also that they get claimed in separate transactions. Here we clean up, simplify, and better document the test such that it is more resilient to future CLTV constant changes.

`CLTV_CLAIM_BUFFER`'s definition stated "this is an upper bound on how many blocks we think it can take us to get a transaction confirmed". This was mostly okay for pre-anchor channels, where we broadcasted HTLC claim transactions at the same time as the commitment transactions themselves, but for anchor channels we can no longer do that - HTLC transactions are always CSV 1'd. Further, when we do go to broadcast HTLC transactions, we start the feerate estimate for them back at the users' feerate estimator, rather than whatever feerate we ended up using to get the commitment transaction confirmed. While we should maybe consider changing that, for now that means that we really need to run the whole "get a transaction confirmed" process from start to finish *twice* in order to claim an HTLC. Thus, `CLTV_CLAIM_BUFFER` is here redefined to be two times "the upper bound on how many blocks we think it can take for us to get a transaction confirmed", with a new `MAX_BLOCKS_FOR_CONF` constant defining the expected max blocks.

In the previous commit it was observed that we actually have to run the whole "get a transaction confirmed" process from start to finish twice to claim an HTLC on an anchor channel. This leaves us with only 9 blocks to get each transaction confirmed, which is quite aggressive. Here we double this threshold, force-closing channels which have an expiring HTLC 36 blocks before expiry instead of 18. We also increase the minimum CLTV expiry delta to 48 to ensure we have at least a few blocks after the transactions get confirmed before we need to fail the inbound edge of a forwarded HTLC back. We do not change the default CLTV expiry delta of 72 blocks.

TheBlueMatt · 2025-03-05T19:23:02Z

Cleaned up the commit history with the following additional diff, plus rebased.

diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 66f004356..d01d25bbc 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -2816,3 +2816,3 @@ pub(crate) const MAX_LOCAL_BREAKDOWN_TIMEOUT: u16 = 2 * 6 * 24 * 7;
/// The minimum number of blocks between an inbound HTLC's CLTV and the corresponding outbound
-/// HTLC's CLTV. The current default represents roughly seven hours of blocks at six blocks/hour.+/// HTLC's CLTV. The current default represents roughly eight hours of blocks at six blocks/hour.
///
@@ -2845,3 +2845,3 @@ pub const MIN_FINAL_CLTV_EXPIRY_DELTA: u16 = HTLC_FAIL_BACK_BUFFER as u16 + 3;
// force-close on us.
-// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our+// In other words, if the next-hop peer fails HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have

TheBlueMatt · 2025-02-18T13:44:17Z

In the process of #3340 I noticed a bunch of our confirmation target constants don't make sense anymore post-anchor (and one of our checks made no sense ever). So here we update them, taking this opportunity to also increase a few windows.

wpaulino

CI has a few test failures that need to be fixed

wpaulino · 2025-02-24T21:26:09Z

Feel free to squash

TheBlueMatt · 2025-02-24T21:40:06Z

Squashed without changes.

wpaulino · 2025-02-24T23:18:06Z

Needs rustfmt

TheBlueMatt · 2025-02-25T19:46:37Z

Grrr, done.

valentinewallace · 2025-03-04T21:12:43Z

+// in with enough time left to fail the corresponding HTLC back to our inbound edge before they
+// force-close on us.
+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have


s/after expiry/before expiry?

No after. We FC a channel several blocks after an HTLC expires.

valentinewallace · 2025-03-04T21:13:31Z

+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have
+// 2*MAX_BLOCKS_FOR_CONF + ANTI_REORG_DELAY left to get two transactions on chain and the second
+// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the


suggestion:
Suggested change
// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the
// fully locked in before the inbound peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the

That reads kinda confusing to me? Makes it sound like the channel was inbound from the peer, rather than the HTLC was relayed inbound from the peer?

valentinewallace · 2025-03-04T21:39:25Z

 /// If an HTLC expires within this many blocks, force-close the channel to broadcast the
 /// HTLC-Success transaction.


"HTLC-Success transaction" phrasing seems to suggest this const is only used in the context of channels with inbound HTLC(s) where we have the preimage. But it seems to be used for inbounds where we don't have the preimage as well, and/or other contexts? I wonder if this could be clarified?

Not directly? Its only used directly as !htlc_outbound && htlc.cltv_expiry <= height + CLTV_CLAIM_BUFFER && self.payment_preimages.contains_key(&htlc.payment_hash) and indirectly to calculate HTLC_FAIL_BACK_BUFFER which is the same concept.

The `CHECK_CLTV_EXPIRY_SANITY_2` check actually made no sense - its use of `2*CLTV_CLAIM_BUFFER` implicitly assumed that we were failing HTLCs `CLTV_CLAIM_BUFFER` after they expired, which is nonsense. Instead, we improve the readability of the docs on `_CHECK_CLTV_EXPIRY_SANITY` and add a new `_CHECK_CLTV_EXPIRY_OFFCHAIN` that correctly tests for what the `CHECK_CLTV_EXPIRY_SANITY_2` check was supposed to look at.

Over the years we've built up a few tests which rely on block count constants but without making direct references to those constants. Here we fix three such tests to ensure changing block count constants in the next commit do not break tests.

`test_duplicate_payment_hash_one_failure_one_success` makes a number of assumptions which rely on our specific CLTV constants, which we intend to change. Specifically, it relies on forwarding two HTLCs, one which goes one hop longer, and that it can close the channel with both HTLCs sitting on chain with enough time to claim that it doesn't give up on them but also that they get claimed in separate transactions. Here we clean up, simplify, and better document the test such that it is more resilient to future CLTV constant changes.

`CLTV_CLAIM_BUFFER`'s definition stated "this is an upper bound on how many blocks we think it can take us to get a transaction confirmed". This was mostly okay for pre-anchor channels, where we broadcasted HTLC claim transactions at the same time as the commitment transactions themselves, but for anchor channels we can no longer do that - HTLC transactions are always CSV 1'd. Further, when we do go to broadcast HTLC transactions, we start the feerate estimate for them back at the users' feerate estimator, rather than whatever feerate we ended up using to get the commitment transaction confirmed. While we should maybe consider changing that, for now that means that we really need to run the whole "get a transaction confirmed" process from start to finish *twice* in order to claim an HTLC. Thus, `CLTV_CLAIM_BUFFER` is here redefined to be two times "the upper bound on how many blocks we think it can take for us to get a transaction confirmed", with a new `MAX_BLOCKS_FOR_CONF` constant defining the expected max blocks.

In the previous commit it was observed that we actually have to run the whole "get a transaction confirmed" process from start to finish twice to claim an HTLC on an anchor channel. This leaves us with only 9 blocks to get each transaction confirmed, which is quite aggressive. Here we double this threshold, force-closing channels which have an expiring HTLC 36 blocks before expiry instead of 18. We also increase the minimum CLTV expiry delta to 48 to ensure we have at least a few blocks after the transactions get confirmed before we need to fail the inbound edge of a forwarded HTLC back. We do not change the default CLTV expiry delta of 72 blocks.

TheBlueMatt · 2025-03-05T19:23:02Z

Cleaned up the commit history with the following additional diff, plus rebased.

diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 66f004356..d01d25bbc 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -2816,3 +2816,3 @@ pub(crate) const MAX_LOCAL_BREAKDOWN_TIMEOUT: u16 = 2 * 6 * 24 * 7;
/// The minimum number of blocks between an inbound HTLC's CLTV and the corresponding outbound
-/// HTLC's CLTV. The current default represents roughly seven hours of blocks at six blocks/hour.+/// HTLC's CLTV. The current default represents roughly eight hours of blocks at six blocks/hour.
///
@@ -2845,3 +2845,3 @@ pub const MIN_FINAL_CLTV_EXPIRY_DELTA: u16 = HTLC_FAIL_BACK_BUFFER as u16 + 3;
// force-close on us.
-// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our+// In other words, if the next-hop peer fails HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have

TheBlueMatt · 2025-02-18T13:44:17Z

In the process of #3340 I noticed a bunch of our confirmation target constants don't make sense anymore post-anchor (and one of our checks made no sense ever). So here we update them, taking this opportunity to also increase a few windows.

wpaulino

CI has a few test failures that need to be fixed

wpaulino · 2025-02-24T21:26:09Z

Feel free to squash

TheBlueMatt · 2025-02-24T21:40:06Z

Squashed without changes.

wpaulino · 2025-02-24T23:18:06Z

Needs rustfmt

TheBlueMatt · 2025-02-25T19:46:37Z

Grrr, done.

valentinewallace · 2025-03-04T21:12:43Z

+// in with enough time left to fail the corresponding HTLC back to our inbound edge before they
+// force-close on us.
+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have


s/after expiry/before expiry?

No after. We FC a channel several blocks after an HTLC expires.

valentinewallace · 2025-03-04T21:13:31Z

+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have
+// 2*MAX_BLOCKS_FOR_CONF + ANTI_REORG_DELAY left to get two transactions on chain and the second
+// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the


suggestion:
Suggested change
// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the
// fully locked in before the inbound peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the

That reads kinda confusing to me? Makes it sound like the channel was inbound from the peer, rather than the HTLC was relayed inbound from the peer?

valentinewallace · 2025-03-04T21:39:25Z

 /// If an HTLC expires within this many blocks, force-close the channel to broadcast the
 /// HTLC-Success transaction.


"HTLC-Success transaction" phrasing seems to suggest this const is only used in the context of channels with inbound HTLC(s) where we have the preimage. But it seems to be used for inbounds where we don't have the preimage as well, and/or other contexts? I wonder if this could be clarified?

Not directly? Its only used directly as !htlc_outbound && htlc.cltv_expiry <= height + CLTV_CLAIM_BUFFER && self.payment_preimages.contains_key(&htlc.payment_hash) and indirectly to calculate HTLC_FAIL_BACK_BUFFER which is the same concept.

The `CHECK_CLTV_EXPIRY_SANITY_2` check actually made no sense - its use of `2*CLTV_CLAIM_BUFFER` implicitly assumed that we were failing HTLCs `CLTV_CLAIM_BUFFER` after they expired, which is nonsense. Instead, we improve the readability of the docs on `_CHECK_CLTV_EXPIRY_SANITY` and add a new `_CHECK_CLTV_EXPIRY_OFFCHAIN` that correctly tests for what the `CHECK_CLTV_EXPIRY_SANITY_2` check was supposed to look at.

Over the years we've built up a few tests which rely on block count constants but without making direct references to those constants. Here we fix three such tests to ensure changing block count constants in the next commit do not break tests.

`test_duplicate_payment_hash_one_failure_one_success` makes a number of assumptions which rely on our specific CLTV constants, which we intend to change. Specifically, it relies on forwarding two HTLCs, one which goes one hop longer, and that it can close the channel with both HTLCs sitting on chain with enough time to claim that it doesn't give up on them but also that they get claimed in separate transactions. Here we clean up, simplify, and better document the test such that it is more resilient to future CLTV constant changes.

`CLTV_CLAIM_BUFFER`'s definition stated "this is an upper bound on how many blocks we think it can take us to get a transaction confirmed". This was mostly okay for pre-anchor channels, where we broadcasted HTLC claim transactions at the same time as the commitment transactions themselves, but for anchor channels we can no longer do that - HTLC transactions are always CSV 1'd. Further, when we do go to broadcast HTLC transactions, we start the feerate estimate for them back at the users' feerate estimator, rather than whatever feerate we ended up using to get the commitment transaction confirmed. While we should maybe consider changing that, for now that means that we really need to run the whole "get a transaction confirmed" process from start to finish *twice* in order to claim an HTLC. Thus, `CLTV_CLAIM_BUFFER` is here redefined to be two times "the upper bound on how many blocks we think it can take for us to get a transaction confirmed", with a new `MAX_BLOCKS_FOR_CONF` constant defining the expected max blocks.

In the previous commit it was observed that we actually have to run the whole "get a transaction confirmed" process from start to finish twice to claim an HTLC on an anchor channel. This leaves us with only 9 blocks to get each transaction confirmed, which is quite aggressive. Here we double this threshold, force-closing channels which have an expiring HTLC 36 blocks before expiry instead of 18. We also increase the minimum CLTV expiry delta to 48 to ensure we have at least a few blocks after the transactions get confirmed before we need to fail the inbound edge of a forwarded HTLC back. We do not change the default CLTV expiry delta of 72 blocks.

TheBlueMatt · 2025-03-05T19:23:02Z

Cleaned up the commit history with the following additional diff, plus rebased.

diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 66f004356..d01d25bbc 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -2816,3 +2816,3 @@ pub(crate) const MAX_LOCAL_BREAKDOWN_TIMEOUT: u16 = 2 * 6 * 24 * 7;
/// The minimum number of blocks between an inbound HTLC's CLTV and the corresponding outbound
-/// HTLC's CLTV. The current default represents roughly seven hours of blocks at six blocks/hour.+/// HTLC's CLTV. The current default represents roughly eight hours of blocks at six blocks/hour.
///
@@ -2845,3 +2845,3 @@ pub const MIN_FINAL_CLTV_EXPIRY_DELTA: u16 = HTLC_FAIL_BACK_BUFFER as u16 + 3;
// force-close on us.
-// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our+// In other words, if the next-hop peer fails HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have

TheBlueMatt · 2025-02-18T13:44:17Z

In the process of #3340 I noticed a bunch of our confirmation target constants don't make sense anymore post-anchor (and one of our checks made no sense ever). So here we update them, taking this opportunity to also increase a few windows.

wpaulino

CI has a few test failures that need to be fixed

wpaulino · 2025-02-24T21:26:09Z

Feel free to squash

TheBlueMatt · 2025-02-24T21:40:06Z

Squashed without changes.

wpaulino · 2025-02-24T23:18:06Z

Needs rustfmt

TheBlueMatt · 2025-02-25T19:46:37Z

Grrr, done.

valentinewallace · 2025-03-04T21:12:43Z

+// in with enough time left to fail the corresponding HTLC back to our inbound edge before they
+// force-close on us.
+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have


s/after expiry/before expiry?

No after. We FC a channel several blocks after an HTLC expires.

valentinewallace · 2025-03-04T21:13:31Z

+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have
+// 2*MAX_BLOCKS_FOR_CONF + ANTI_REORG_DELAY left to get two transactions on chain and the second
+// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the


suggestion:
Suggested change
// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the
// fully locked in before the inbound peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the

That reads kinda confusing to me? Makes it sound like the channel was inbound from the peer, rather than the HTLC was relayed inbound from the peer?

valentinewallace · 2025-03-04T21:39:25Z

 /// If an HTLC expires within this many blocks, force-close the channel to broadcast the
 /// HTLC-Success transaction.


"HTLC-Success transaction" phrasing seems to suggest this const is only used in the context of channels with inbound HTLC(s) where we have the preimage. But it seems to be used for inbounds where we don't have the preimage as well, and/or other contexts? I wonder if this could be clarified?

Not directly? Its only used directly as !htlc_outbound && htlc.cltv_expiry <= height + CLTV_CLAIM_BUFFER && self.payment_preimages.contains_key(&htlc.payment_hash) and indirectly to calculate HTLC_FAIL_BACK_BUFFER which is the same concept.

The `CHECK_CLTV_EXPIRY_SANITY_2` check actually made no sense - its use of `2*CLTV_CLAIM_BUFFER` implicitly assumed that we were failing HTLCs `CLTV_CLAIM_BUFFER` after they expired, which is nonsense. Instead, we improve the readability of the docs on `_CHECK_CLTV_EXPIRY_SANITY` and add a new `_CHECK_CLTV_EXPIRY_OFFCHAIN` that correctly tests for what the `CHECK_CLTV_EXPIRY_SANITY_2` check was supposed to look at.

Over the years we've built up a few tests which rely on block count constants but without making direct references to those constants. Here we fix three such tests to ensure changing block count constants in the next commit do not break tests.

`test_duplicate_payment_hash_one_failure_one_success` makes a number of assumptions which rely on our specific CLTV constants, which we intend to change. Specifically, it relies on forwarding two HTLCs, one which goes one hop longer, and that it can close the channel with both HTLCs sitting on chain with enough time to claim that it doesn't give up on them but also that they get claimed in separate transactions. Here we clean up, simplify, and better document the test such that it is more resilient to future CLTV constant changes.

`CLTV_CLAIM_BUFFER`'s definition stated "this is an upper bound on how many blocks we think it can take us to get a transaction confirmed". This was mostly okay for pre-anchor channels, where we broadcasted HTLC claim transactions at the same time as the commitment transactions themselves, but for anchor channels we can no longer do that - HTLC transactions are always CSV 1'd. Further, when we do go to broadcast HTLC transactions, we start the feerate estimate for them back at the users' feerate estimator, rather than whatever feerate we ended up using to get the commitment transaction confirmed. While we should maybe consider changing that, for now that means that we really need to run the whole "get a transaction confirmed" process from start to finish *twice* in order to claim an HTLC. Thus, `CLTV_CLAIM_BUFFER` is here redefined to be two times "the upper bound on how many blocks we think it can take for us to get a transaction confirmed", with a new `MAX_BLOCKS_FOR_CONF` constant defining the expected max blocks.

In the previous commit it was observed that we actually have to run the whole "get a transaction confirmed" process from start to finish twice to claim an HTLC on an anchor channel. This leaves us with only 9 blocks to get each transaction confirmed, which is quite aggressive. Here we double this threshold, force-closing channels which have an expiring HTLC 36 blocks before expiry instead of 18. We also increase the minimum CLTV expiry delta to 48 to ensure we have at least a few blocks after the transactions get confirmed before we need to fail the inbound edge of a forwarded HTLC back. We do not change the default CLTV expiry delta of 72 blocks.

TheBlueMatt · 2025-03-05T19:23:02Z

Cleaned up the commit history with the following additional diff, plus rebased.

diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 66f004356..d01d25bbc 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -2816,3 +2816,3 @@ pub(crate) const MAX_LOCAL_BREAKDOWN_TIMEOUT: u16 = 2 * 6 * 24 * 7;
/// The minimum number of blocks between an inbound HTLC's CLTV and the corresponding outbound
-/// HTLC's CLTV. The current default represents roughly seven hours of blocks at six blocks/hour.+/// HTLC's CLTV. The current default represents roughly eight hours of blocks at six blocks/hour.
///
@@ -2845,3 +2845,3 @@ pub const MIN_FINAL_CLTV_EXPIRY_DELTA: u16 = HTLC_FAIL_BACK_BUFFER as u16 + 3;
// force-close on us.
-// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our+// In other words, if the next-hop peer fails HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have

TheBlueMatt · 2025-02-18T13:44:17Z

In the process of #3340 I noticed a bunch of our confirmation target constants don't make sense anymore post-anchor (and one of our checks made no sense ever). So here we update them, taking this opportunity to also increase a few windows.

wpaulino

CI has a few test failures that need to be fixed

wpaulino · 2025-02-24T21:26:09Z

Feel free to squash

TheBlueMatt · 2025-02-24T21:40:06Z

Squashed without changes.

wpaulino · 2025-02-24T23:18:06Z

Needs rustfmt

TheBlueMatt · 2025-02-25T19:46:37Z

Grrr, done.

valentinewallace · 2025-03-04T21:12:43Z

+// in with enough time left to fail the corresponding HTLC back to our inbound edge before they
+// force-close on us.
+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have


s/after expiry/before expiry?

No after. We FC a channel several blocks after an HTLC expires.

valentinewallace · 2025-03-04T21:13:31Z

+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have
+// 2*MAX_BLOCKS_FOR_CONF + ANTI_REORG_DELAY left to get two transactions on chain and the second
+// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the


suggestion:
Suggested change
// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the
// fully locked in before the inbound peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the

That reads kinda confusing to me? Makes it sound like the channel was inbound from the peer, rather than the HTLC was relayed inbound from the peer?

valentinewallace · 2025-03-04T21:39:25Z

 /// If an HTLC expires within this many blocks, force-close the channel to broadcast the
 /// HTLC-Success transaction.


"HTLC-Success transaction" phrasing seems to suggest this const is only used in the context of channels with inbound HTLC(s) where we have the preimage. But it seems to be used for inbounds where we don't have the preimage as well, and/or other contexts? I wonder if this could be clarified?

Not directly? Its only used directly as !htlc_outbound && htlc.cltv_expiry <= height + CLTV_CLAIM_BUFFER && self.payment_preimages.contains_key(&htlc.payment_hash) and indirectly to calculate HTLC_FAIL_BACK_BUFFER which is the same concept.

The `CHECK_CLTV_EXPIRY_SANITY_2` check actually made no sense - its use of `2*CLTV_CLAIM_BUFFER` implicitly assumed that we were failing HTLCs `CLTV_CLAIM_BUFFER` after they expired, which is nonsense. Instead, we improve the readability of the docs on `_CHECK_CLTV_EXPIRY_SANITY` and add a new `_CHECK_CLTV_EXPIRY_OFFCHAIN` that correctly tests for what the `CHECK_CLTV_EXPIRY_SANITY_2` check was supposed to look at.

Over the years we've built up a few tests which rely on block count constants but without making direct references to those constants. Here we fix three such tests to ensure changing block count constants in the next commit do not break tests.

`test_duplicate_payment_hash_one_failure_one_success` makes a number of assumptions which rely on our specific CLTV constants, which we intend to change. Specifically, it relies on forwarding two HTLCs, one which goes one hop longer, and that it can close the channel with both HTLCs sitting on chain with enough time to claim that it doesn't give up on them but also that they get claimed in separate transactions. Here we clean up, simplify, and better document the test such that it is more resilient to future CLTV constant changes.

`CLTV_CLAIM_BUFFER`'s definition stated "this is an upper bound on how many blocks we think it can take us to get a transaction confirmed". This was mostly okay for pre-anchor channels, where we broadcasted HTLC claim transactions at the same time as the commitment transactions themselves, but for anchor channels we can no longer do that - HTLC transactions are always CSV 1'd. Further, when we do go to broadcast HTLC transactions, we start the feerate estimate for them back at the users' feerate estimator, rather than whatever feerate we ended up using to get the commitment transaction confirmed. While we should maybe consider changing that, for now that means that we really need to run the whole "get a transaction confirmed" process from start to finish *twice* in order to claim an HTLC. Thus, `CLTV_CLAIM_BUFFER` is here redefined to be two times "the upper bound on how many blocks we think it can take for us to get a transaction confirmed", with a new `MAX_BLOCKS_FOR_CONF` constant defining the expected max blocks.

In the previous commit it was observed that we actually have to run the whole "get a transaction confirmed" process from start to finish twice to claim an HTLC on an anchor channel. This leaves us with only 9 blocks to get each transaction confirmed, which is quite aggressive. Here we double this threshold, force-closing channels which have an expiring HTLC 36 blocks before expiry instead of 18. We also increase the minimum CLTV expiry delta to 48 to ensure we have at least a few blocks after the transactions get confirmed before we need to fail the inbound edge of a forwarded HTLC back. We do not change the default CLTV expiry delta of 72 blocks.

TheBlueMatt · 2025-03-05T19:23:02Z

Cleaned up the commit history with the following additional diff, plus rebased.

diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 66f004356..d01d25bbc 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -2816,3 +2816,3 @@ pub(crate) const MAX_LOCAL_BREAKDOWN_TIMEOUT: u16 = 2 * 6 * 24 * 7;
/// The minimum number of blocks between an inbound HTLC's CLTV and the corresponding outbound
-/// HTLC's CLTV. The current default represents roughly seven hours of blocks at six blocks/hour.+/// HTLC's CLTV. The current default represents roughly eight hours of blocks at six blocks/hour.
///
@@ -2845,3 +2845,3 @@ pub const MIN_FINAL_CLTV_EXPIRY_DELTA: u16 = HTLC_FAIL_BACK_BUFFER as u16 + 3;
// force-close on us.
-// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our+// In other words, if the next-hop peer fails HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have

TheBlueMatt · 2025-02-18T13:44:17Z

In the process of #3340 I noticed a bunch of our confirmation target constants don't make sense anymore post-anchor (and one of our checks made no sense ever). So here we update them, taking this opportunity to also increase a few windows.

wpaulino

CI has a few test failures that need to be fixed

wpaulino · 2025-02-24T21:26:09Z

Feel free to squash

TheBlueMatt · 2025-02-24T21:40:06Z

Squashed without changes.

wpaulino · 2025-02-24T23:18:06Z

Needs rustfmt

TheBlueMatt · 2025-02-25T19:46:37Z

Grrr, done.

valentinewallace · 2025-03-04T21:12:43Z

+// in with enough time left to fail the corresponding HTLC back to our inbound edge before they
+// force-close on us.
+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have


s/after expiry/before expiry?

No after. We FC a channel several blocks after an HTLC expires.

valentinewallace · 2025-03-04T21:13:31Z

+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have
+// 2*MAX_BLOCKS_FOR_CONF + ANTI_REORG_DELAY left to get two transactions on chain and the second
+// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the


suggestion:
Suggested change
// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the
// fully locked in before the inbound peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the

That reads kinda confusing to me? Makes it sound like the channel was inbound from the peer, rather than the HTLC was relayed inbound from the peer?

valentinewallace · 2025-03-04T21:39:25Z

 /// If an HTLC expires within this many blocks, force-close the channel to broadcast the
 /// HTLC-Success transaction.


"HTLC-Success transaction" phrasing seems to suggest this const is only used in the context of channels with inbound HTLC(s) where we have the preimage. But it seems to be used for inbounds where we don't have the preimage as well, and/or other contexts? I wonder if this could be clarified?

Not directly? Its only used directly as !htlc_outbound && htlc.cltv_expiry <= height + CLTV_CLAIM_BUFFER && self.payment_preimages.contains_key(&htlc.payment_hash) and indirectly to calculate HTLC_FAIL_BACK_BUFFER which is the same concept.

The `CHECK_CLTV_EXPIRY_SANITY_2` check actually made no sense - its use of `2*CLTV_CLAIM_BUFFER` implicitly assumed that we were failing HTLCs `CLTV_CLAIM_BUFFER` after they expired, which is nonsense. Instead, we improve the readability of the docs on `_CHECK_CLTV_EXPIRY_SANITY` and add a new `_CHECK_CLTV_EXPIRY_OFFCHAIN` that correctly tests for what the `CHECK_CLTV_EXPIRY_SANITY_2` check was supposed to look at.

Over the years we've built up a few tests which rely on block count constants but without making direct references to those constants. Here we fix three such tests to ensure changing block count constants in the next commit do not break tests.

`test_duplicate_payment_hash_one_failure_one_success` makes a number of assumptions which rely on our specific CLTV constants, which we intend to change. Specifically, it relies on forwarding two HTLCs, one which goes one hop longer, and that it can close the channel with both HTLCs sitting on chain with enough time to claim that it doesn't give up on them but also that they get claimed in separate transactions. Here we clean up, simplify, and better document the test such that it is more resilient to future CLTV constant changes.

`CLTV_CLAIM_BUFFER`'s definition stated "this is an upper bound on how many blocks we think it can take us to get a transaction confirmed". This was mostly okay for pre-anchor channels, where we broadcasted HTLC claim transactions at the same time as the commitment transactions themselves, but for anchor channels we can no longer do that - HTLC transactions are always CSV 1'd. Further, when we do go to broadcast HTLC transactions, we start the feerate estimate for them back at the users' feerate estimator, rather than whatever feerate we ended up using to get the commitment transaction confirmed. While we should maybe consider changing that, for now that means that we really need to run the whole "get a transaction confirmed" process from start to finish *twice* in order to claim an HTLC. Thus, `CLTV_CLAIM_BUFFER` is here redefined to be two times "the upper bound on how many blocks we think it can take for us to get a transaction confirmed", with a new `MAX_BLOCKS_FOR_CONF` constant defining the expected max blocks.

In the previous commit it was observed that we actually have to run the whole "get a transaction confirmed" process from start to finish twice to claim an HTLC on an anchor channel. This leaves us with only 9 blocks to get each transaction confirmed, which is quite aggressive. Here we double this threshold, force-closing channels which have an expiring HTLC 36 blocks before expiry instead of 18. We also increase the minimum CLTV expiry delta to 48 to ensure we have at least a few blocks after the transactions get confirmed before we need to fail the inbound edge of a forwarded HTLC back. We do not change the default CLTV expiry delta of 72 blocks.

TheBlueMatt · 2025-03-05T19:23:02Z

Cleaned up the commit history with the following additional diff, plus rebased.

diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 66f004356..d01d25bbc 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -2816,3 +2816,3 @@ pub(crate) const MAX_LOCAL_BREAKDOWN_TIMEOUT: u16 = 2 * 6 * 24 * 7;
/// The minimum number of blocks between an inbound HTLC's CLTV and the corresponding outbound
-/// HTLC's CLTV. The current default represents roughly seven hours of blocks at six blocks/hour.+/// HTLC's CLTV. The current default represents roughly eight hours of blocks at six blocks/hour.
///
@@ -2845,3 +2845,3 @@ pub const MIN_FINAL_CLTV_EXPIRY_DELTA: u16 = HTLC_FAIL_BACK_BUFFER as u16 + 3;
// force-close on us.
-// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our+// In other words, if the next-hop peer fails HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
// CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have

wpaulino reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/functional_tests.rs Outdated
Comment threadlightning/src/ln/functional_tests.rs Outdated

TheBlueMatt force-pushed the 2025-02-better-block-constants branch 2 times, most recently from 5314c7d to dac2cc2Compare February 24, 2025 20:29

TheBlueMatt force-pushed the 2025-02-better-block-constants branch from dac2cc2 to 84ce4f0Compare February 24, 2025 21:40

TheBlueMatt force-pushed the 2025-02-better-block-constants branch from 84ce4f0 to 7fb9ba1Compare February 25, 2025 19:46

wpaulino previously approved these changes Feb 25, 2025
View reviewed changes

ldk-reviews-bot requested a review from arik-so March 4, 2025 13:43

TheBlueMatt removed the request for review from arik-so March 4, 2025 13:44

ldk-reviews-bot requested a review from valentinewallace March 4, 2025 13:45

valentinewallace reviewed Mar 4, 2025
View reviewed changes

TheBlueMatt dismissed wpaulino’s stale review via d078b10March 5, 2025 19:22

TheBlueMatt force-pushed the 2025-02-better-block-constants branch from 7fb9ba1 to d078b10Compare March 5, 2025 19:22

TheBlueMatt added 4 commits March 5, 2025 19:22

TheBlueMatt force-pushed the 2025-02-better-block-constants branch from d078b10 to e7c2a61Compare March 5, 2025 19:23

valentinewallace approved these changes Mar 5, 2025
View reviewed changes

wpaulino approved these changes Mar 5, 2025
View reviewed changes

TheBlueMatt merged commit 071aa85 into lightningdevkit:mainMar 6, 2025

tnull mentioned this pull request Apr 6, 2026
CLN-to-LDK keysend is broken due to incompatible min_final_cltv_expiryElementsProject/lightning#9034
Closed