Locktimed packages fixes by TheBlueMatt · Pull Request #3923 · lightningdevkit/rust-lightning

TheBlueMatt · 2025-07-10T18:16:02Z

See individual commits for more. This is #3860 with an additional issue I found while writing a test for it fixed.

In a number of tests we require available UTXOs to do HTLC anchor claims by bringing our own fees. We previously wrote that out in each test, which is somewhat verbose, so here we simply add a test utility that gives each node a full BTC in a single UTXO.

We have to prune locktimed packages when their inputs are spent, otherwise the notification of the watched outputs might be missed. This can lead to locktimed packages with spent inputs being added back to the pending claim requests in the future, and they are never cleaned up until node restart. Resolves: lightningdevkit#3859

ldk-reviews-bot · 2025-07-10T18:16:05Z

👋 Thanks for assigning @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

When we have an outpoint to claim which is lock-timed and the locktime is reached, we add it to `OnchainTxHandler::claimable_outpoints` to indicate the outpoint is now being claimed. However, `claimable_outpoints` is supposed to track when the outpoint first appeared on chain so that we can remove the claim if the outpoint is reorged out. Sadly, in the handling for lock-timed packages, we incorrectly stored the current height in `claimable_outpoints`, causing such claims to be removed in case of a reorg right after they were generated, even if the output we intend to claim isn't removed at all. Here we start tracking when the outpoint we're spending was created in `PackageSolvingData`'s constituent types. While we could have tracked this information in `PackageTemplate`, it would preclude later merging packages that are spending outpoints included in different blocks, which we don't necessarily want to do.

When we have an outpoint to claim which is lock-timed and the locktime is reached, we add it to `OnchainTxHandler::claimable_outpoints` to indicate the outpoint is now being claimed. However, `claimable_outpoints` is supposed to track when the outpoint first appeared on chain so that we can remove the claim if the outpoint is reorged out. Sadly, in the handling for lock-timed packages, we incorrectly stored the current height in `claimable_outpoints`, causing such claims to be removed in case of a reorg right after they were generated, even if the output we intend to claim isn't removed at all. Here we use the creation-height tracking added in the previous commit to actually address the issue, using the tracked height when adding a claim to `OnchainTxHandler::claimable_outpoints`. In cases where we have no information, we continue to use the current height, retaining the issue for locktimed packages on upgrades, but this simplifies cases where we actually don't have the information available anyway.

wpaulino · 2025-07-11T00:17:54Z

+ for (k, outpoint_confirmation_height) in req.outpoints_and_creation_heights() {
+ let creation_height = outpoint_confirmation_height.unwrap_or(conf_height);
+ log_info!(logger, "Registering claiming request for {}:{}, which exists as of height {creation_height}", k.txid, k.vout);
+ self.claimable_outpoints.insert(k.clone(), (claim_id, creation_height));


Hm, shouldn't we prefer signed_locktime over creation_height for outpoints that have one though? While the outpoint hasn't been reorged out, claiming it is no longer possible once the block at signed_locktime is disconnected.

In practice I think this would just result in us broadcasting things that cannot enter the mempool until we get back to the expected height. If we have any other claims that were merged into the same package for whatever reason, and they are still valid at the disconnected block height, then this would be a greater issue.

The problem is that when things time out via claimable_outpoints, we don't stop claiming them, we remove them. We don't get them back after a reorg at that point. We could move to pushing things into the locked-packages vec after a block-disconnect, but that seems like a bigger change?

ldk-reviews-bot · 2025-07-11T00:24:09Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

ldk-reviews-bot · 2025-07-14T00:01:05Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

This adds a single test which exercises both the ability to prune locktimed packages when inputs are spent as well as the creation-height tracking for locktimed packages.

TheBlueMatt · 2025-07-14T12:55:46Z

Cleaned up and improved the test slightly:

$ git diff-tree -U2 21be9c5ed d7726eff0
diff --git a/lightning/src/ln/reorg_tests.rs b/lightning/src/ln/reorg_tests.rs
index 6faabac4c0..c5f512b319 100644
--- a/lightning/src/ln/reorg_tests.rs+++ b/lightning/src/ln/reorg_tests.rs@@ -13,5 +13,5 @@
use crate::chain::chaininterface::LowerBoundedFeeEstimator;
-use crate::chain::channelmonitor::{ANTI_REORG_DELAY, LATENCY_GRACE_PERIOD_BLOCKS};+use crate::chain::channelmonitor::{ANTI_REORG_DELAY, Balance, LATENCY_GRACE_PERIOD_BLOCKS};
use crate::chain::transaction::OutPoint;
use crate::chain::Confirm;
@@ -1058,12 +1058,19 @@ fn do_test_split_htlc_expiry_tracking(use_third_htlc: bool, reorg_out: bool) {
if reorg_out {
- // Reorg out bs_htlc_spend_tx, letting node A the claim all the HTLCs instead.+ // Reorg out bs_htlc_spend_tx, letting node A claim all the HTLCs instead.
disconnect_blocks(&nodes[0], ANTI_REORG_DELAY - 2);
assert_eq!(nodes[0].tx_broadcaster.txn_broadcast().len(), 0);
- // As soon as bs_htlc_spend_tx is disconnected+ // As soon as bs_htlc_spend_tx is disconnected, node A should consider all HTLCs+ // claimable-on-timeout.
disconnect_blocks(&nodes[0], 1);
let balances = nodes[0].chain_monitor.chain_monitor.get_claimable_balances(&[]);
assert_eq!(balances.len(), if use_third_htlc { 3 } else { 2 });
+ for balance in balances {+ if let Balance::MaybeTimeoutClaimableHTLC { .. } = balance {+ } else {+ panic!("Unexpected balance {balance:?}");+ }+ }
connect_blocks(&nodes[0], 100);

TheBlueMatt · 2025-07-15T17:55:47Z

Backported in #3932

v0.1.5 - Jul 16, 2025 - "Async Path Reduction" Performance Improvements ======================== * `NetworkGraph`'s expensive internal consistency checks have now been disabled in debug builds in addition to release builds (lightningdevkit#3687). Bug Fixes ========= * Pathfinding which results in a multi-path payment is now substantially smarter, using fewer paths and better optimizing fees and successes (lightningdevkit#3890). * A counterparty delaying claiming multiple HTLCs with different expiries can no longer cause our `ChannelMonitor` to continuously rebroadcast invalid transactions or RBF bump attempts (lightningdevkit#3923). * Reorgs can no longer cause us to fail to claim HTLCs after a counterparty delayed claiming multiple HTLCs with different expiries (lightningdevkit#3923). * Force-closing a channel while it is blocked on another channel's async `ChannelMonitorUpdate` can no longer lead to a panic (lightningdevkit#3858). * `ChannelMonitorUpdate`s can no longer be released to storage too early when doing async updates or on restart. This only impacts async `ChannelMonitorUpdate` persistence and can lead to loss of funds only in rare cases with `ChannelMonitorUpdate` persistence order inversions (lightningdevkit#3907). Security ======== 0.1.5 fixes a vulnerability which could allow a peer to overdraw their reserve value, potentially cutting into commitment transaction fees on channels with a low reserve. * Due to a bug in checking whether an HTLC is dust during acceptance, near-dust HTLCs were not counted towards the commitment transaction fee, but did eventually contribute to it when we built a commitment transaction. This can be used by a counterparty to overdraw their reserve value, or, for channels with a low reserve value, cut into the commitment transaction fee (lightningdevkit#3933).

TheBlueMatt · 2025-07-10T18:16:02Z

See individual commits for more. This is #3860 with an additional issue I found while writing a test for it fixed.

In a number of tests we require available UTXOs to do HTLC anchor claims by bringing our own fees. We previously wrote that out in each test, which is somewhat verbose, so here we simply add a test utility that gives each node a full BTC in a single UTXO.

We have to prune locktimed packages when their inputs are spent, otherwise the notification of the watched outputs might be missed. This can lead to locktimed packages with spent inputs being added back to the pending claim requests in the future, and they are never cleaned up until node restart. Resolves: lightningdevkit#3859

ldk-reviews-bot · 2025-07-10T18:16:05Z

👋 Thanks for assigning @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

When we have an outpoint to claim which is lock-timed and the locktime is reached, we add it to `OnchainTxHandler::claimable_outpoints` to indicate the outpoint is now being claimed. However, `claimable_outpoints` is supposed to track when the outpoint first appeared on chain so that we can remove the claim if the outpoint is reorged out. Sadly, in the handling for lock-timed packages, we incorrectly stored the current height in `claimable_outpoints`, causing such claims to be removed in case of a reorg right after they were generated, even if the output we intend to claim isn't removed at all. Here we start tracking when the outpoint we're spending was created in `PackageSolvingData`'s constituent types. While we could have tracked this information in `PackageTemplate`, it would preclude later merging packages that are spending outpoints included in different blocks, which we don't necessarily want to do.

When we have an outpoint to claim which is lock-timed and the locktime is reached, we add it to `OnchainTxHandler::claimable_outpoints` to indicate the outpoint is now being claimed. However, `claimable_outpoints` is supposed to track when the outpoint first appeared on chain so that we can remove the claim if the outpoint is reorged out. Sadly, in the handling for lock-timed packages, we incorrectly stored the current height in `claimable_outpoints`, causing such claims to be removed in case of a reorg right after they were generated, even if the output we intend to claim isn't removed at all. Here we use the creation-height tracking added in the previous commit to actually address the issue, using the tracked height when adding a claim to `OnchainTxHandler::claimable_outpoints`. In cases where we have no information, we continue to use the current height, retaining the issue for locktimed packages on upgrades, but this simplifies cases where we actually don't have the information available anyway.

wpaulino · 2025-07-11T00:17:54Z

+ for (k, outpoint_confirmation_height) in req.outpoints_and_creation_heights() {
+ let creation_height = outpoint_confirmation_height.unwrap_or(conf_height);
+ log_info!(logger, "Registering claiming request for {}:{}, which exists as of height {creation_height}", k.txid, k.vout);
+ self.claimable_outpoints.insert(k.clone(), (claim_id, creation_height));


Hm, shouldn't we prefer signed_locktime over creation_height for outpoints that have one though? While the outpoint hasn't been reorged out, claiming it is no longer possible once the block at signed_locktime is disconnected.

In practice I think this would just result in us broadcasting things that cannot enter the mempool until we get back to the expected height. If we have any other claims that were merged into the same package for whatever reason, and they are still valid at the disconnected block height, then this would be a greater issue.

The problem is that when things time out via claimable_outpoints, we don't stop claiming them, we remove them. We don't get them back after a reorg at that point. We could move to pushing things into the locked-packages vec after a block-disconnect, but that seems like a bigger change?

ldk-reviews-bot · 2025-07-11T00:24:09Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

ldk-reviews-bot · 2025-07-14T00:01:05Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

This adds a single test which exercises both the ability to prune locktimed packages when inputs are spent as well as the creation-height tracking for locktimed packages.

TheBlueMatt · 2025-07-14T12:55:46Z

Cleaned up and improved the test slightly:

$ git diff-tree -U2 21be9c5ed d7726eff0
diff --git a/lightning/src/ln/reorg_tests.rs b/lightning/src/ln/reorg_tests.rs
index 6faabac4c0..c5f512b319 100644
--- a/lightning/src/ln/reorg_tests.rs+++ b/lightning/src/ln/reorg_tests.rs@@ -13,5 +13,5 @@
use crate::chain::chaininterface::LowerBoundedFeeEstimator;
-use crate::chain::channelmonitor::{ANTI_REORG_DELAY, LATENCY_GRACE_PERIOD_BLOCKS};+use crate::chain::channelmonitor::{ANTI_REORG_DELAY, Balance, LATENCY_GRACE_PERIOD_BLOCKS};
use crate::chain::transaction::OutPoint;
use crate::chain::Confirm;
@@ -1058,12 +1058,19 @@ fn do_test_split_htlc_expiry_tracking(use_third_htlc: bool, reorg_out: bool) {
if reorg_out {
- // Reorg out bs_htlc_spend_tx, letting node A the claim all the HTLCs instead.+ // Reorg out bs_htlc_spend_tx, letting node A claim all the HTLCs instead.
disconnect_blocks(&nodes[0], ANTI_REORG_DELAY - 2);
assert_eq!(nodes[0].tx_broadcaster.txn_broadcast().len(), 0);
- // As soon as bs_htlc_spend_tx is disconnected+ // As soon as bs_htlc_spend_tx is disconnected, node A should consider all HTLCs+ // claimable-on-timeout.
disconnect_blocks(&nodes[0], 1);
let balances = nodes[0].chain_monitor.chain_monitor.get_claimable_balances(&[]);
assert_eq!(balances.len(), if use_third_htlc { 3 } else { 2 });
+ for balance in balances {+ if let Balance::MaybeTimeoutClaimableHTLC { .. } = balance {+ } else {+ panic!("Unexpected balance {balance:?}");+ }+ }
connect_blocks(&nodes[0], 100);

TheBlueMatt · 2025-07-15T17:55:47Z

Backported in #3932

v0.1.5 - Jul 16, 2025 - "Async Path Reduction" Performance Improvements ======================== * `NetworkGraph`'s expensive internal consistency checks have now been disabled in debug builds in addition to release builds (lightningdevkit#3687). Bug Fixes ========= * Pathfinding which results in a multi-path payment is now substantially smarter, using fewer paths and better optimizing fees and successes (lightningdevkit#3890). * A counterparty delaying claiming multiple HTLCs with different expiries can no longer cause our `ChannelMonitor` to continuously rebroadcast invalid transactions or RBF bump attempts (lightningdevkit#3923). * Reorgs can no longer cause us to fail to claim HTLCs after a counterparty delayed claiming multiple HTLCs with different expiries (lightningdevkit#3923). * Force-closing a channel while it is blocked on another channel's async `ChannelMonitorUpdate` can no longer lead to a panic (lightningdevkit#3858). * `ChannelMonitorUpdate`s can no longer be released to storage too early when doing async updates or on restart. This only impacts async `ChannelMonitorUpdate` persistence and can lead to loss of funds only in rare cases with `ChannelMonitorUpdate` persistence order inversions (lightningdevkit#3907). Security ======== 0.1.5 fixes a vulnerability which could allow a peer to overdraw their reserve value, potentially cutting into commitment transaction fees on channels with a low reserve. * Due to a bug in checking whether an HTLC is dust during acceptance, near-dust HTLCs were not counted towards the commitment transaction fee, but did eventually contribute to it when we built a commitment transaction. This can be used by a counterparty to overdraw their reserve value, or, for channels with a low reserve value, cut into the commitment transaction fee (lightningdevkit#3933).

TheBlueMatt · 2025-07-10T18:16:02Z

See individual commits for more. This is #3860 with an additional issue I found while writing a test for it fixed.

In a number of tests we require available UTXOs to do HTLC anchor claims by bringing our own fees. We previously wrote that out in each test, which is somewhat verbose, so here we simply add a test utility that gives each node a full BTC in a single UTXO.

We have to prune locktimed packages when their inputs are spent, otherwise the notification of the watched outputs might be missed. This can lead to locktimed packages with spent inputs being added back to the pending claim requests in the future, and they are never cleaned up until node restart. Resolves: lightningdevkit#3859

ldk-reviews-bot · 2025-07-10T18:16:05Z

👋 Thanks for assigning @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

When we have an outpoint to claim which is lock-timed and the locktime is reached, we add it to `OnchainTxHandler::claimable_outpoints` to indicate the outpoint is now being claimed. However, `claimable_outpoints` is supposed to track when the outpoint first appeared on chain so that we can remove the claim if the outpoint is reorged out. Sadly, in the handling for lock-timed packages, we incorrectly stored the current height in `claimable_outpoints`, causing such claims to be removed in case of a reorg right after they were generated, even if the output we intend to claim isn't removed at all. Here we start tracking when the outpoint we're spending was created in `PackageSolvingData`'s constituent types. While we could have tracked this information in `PackageTemplate`, it would preclude later merging packages that are spending outpoints included in different blocks, which we don't necessarily want to do.

When we have an outpoint to claim which is lock-timed and the locktime is reached, we add it to `OnchainTxHandler::claimable_outpoints` to indicate the outpoint is now being claimed. However, `claimable_outpoints` is supposed to track when the outpoint first appeared on chain so that we can remove the claim if the outpoint is reorged out. Sadly, in the handling for lock-timed packages, we incorrectly stored the current height in `claimable_outpoints`, causing such claims to be removed in case of a reorg right after they were generated, even if the output we intend to claim isn't removed at all. Here we use the creation-height tracking added in the previous commit to actually address the issue, using the tracked height when adding a claim to `OnchainTxHandler::claimable_outpoints`. In cases where we have no information, we continue to use the current height, retaining the issue for locktimed packages on upgrades, but this simplifies cases where we actually don't have the information available anyway.

wpaulino · 2025-07-11T00:17:54Z

+ for (k, outpoint_confirmation_height) in req.outpoints_and_creation_heights() {
+ let creation_height = outpoint_confirmation_height.unwrap_or(conf_height);
+ log_info!(logger, "Registering claiming request for {}:{}, which exists as of height {creation_height}", k.txid, k.vout);
+ self.claimable_outpoints.insert(k.clone(), (claim_id, creation_height));


Hm, shouldn't we prefer signed_locktime over creation_height for outpoints that have one though? While the outpoint hasn't been reorged out, claiming it is no longer possible once the block at signed_locktime is disconnected.

In practice I think this would just result in us broadcasting things that cannot enter the mempool until we get back to the expected height. If we have any other claims that were merged into the same package for whatever reason, and they are still valid at the disconnected block height, then this would be a greater issue.

The problem is that when things time out via claimable_outpoints, we don't stop claiming them, we remove them. We don't get them back after a reorg at that point. We could move to pushing things into the locked-packages vec after a block-disconnect, but that seems like a bigger change?

ldk-reviews-bot · 2025-07-11T00:24:09Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

ldk-reviews-bot · 2025-07-14T00:01:05Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

This adds a single test which exercises both the ability to prune locktimed packages when inputs are spent as well as the creation-height tracking for locktimed packages.

TheBlueMatt · 2025-07-14T12:55:46Z

Cleaned up and improved the test slightly:

$ git diff-tree -U2 21be9c5ed d7726eff0
diff --git a/lightning/src/ln/reorg_tests.rs b/lightning/src/ln/reorg_tests.rs
index 6faabac4c0..c5f512b319 100644
--- a/lightning/src/ln/reorg_tests.rs+++ b/lightning/src/ln/reorg_tests.rs@@ -13,5 +13,5 @@
use crate::chain::chaininterface::LowerBoundedFeeEstimator;
-use crate::chain::channelmonitor::{ANTI_REORG_DELAY, LATENCY_GRACE_PERIOD_BLOCKS};+use crate::chain::channelmonitor::{ANTI_REORG_DELAY, Balance, LATENCY_GRACE_PERIOD_BLOCKS};
use crate::chain::transaction::OutPoint;
use crate::chain::Confirm;
@@ -1058,12 +1058,19 @@ fn do_test_split_htlc_expiry_tracking(use_third_htlc: bool, reorg_out: bool) {
if reorg_out {
- // Reorg out bs_htlc_spend_tx, letting node A the claim all the HTLCs instead.+ // Reorg out bs_htlc_spend_tx, letting node A claim all the HTLCs instead.
disconnect_blocks(&nodes[0], ANTI_REORG_DELAY - 2);
assert_eq!(nodes[0].tx_broadcaster.txn_broadcast().len(), 0);
- // As soon as bs_htlc_spend_tx is disconnected+ // As soon as bs_htlc_spend_tx is disconnected, node A should consider all HTLCs+ // claimable-on-timeout.
disconnect_blocks(&nodes[0], 1);
let balances = nodes[0].chain_monitor.chain_monitor.get_claimable_balances(&[]);
assert_eq!(balances.len(), if use_third_htlc { 3 } else { 2 });
+ for balance in balances {+ if let Balance::MaybeTimeoutClaimableHTLC { .. } = balance {+ } else {+ panic!("Unexpected balance {balance:?}");+ }+ }
connect_blocks(&nodes[0], 100);

TheBlueMatt · 2025-07-15T17:55:47Z

Backported in #3932

v0.1.5 - Jul 16, 2025 - "Async Path Reduction" Performance Improvements ======================== * `NetworkGraph`'s expensive internal consistency checks have now been disabled in debug builds in addition to release builds (lightningdevkit#3687). Bug Fixes ========= * Pathfinding which results in a multi-path payment is now substantially smarter, using fewer paths and better optimizing fees and successes (lightningdevkit#3890). * A counterparty delaying claiming multiple HTLCs with different expiries can no longer cause our `ChannelMonitor` to continuously rebroadcast invalid transactions or RBF bump attempts (lightningdevkit#3923). * Reorgs can no longer cause us to fail to claim HTLCs after a counterparty delayed claiming multiple HTLCs with different expiries (lightningdevkit#3923). * Force-closing a channel while it is blocked on another channel's async `ChannelMonitorUpdate` can no longer lead to a panic (lightningdevkit#3858). * `ChannelMonitorUpdate`s can no longer be released to storage too early when doing async updates or on restart. This only impacts async `ChannelMonitorUpdate` persistence and can lead to loss of funds only in rare cases with `ChannelMonitorUpdate` persistence order inversions (lightningdevkit#3907). Security ======== 0.1.5 fixes a vulnerability which could allow a peer to overdraw their reserve value, potentially cutting into commitment transaction fees on channels with a low reserve. * Due to a bug in checking whether an HTLC is dust during acceptance, near-dust HTLCs were not counted towards the commitment transaction fee, but did eventually contribute to it when we built a commitment transaction. This can be used by a counterparty to overdraw their reserve value, or, for channels with a low reserve value, cut into the commitment transaction fee (lightningdevkit#3933).

TheBlueMatt · 2025-07-10T18:16:02Z

See individual commits for more. This is #3860 with an additional issue I found while writing a test for it fixed.

In a number of tests we require available UTXOs to do HTLC anchor claims by bringing our own fees. We previously wrote that out in each test, which is somewhat verbose, so here we simply add a test utility that gives each node a full BTC in a single UTXO.

We have to prune locktimed packages when their inputs are spent, otherwise the notification of the watched outputs might be missed. This can lead to locktimed packages with spent inputs being added back to the pending claim requests in the future, and they are never cleaned up until node restart. Resolves: lightningdevkit#3859

ldk-reviews-bot · 2025-07-10T18:16:05Z

👋 Thanks for assigning @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

When we have an outpoint to claim which is lock-timed and the locktime is reached, we add it to `OnchainTxHandler::claimable_outpoints` to indicate the outpoint is now being claimed. However, `claimable_outpoints` is supposed to track when the outpoint first appeared on chain so that we can remove the claim if the outpoint is reorged out. Sadly, in the handling for lock-timed packages, we incorrectly stored the current height in `claimable_outpoints`, causing such claims to be removed in case of a reorg right after they were generated, even if the output we intend to claim isn't removed at all. Here we start tracking when the outpoint we're spending was created in `PackageSolvingData`'s constituent types. While we could have tracked this information in `PackageTemplate`, it would preclude later merging packages that are spending outpoints included in different blocks, which we don't necessarily want to do.

When we have an outpoint to claim which is lock-timed and the locktime is reached, we add it to `OnchainTxHandler::claimable_outpoints` to indicate the outpoint is now being claimed. However, `claimable_outpoints` is supposed to track when the outpoint first appeared on chain so that we can remove the claim if the outpoint is reorged out. Sadly, in the handling for lock-timed packages, we incorrectly stored the current height in `claimable_outpoints`, causing such claims to be removed in case of a reorg right after they were generated, even if the output we intend to claim isn't removed at all. Here we use the creation-height tracking added in the previous commit to actually address the issue, using the tracked height when adding a claim to `OnchainTxHandler::claimable_outpoints`. In cases where we have no information, we continue to use the current height, retaining the issue for locktimed packages on upgrades, but this simplifies cases where we actually don't have the information available anyway.

wpaulino · 2025-07-11T00:17:54Z

+ for (k, outpoint_confirmation_height) in req.outpoints_and_creation_heights() {
+ let creation_height = outpoint_confirmation_height.unwrap_or(conf_height);
+ log_info!(logger, "Registering claiming request for {}:{}, which exists as of height {creation_height}", k.txid, k.vout);
+ self.claimable_outpoints.insert(k.clone(), (claim_id, creation_height));


Hm, shouldn't we prefer signed_locktime over creation_height for outpoints that have one though? While the outpoint hasn't been reorged out, claiming it is no longer possible once the block at signed_locktime is disconnected.

In practice I think this would just result in us broadcasting things that cannot enter the mempool until we get back to the expected height. If we have any other claims that were merged into the same package for whatever reason, and they are still valid at the disconnected block height, then this would be a greater issue.

The problem is that when things time out via claimable_outpoints, we don't stop claiming them, we remove them. We don't get them back after a reorg at that point. We could move to pushing things into the locked-packages vec after a block-disconnect, but that seems like a bigger change?

ldk-reviews-bot · 2025-07-11T00:24:09Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

ldk-reviews-bot · 2025-07-14T00:01:05Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

This adds a single test which exercises both the ability to prune locktimed packages when inputs are spent as well as the creation-height tracking for locktimed packages.

TheBlueMatt · 2025-07-14T12:55:46Z

Cleaned up and improved the test slightly:

$ git diff-tree -U2 21be9c5ed d7726eff0
diff --git a/lightning/src/ln/reorg_tests.rs b/lightning/src/ln/reorg_tests.rs
index 6faabac4c0..c5f512b319 100644
--- a/lightning/src/ln/reorg_tests.rs+++ b/lightning/src/ln/reorg_tests.rs@@ -13,5 +13,5 @@
use crate::chain::chaininterface::LowerBoundedFeeEstimator;
-use crate::chain::channelmonitor::{ANTI_REORG_DELAY, LATENCY_GRACE_PERIOD_BLOCKS};+use crate::chain::channelmonitor::{ANTI_REORG_DELAY, Balance, LATENCY_GRACE_PERIOD_BLOCKS};
use crate::chain::transaction::OutPoint;
use crate::chain::Confirm;
@@ -1058,12 +1058,19 @@ fn do_test_split_htlc_expiry_tracking(use_third_htlc: bool, reorg_out: bool) {
if reorg_out {
- // Reorg out bs_htlc_spend_tx, letting node A the claim all the HTLCs instead.+ // Reorg out bs_htlc_spend_tx, letting node A claim all the HTLCs instead.
disconnect_blocks(&nodes[0], ANTI_REORG_DELAY - 2);
assert_eq!(nodes[0].tx_broadcaster.txn_broadcast().len(), 0);
- // As soon as bs_htlc_spend_tx is disconnected+ // As soon as bs_htlc_spend_tx is disconnected, node A should consider all HTLCs+ // claimable-on-timeout.
disconnect_blocks(&nodes[0], 1);
let balances = nodes[0].chain_monitor.chain_monitor.get_claimable_balances(&[]);
assert_eq!(balances.len(), if use_third_htlc { 3 } else { 2 });
+ for balance in balances {+ if let Balance::MaybeTimeoutClaimableHTLC { .. } = balance {+ } else {+ panic!("Unexpected balance {balance:?}");+ }+ }
connect_blocks(&nodes[0], 100);

TheBlueMatt · 2025-07-15T17:55:47Z

Backported in #3932

v0.1.5 - Jul 16, 2025 - "Async Path Reduction" Performance Improvements ======================== * `NetworkGraph`'s expensive internal consistency checks have now been disabled in debug builds in addition to release builds (lightningdevkit#3687). Bug Fixes ========= * Pathfinding which results in a multi-path payment is now substantially smarter, using fewer paths and better optimizing fees and successes (lightningdevkit#3890). * A counterparty delaying claiming multiple HTLCs with different expiries can no longer cause our `ChannelMonitor` to continuously rebroadcast invalid transactions or RBF bump attempts (lightningdevkit#3923). * Reorgs can no longer cause us to fail to claim HTLCs after a counterparty delayed claiming multiple HTLCs with different expiries (lightningdevkit#3923). * Force-closing a channel while it is blocked on another channel's async `ChannelMonitorUpdate` can no longer lead to a panic (lightningdevkit#3858). * `ChannelMonitorUpdate`s can no longer be released to storage too early when doing async updates or on restart. This only impacts async `ChannelMonitorUpdate` persistence and can lead to loss of funds only in rare cases with `ChannelMonitorUpdate` persistence order inversions (lightningdevkit#3907). Security ======== 0.1.5 fixes a vulnerability which could allow a peer to overdraw their reserve value, potentially cutting into commitment transaction fees on channels with a low reserve. * Due to a bug in checking whether an HTLC is dust during acceptance, near-dust HTLCs were not counted towards the commitment transaction fee, but did eventually contribute to it when we built a commitment transaction. This can be used by a counterparty to overdraw their reserve value, or, for channels with a low reserve value, cut into the commitment transaction fee (lightningdevkit#3933).

TheBlueMatt · 2025-07-10T18:16:02Z

See individual commits for more. This is #3860 with an additional issue I found while writing a test for it fixed.

In a number of tests we require available UTXOs to do HTLC anchor claims by bringing our own fees. We previously wrote that out in each test, which is somewhat verbose, so here we simply add a test utility that gives each node a full BTC in a single UTXO.

We have to prune locktimed packages when their inputs are spent, otherwise the notification of the watched outputs might be missed. This can lead to locktimed packages with spent inputs being added back to the pending claim requests in the future, and they are never cleaned up until node restart. Resolves: lightningdevkit#3859

ldk-reviews-bot · 2025-07-10T18:16:05Z

👋 Thanks for assigning @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

When we have an outpoint to claim which is lock-timed and the locktime is reached, we add it to `OnchainTxHandler::claimable_outpoints` to indicate the outpoint is now being claimed. However, `claimable_outpoints` is supposed to track when the outpoint first appeared on chain so that we can remove the claim if the outpoint is reorged out. Sadly, in the handling for lock-timed packages, we incorrectly stored the current height in `claimable_outpoints`, causing such claims to be removed in case of a reorg right after they were generated, even if the output we intend to claim isn't removed at all. Here we start tracking when the outpoint we're spending was created in `PackageSolvingData`'s constituent types. While we could have tracked this information in `PackageTemplate`, it would preclude later merging packages that are spending outpoints included in different blocks, which we don't necessarily want to do.

When we have an outpoint to claim which is lock-timed and the locktime is reached, we add it to `OnchainTxHandler::claimable_outpoints` to indicate the outpoint is now being claimed. However, `claimable_outpoints` is supposed to track when the outpoint first appeared on chain so that we can remove the claim if the outpoint is reorged out. Sadly, in the handling for lock-timed packages, we incorrectly stored the current height in `claimable_outpoints`, causing such claims to be removed in case of a reorg right after they were generated, even if the output we intend to claim isn't removed at all. Here we use the creation-height tracking added in the previous commit to actually address the issue, using the tracked height when adding a claim to `OnchainTxHandler::claimable_outpoints`. In cases where we have no information, we continue to use the current height, retaining the issue for locktimed packages on upgrades, but this simplifies cases where we actually don't have the information available anyway.

wpaulino · 2025-07-11T00:17:54Z

+ for (k, outpoint_confirmation_height) in req.outpoints_and_creation_heights() {
+ let creation_height = outpoint_confirmation_height.unwrap_or(conf_height);
+ log_info!(logger, "Registering claiming request for {}:{}, which exists as of height {creation_height}", k.txid, k.vout);
+ self.claimable_outpoints.insert(k.clone(), (claim_id, creation_height));


Hm, shouldn't we prefer signed_locktime over creation_height for outpoints that have one though? While the outpoint hasn't been reorged out, claiming it is no longer possible once the block at signed_locktime is disconnected.

In practice I think this would just result in us broadcasting things that cannot enter the mempool until we get back to the expected height. If we have any other claims that were merged into the same package for whatever reason, and they are still valid at the disconnected block height, then this would be a greater issue.

The problem is that when things time out via claimable_outpoints, we don't stop claiming them, we remove them. We don't get them back after a reorg at that point. We could move to pushing things into the locked-packages vec after a block-disconnect, but that seems like a bigger change?

ldk-reviews-bot · 2025-07-11T00:24:09Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

ldk-reviews-bot · 2025-07-14T00:01:05Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

This adds a single test which exercises both the ability to prune locktimed packages when inputs are spent as well as the creation-height tracking for locktimed packages.

TheBlueMatt · 2025-07-14T12:55:46Z

Cleaned up and improved the test slightly:

$ git diff-tree -U2 21be9c5ed d7726eff0
diff --git a/lightning/src/ln/reorg_tests.rs b/lightning/src/ln/reorg_tests.rs
index 6faabac4c0..c5f512b319 100644
--- a/lightning/src/ln/reorg_tests.rs+++ b/lightning/src/ln/reorg_tests.rs@@ -13,5 +13,5 @@
use crate::chain::chaininterface::LowerBoundedFeeEstimator;
-use crate::chain::channelmonitor::{ANTI_REORG_DELAY, LATENCY_GRACE_PERIOD_BLOCKS};+use crate::chain::channelmonitor::{ANTI_REORG_DELAY, Balance, LATENCY_GRACE_PERIOD_BLOCKS};
use crate::chain::transaction::OutPoint;
use crate::chain::Confirm;
@@ -1058,12 +1058,19 @@ fn do_test_split_htlc_expiry_tracking(use_third_htlc: bool, reorg_out: bool) {
if reorg_out {
- // Reorg out bs_htlc_spend_tx, letting node A the claim all the HTLCs instead.+ // Reorg out bs_htlc_spend_tx, letting node A claim all the HTLCs instead.
disconnect_blocks(&nodes[0], ANTI_REORG_DELAY - 2);
assert_eq!(nodes[0].tx_broadcaster.txn_broadcast().len(), 0);
- // As soon as bs_htlc_spend_tx is disconnected+ // As soon as bs_htlc_spend_tx is disconnected, node A should consider all HTLCs+ // claimable-on-timeout.
disconnect_blocks(&nodes[0], 1);
let balances = nodes[0].chain_monitor.chain_monitor.get_claimable_balances(&[]);
assert_eq!(balances.len(), if use_third_htlc { 3 } else { 2 });
+ for balance in balances {+ if let Balance::MaybeTimeoutClaimableHTLC { .. } = balance {+ } else {+ panic!("Unexpected balance {balance:?}");+ }+ }
connect_blocks(&nodes[0], 100);

TheBlueMatt · 2025-07-15T17:55:47Z

Backported in #3932

v0.1.5 - Jul 16, 2025 - "Async Path Reduction" Performance Improvements ======================== * `NetworkGraph`'s expensive internal consistency checks have now been disabled in debug builds in addition to release builds (lightningdevkit#3687). Bug Fixes ========= * Pathfinding which results in a multi-path payment is now substantially smarter, using fewer paths and better optimizing fees and successes (lightningdevkit#3890). * A counterparty delaying claiming multiple HTLCs with different expiries can no longer cause our `ChannelMonitor` to continuously rebroadcast invalid transactions or RBF bump attempts (lightningdevkit#3923). * Reorgs can no longer cause us to fail to claim HTLCs after a counterparty delayed claiming multiple HTLCs with different expiries (lightningdevkit#3923). * Force-closing a channel while it is blocked on another channel's async `ChannelMonitorUpdate` can no longer lead to a panic (lightningdevkit#3858). * `ChannelMonitorUpdate`s can no longer be released to storage too early when doing async updates or on restart. This only impacts async `ChannelMonitorUpdate` persistence and can lead to loss of funds only in rare cases with `ChannelMonitorUpdate` persistence order inversions (lightningdevkit#3907). Security ======== 0.1.5 fixes a vulnerability which could allow a peer to overdraw their reserve value, potentially cutting into commitment transaction fees on channels with a low reserve. * Due to a bug in checking whether an HTLC is dust during acceptance, near-dust HTLCs were not counted towards the commitment transaction fee, but did eventually contribute to it when we built a commitment transaction. This can be used by a counterparty to overdraw their reserve value, or, for channels with a low reserve value, cut into the commitment transaction fee (lightningdevkit#3933).

TheBlueMatt · 2025-07-10T18:16:02Z

See individual commits for more. This is #3860 with an additional issue I found while writing a test for it fixed.

In a number of tests we require available UTXOs to do HTLC anchor claims by bringing our own fees. We previously wrote that out in each test, which is somewhat verbose, so here we simply add a test utility that gives each node a full BTC in a single UTXO.

We have to prune locktimed packages when their inputs are spent, otherwise the notification of the watched outputs might be missed. This can lead to locktimed packages with spent inputs being added back to the pending claim requests in the future, and they are never cleaned up until node restart. Resolves: lightningdevkit#3859

ldk-reviews-bot · 2025-07-10T18:16:05Z

👋 Thanks for assigning @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

When we have an outpoint to claim which is lock-timed and the locktime is reached, we add it to `OnchainTxHandler::claimable_outpoints` to indicate the outpoint is now being claimed. However, `claimable_outpoints` is supposed to track when the outpoint first appeared on chain so that we can remove the claim if the outpoint is reorged out. Sadly, in the handling for lock-timed packages, we incorrectly stored the current height in `claimable_outpoints`, causing such claims to be removed in case of a reorg right after they were generated, even if the output we intend to claim isn't removed at all. Here we start tracking when the outpoint we're spending was created in `PackageSolvingData`'s constituent types. While we could have tracked this information in `PackageTemplate`, it would preclude later merging packages that are spending outpoints included in different blocks, which we don't necessarily want to do.

When we have an outpoint to claim which is lock-timed and the locktime is reached, we add it to `OnchainTxHandler::claimable_outpoints` to indicate the outpoint is now being claimed. However, `claimable_outpoints` is supposed to track when the outpoint first appeared on chain so that we can remove the claim if the outpoint is reorged out. Sadly, in the handling for lock-timed packages, we incorrectly stored the current height in `claimable_outpoints`, causing such claims to be removed in case of a reorg right after they were generated, even if the output we intend to claim isn't removed at all. Here we use the creation-height tracking added in the previous commit to actually address the issue, using the tracked height when adding a claim to `OnchainTxHandler::claimable_outpoints`. In cases where we have no information, we continue to use the current height, retaining the issue for locktimed packages on upgrades, but this simplifies cases where we actually don't have the information available anyway.

wpaulino · 2025-07-11T00:17:54Z

+ for (k, outpoint_confirmation_height) in req.outpoints_and_creation_heights() {
+ let creation_height = outpoint_confirmation_height.unwrap_or(conf_height);
+ log_info!(logger, "Registering claiming request for {}:{}, which exists as of height {creation_height}", k.txid, k.vout);
+ self.claimable_outpoints.insert(k.clone(), (claim_id, creation_height));


Hm, shouldn't we prefer signed_locktime over creation_height for outpoints that have one though? While the outpoint hasn't been reorged out, claiming it is no longer possible once the block at signed_locktime is disconnected.

In practice I think this would just result in us broadcasting things that cannot enter the mempool until we get back to the expected height. If we have any other claims that were merged into the same package for whatever reason, and they are still valid at the disconnected block height, then this would be a greater issue.

The problem is that when things time out via claimable_outpoints, we don't stop claiming them, we remove them. We don't get them back after a reorg at that point. We could move to pushing things into the locked-packages vec after a block-disconnect, but that seems like a bigger change?

ldk-reviews-bot · 2025-07-11T00:24:09Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

ldk-reviews-bot · 2025-07-14T00:01:05Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

This adds a single test which exercises both the ability to prune locktimed packages when inputs are spent as well as the creation-height tracking for locktimed packages.

TheBlueMatt · 2025-07-14T12:55:46Z

Cleaned up and improved the test slightly:

$ git diff-tree -U2 21be9c5ed d7726eff0
diff --git a/lightning/src/ln/reorg_tests.rs b/lightning/src/ln/reorg_tests.rs
index 6faabac4c0..c5f512b319 100644
--- a/lightning/src/ln/reorg_tests.rs+++ b/lightning/src/ln/reorg_tests.rs@@ -13,5 +13,5 @@
use crate::chain::chaininterface::LowerBoundedFeeEstimator;
-use crate::chain::channelmonitor::{ANTI_REORG_DELAY, LATENCY_GRACE_PERIOD_BLOCKS};+use crate::chain::channelmonitor::{ANTI_REORG_DELAY, Balance, LATENCY_GRACE_PERIOD_BLOCKS};
use crate::chain::transaction::OutPoint;
use crate::chain::Confirm;
@@ -1058,12 +1058,19 @@ fn do_test_split_htlc_expiry_tracking(use_third_htlc: bool, reorg_out: bool) {
if reorg_out {
- // Reorg out bs_htlc_spend_tx, letting node A the claim all the HTLCs instead.+ // Reorg out bs_htlc_spend_tx, letting node A claim all the HTLCs instead.
disconnect_blocks(&nodes[0], ANTI_REORG_DELAY - 2);
assert_eq!(nodes[0].tx_broadcaster.txn_broadcast().len(), 0);
- // As soon as bs_htlc_spend_tx is disconnected+ // As soon as bs_htlc_spend_tx is disconnected, node A should consider all HTLCs+ // claimable-on-timeout.
disconnect_blocks(&nodes[0], 1);
let balances = nodes[0].chain_monitor.chain_monitor.get_claimable_balances(&[]);
assert_eq!(balances.len(), if use_third_htlc { 3 } else { 2 });
+ for balance in balances {+ if let Balance::MaybeTimeoutClaimableHTLC { .. } = balance {+ } else {+ panic!("Unexpected balance {balance:?}");+ }+ }
connect_blocks(&nodes[0], 100);

TheBlueMatt · 2025-07-15T17:55:47Z

Backported in #3932

v0.1.5 - Jul 16, 2025 - "Async Path Reduction" Performance Improvements ======================== * `NetworkGraph`'s expensive internal consistency checks have now been disabled in debug builds in addition to release builds (lightningdevkit#3687). Bug Fixes ========= * Pathfinding which results in a multi-path payment is now substantially smarter, using fewer paths and better optimizing fees and successes (lightningdevkit#3890). * A counterparty delaying claiming multiple HTLCs with different expiries can no longer cause our `ChannelMonitor` to continuously rebroadcast invalid transactions or RBF bump attempts (lightningdevkit#3923). * Reorgs can no longer cause us to fail to claim HTLCs after a counterparty delayed claiming multiple HTLCs with different expiries (lightningdevkit#3923). * Force-closing a channel while it is blocked on another channel's async `ChannelMonitorUpdate` can no longer lead to a panic (lightningdevkit#3858). * `ChannelMonitorUpdate`s can no longer be released to storage too early when doing async updates or on restart. This only impacts async `ChannelMonitorUpdate` persistence and can lead to loss of funds only in rare cases with `ChannelMonitorUpdate` persistence order inversions (lightningdevkit#3907). Security ======== 0.1.5 fixes a vulnerability which could allow a peer to overdraw their reserve value, potentially cutting into commitment transaction fees on channels with a low reserve. * Due to a bug in checking whether an HTLC is dust during acceptance, near-dust HTLCs were not counted towards the commitment transaction fee, but did eventually contribute to it when we built a commitment transaction. This can be used by a counterparty to overdraw their reserve value, or, for channels with a low reserve value, cut into the commitment transaction fee (lightningdevkit#3933).

TheBlueMatt · 2025-07-10T18:16:02Z

See individual commits for more. This is #3860 with an additional issue I found while writing a test for it fixed.

In a number of tests we require available UTXOs to do HTLC anchor claims by bringing our own fees. We previously wrote that out in each test, which is somewhat verbose, so here we simply add a test utility that gives each node a full BTC in a single UTXO.

We have to prune locktimed packages when their inputs are spent, otherwise the notification of the watched outputs might be missed. This can lead to locktimed packages with spent inputs being added back to the pending claim requests in the future, and they are never cleaned up until node restart. Resolves: lightningdevkit#3859

ldk-reviews-bot · 2025-07-10T18:16:05Z

👋 Thanks for assigning @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

When we have an outpoint to claim which is lock-timed and the locktime is reached, we add it to `OnchainTxHandler::claimable_outpoints` to indicate the outpoint is now being claimed. However, `claimable_outpoints` is supposed to track when the outpoint first appeared on chain so that we can remove the claim if the outpoint is reorged out. Sadly, in the handling for lock-timed packages, we incorrectly stored the current height in `claimable_outpoints`, causing such claims to be removed in case of a reorg right after they were generated, even if the output we intend to claim isn't removed at all. Here we start tracking when the outpoint we're spending was created in `PackageSolvingData`'s constituent types. While we could have tracked this information in `PackageTemplate`, it would preclude later merging packages that are spending outpoints included in different blocks, which we don't necessarily want to do.

When we have an outpoint to claim which is lock-timed and the locktime is reached, we add it to `OnchainTxHandler::claimable_outpoints` to indicate the outpoint is now being claimed. However, `claimable_outpoints` is supposed to track when the outpoint first appeared on chain so that we can remove the claim if the outpoint is reorged out. Sadly, in the handling for lock-timed packages, we incorrectly stored the current height in `claimable_outpoints`, causing such claims to be removed in case of a reorg right after they were generated, even if the output we intend to claim isn't removed at all. Here we use the creation-height tracking added in the previous commit to actually address the issue, using the tracked height when adding a claim to `OnchainTxHandler::claimable_outpoints`. In cases where we have no information, we continue to use the current height, retaining the issue for locktimed packages on upgrades, but this simplifies cases where we actually don't have the information available anyway.

wpaulino · 2025-07-11T00:17:54Z

+ for (k, outpoint_confirmation_height) in req.outpoints_and_creation_heights() {
+ let creation_height = outpoint_confirmation_height.unwrap_or(conf_height);
+ log_info!(logger, "Registering claiming request for {}:{}, which exists as of height {creation_height}", k.txid, k.vout);
+ self.claimable_outpoints.insert(k.clone(), (claim_id, creation_height));


Hm, shouldn't we prefer signed_locktime over creation_height for outpoints that have one though? While the outpoint hasn't been reorged out, claiming it is no longer possible once the block at signed_locktime is disconnected.

In practice I think this would just result in us broadcasting things that cannot enter the mempool until we get back to the expected height. If we have any other claims that were merged into the same package for whatever reason, and they are still valid at the disconnected block height, then this would be a greater issue.

The problem is that when things time out via claimable_outpoints, we don't stop claiming them, we remove them. We don't get them back after a reorg at that point. We could move to pushing things into the locked-packages vec after a block-disconnect, but that seems like a bigger change?

ldk-reviews-bot · 2025-07-11T00:24:09Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

ldk-reviews-bot · 2025-07-14T00:01:05Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

This adds a single test which exercises both the ability to prune locktimed packages when inputs are spent as well as the creation-height tracking for locktimed packages.

TheBlueMatt · 2025-07-14T12:55:46Z

Cleaned up and improved the test slightly:

$ git diff-tree -U2 21be9c5ed d7726eff0
diff --git a/lightning/src/ln/reorg_tests.rs b/lightning/src/ln/reorg_tests.rs
index 6faabac4c0..c5f512b319 100644
--- a/lightning/src/ln/reorg_tests.rs+++ b/lightning/src/ln/reorg_tests.rs@@ -13,5 +13,5 @@
use crate::chain::chaininterface::LowerBoundedFeeEstimator;
-use crate::chain::channelmonitor::{ANTI_REORG_DELAY, LATENCY_GRACE_PERIOD_BLOCKS};+use crate::chain::channelmonitor::{ANTI_REORG_DELAY, Balance, LATENCY_GRACE_PERIOD_BLOCKS};
use crate::chain::transaction::OutPoint;
use crate::chain::Confirm;
@@ -1058,12 +1058,19 @@ fn do_test_split_htlc_expiry_tracking(use_third_htlc: bool, reorg_out: bool) {
if reorg_out {
- // Reorg out bs_htlc_spend_tx, letting node A the claim all the HTLCs instead.+ // Reorg out bs_htlc_spend_tx, letting node A claim all the HTLCs instead.
disconnect_blocks(&nodes[0], ANTI_REORG_DELAY - 2);
assert_eq!(nodes[0].tx_broadcaster.txn_broadcast().len(), 0);
- // As soon as bs_htlc_spend_tx is disconnected+ // As soon as bs_htlc_spend_tx is disconnected, node A should consider all HTLCs+ // claimable-on-timeout.
disconnect_blocks(&nodes[0], 1);
let balances = nodes[0].chain_monitor.chain_monitor.get_claimable_balances(&[]);
assert_eq!(balances.len(), if use_third_htlc { 3 } else { 2 });
+ for balance in balances {+ if let Balance::MaybeTimeoutClaimableHTLC { .. } = balance {+ } else {+ panic!("Unexpected balance {balance:?}");+ }+ }
connect_blocks(&nodes[0], 100);

TheBlueMatt · 2025-07-15T17:55:47Z

Backported in #3932

v0.1.5 - Jul 16, 2025 - "Async Path Reduction" Performance Improvements ======================== * `NetworkGraph`'s expensive internal consistency checks have now been disabled in debug builds in addition to release builds (lightningdevkit#3687). Bug Fixes ========= * Pathfinding which results in a multi-path payment is now substantially smarter, using fewer paths and better optimizing fees and successes (lightningdevkit#3890). * A counterparty delaying claiming multiple HTLCs with different expiries can no longer cause our `ChannelMonitor` to continuously rebroadcast invalid transactions or RBF bump attempts (lightningdevkit#3923). * Reorgs can no longer cause us to fail to claim HTLCs after a counterparty delayed claiming multiple HTLCs with different expiries (lightningdevkit#3923). * Force-closing a channel while it is blocked on another channel's async `ChannelMonitorUpdate` can no longer lead to a panic (lightningdevkit#3858). * `ChannelMonitorUpdate`s can no longer be released to storage too early when doing async updates or on restart. This only impacts async `ChannelMonitorUpdate` persistence and can lead to loss of funds only in rare cases with `ChannelMonitorUpdate` persistence order inversions (lightningdevkit#3907). Security ======== 0.1.5 fixes a vulnerability which could allow a peer to overdraw their reserve value, potentially cutting into commitment transaction fees on channels with a low reserve. * Due to a bug in checking whether an HTLC is dust during acceptance, near-dust HTLCs were not counted towards the commitment transaction fee, but did eventually contribute to it when we built a commitment transaction. This can be used by a counterparty to overdraw their reserve value, or, for channels with a low reserve value, cut into the commitment transaction fee (lightningdevkit#3933).

TheBlueMatt · 2025-07-10T18:16:02Z

See individual commits for more. This is #3860 with an additional issue I found while writing a test for it fixed.

In a number of tests we require available UTXOs to do HTLC anchor claims by bringing our own fees. We previously wrote that out in each test, which is somewhat verbose, so here we simply add a test utility that gives each node a full BTC in a single UTXO.

We have to prune locktimed packages when their inputs are spent, otherwise the notification of the watched outputs might be missed. This can lead to locktimed packages with spent inputs being added back to the pending claim requests in the future, and they are never cleaned up until node restart. Resolves: lightningdevkit#3859

ldk-reviews-bot · 2025-07-10T18:16:05Z

👋 Thanks for assigning @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

When we have an outpoint to claim which is lock-timed and the locktime is reached, we add it to `OnchainTxHandler::claimable_outpoints` to indicate the outpoint is now being claimed. However, `claimable_outpoints` is supposed to track when the outpoint first appeared on chain so that we can remove the claim if the outpoint is reorged out. Sadly, in the handling for lock-timed packages, we incorrectly stored the current height in `claimable_outpoints`, causing such claims to be removed in case of a reorg right after they were generated, even if the output we intend to claim isn't removed at all. Here we start tracking when the outpoint we're spending was created in `PackageSolvingData`'s constituent types. While we could have tracked this information in `PackageTemplate`, it would preclude later merging packages that are spending outpoints included in different blocks, which we don't necessarily want to do.

When we have an outpoint to claim which is lock-timed and the locktime is reached, we add it to `OnchainTxHandler::claimable_outpoints` to indicate the outpoint is now being claimed. However, `claimable_outpoints` is supposed to track when the outpoint first appeared on chain so that we can remove the claim if the outpoint is reorged out. Sadly, in the handling for lock-timed packages, we incorrectly stored the current height in `claimable_outpoints`, causing such claims to be removed in case of a reorg right after they were generated, even if the output we intend to claim isn't removed at all. Here we use the creation-height tracking added in the previous commit to actually address the issue, using the tracked height when adding a claim to `OnchainTxHandler::claimable_outpoints`. In cases where we have no information, we continue to use the current height, retaining the issue for locktimed packages on upgrades, but this simplifies cases where we actually don't have the information available anyway.

wpaulino · 2025-07-11T00:17:54Z

+ for (k, outpoint_confirmation_height) in req.outpoints_and_creation_heights() {
+ let creation_height = outpoint_confirmation_height.unwrap_or(conf_height);
+ log_info!(logger, "Registering claiming request for {}:{}, which exists as of height {creation_height}", k.txid, k.vout);
+ self.claimable_outpoints.insert(k.clone(), (claim_id, creation_height));


Hm, shouldn't we prefer signed_locktime over creation_height for outpoints that have one though? While the outpoint hasn't been reorged out, claiming it is no longer possible once the block at signed_locktime is disconnected.

In practice I think this would just result in us broadcasting things that cannot enter the mempool until we get back to the expected height. If we have any other claims that were merged into the same package for whatever reason, and they are still valid at the disconnected block height, then this would be a greater issue.

The problem is that when things time out via claimable_outpoints, we don't stop claiming them, we remove them. We don't get them back after a reorg at that point. We could move to pushing things into the locked-packages vec after a block-disconnect, but that seems like a bigger change?

ldk-reviews-bot · 2025-07-11T00:24:09Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

ldk-reviews-bot · 2025-07-14T00:01:05Z

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

This adds a single test which exercises both the ability to prune locktimed packages when inputs are spent as well as the creation-height tracking for locktimed packages.

TheBlueMatt · 2025-07-14T12:55:46Z

Cleaned up and improved the test slightly:

$ git diff-tree -U2 21be9c5ed d7726eff0
diff --git a/lightning/src/ln/reorg_tests.rs b/lightning/src/ln/reorg_tests.rs
index 6faabac4c0..c5f512b319 100644
--- a/lightning/src/ln/reorg_tests.rs+++ b/lightning/src/ln/reorg_tests.rs@@ -13,5 +13,5 @@
use crate::chain::chaininterface::LowerBoundedFeeEstimator;
-use crate::chain::channelmonitor::{ANTI_REORG_DELAY, LATENCY_GRACE_PERIOD_BLOCKS};+use crate::chain::channelmonitor::{ANTI_REORG_DELAY, Balance, LATENCY_GRACE_PERIOD_BLOCKS};
use crate::chain::transaction::OutPoint;
use crate::chain::Confirm;
@@ -1058,12 +1058,19 @@ fn do_test_split_htlc_expiry_tracking(use_third_htlc: bool, reorg_out: bool) {
if reorg_out {
- // Reorg out bs_htlc_spend_tx, letting node A the claim all the HTLCs instead.+ // Reorg out bs_htlc_spend_tx, letting node A claim all the HTLCs instead.
disconnect_blocks(&nodes[0], ANTI_REORG_DELAY - 2);
assert_eq!(nodes[0].tx_broadcaster.txn_broadcast().len(), 0);
- // As soon as bs_htlc_spend_tx is disconnected+ // As soon as bs_htlc_spend_tx is disconnected, node A should consider all HTLCs+ // claimable-on-timeout.
disconnect_blocks(&nodes[0], 1);
let balances = nodes[0].chain_monitor.chain_monitor.get_claimable_balances(&[]);
assert_eq!(balances.len(), if use_third_htlc { 3 } else { 2 });
+ for balance in balances {+ if let Balance::MaybeTimeoutClaimableHTLC { .. } = balance {+ } else {+ panic!("Unexpected balance {balance:?}");+ }+ }
connect_blocks(&nodes[0], 100);

TheBlueMatt · 2025-07-15T17:55:47Z

Backported in #3932

v0.1.5 - Jul 16, 2025 - "Async Path Reduction" Performance Improvements ======================== * `NetworkGraph`'s expensive internal consistency checks have now been disabled in debug builds in addition to release builds (lightningdevkit#3687). Bug Fixes ========= * Pathfinding which results in a multi-path payment is now substantially smarter, using fewer paths and better optimizing fees and successes (lightningdevkit#3890). * A counterparty delaying claiming multiple HTLCs with different expiries can no longer cause our `ChannelMonitor` to continuously rebroadcast invalid transactions or RBF bump attempts (lightningdevkit#3923). * Reorgs can no longer cause us to fail to claim HTLCs after a counterparty delayed claiming multiple HTLCs with different expiries (lightningdevkit#3923). * Force-closing a channel while it is blocked on another channel's async `ChannelMonitorUpdate` can no longer lead to a panic (lightningdevkit#3858). * `ChannelMonitorUpdate`s can no longer be released to storage too early when doing async updates or on restart. This only impacts async `ChannelMonitorUpdate` persistence and can lead to loss of funds only in rare cases with `ChannelMonitorUpdate` persistence order inversions (lightningdevkit#3907). Security ======== 0.1.5 fixes a vulnerability which could allow a peer to overdraw their reserve value, potentially cutting into commitment transaction fees on channels with a low reserve. * Due to a bug in checking whether an HTLC is dust during acceptance, near-dust HTLCs were not counted towards the commitment transaction fee, but did eventually contribute to it when we built a commitment transaction. This can be used by a counterparty to overdraw their reserve value, or, for channels with a low reserve value, cut into the commitment transaction fee (lightningdevkit#3933).

TheBlueMattand others added 2 commits July 10, 2025 17:56

TheBlueMatt added this to the 0.2 milestone Jul 10, 2025

TheBlueMatt requested a review from wpaulino July 10, 2025 18:16

TheBlueMatt mentioned this pull request Jul 10, 2025
Prune locktimed packages when inputs are spent #3860
Closed

graphite-appBot reviewed Jul 10, 2025
View reviewed changes

Comment threadlightning/src/ln/reorg_tests.rs Outdated

TheBlueMatt added 2 commits July 10, 2025 21:57

TheBlueMatt force-pushed the 2025-07-3860-plus-plus branch from ff95a56 to 21be9c5Compare July 10, 2025 22:19

wpaulino reviewed Jul 11, 2025
View reviewed changes

tankyleo self-requested a review July 11, 2025 16:55

Add a test case for the issues fixed in the previous few commits
d7726ef
This adds a single test which exercises both the ability to prune locktimed packages when inputs are spent as well as the creation-height tracking for locktimed packages.

TheBlueMatt force-pushed the 2025-07-3860-plus-plus branch from 21be9c5 to d7726efCompare July 14, 2025 12:53

wpaulino approved these changes Jul 14, 2025
View reviewed changes

tankyleo approved these changes Jul 14, 2025
View reviewed changes

TheBlueMatt merged commit 7e4598d into lightningdevkit:mainJul 15, 2025

TheBlueMatt added the backport 0.1 label Jul 15, 2025

TheBlueMatt mentioned this pull request Jul 15, 2025
0.1.5 backports #3932
Merged

TheBlueMatt removed the backport 0.1 label Jul 15, 2025

TheBlueMatt added this to Weekly Goals Jul 17, 2025

TheBlueMatt self-assigned this Jul 17, 2025

TheBlueMattand others added 2 commits July 10, 2025 17:56

TheBlueMatt added this to the 0.2 milestone Jul 10, 2025

TheBlueMatt requested a review from wpaulino July 10, 2025 18:16

TheBlueMatt mentioned this pull request Jul 10, 2025
Prune locktimed packages when inputs are spent #3860
Closed

graphite-appBot reviewed Jul 10, 2025
View reviewed changes

Comment threadlightning/src/ln/reorg_tests.rs Outdated

TheBlueMatt added 2 commits July 10, 2025 21:57

TheBlueMatt force-pushed the 2025-07-3860-plus-plus branch from ff95a56 to 21be9c5Compare July 10, 2025 22:19

wpaulino reviewed Jul 11, 2025
View reviewed changes

tankyleo self-requested a review July 11, 2025 16:55

Add a test case for the issues fixed in the previous few commits
d7726ef
This adds a single test which exercises both the ability to prune locktimed packages when inputs are spent as well as the creation-height tracking for locktimed packages.

TheBlueMatt force-pushed the 2025-07-3860-plus-plus branch from 21be9c5 to d7726efCompare July 14, 2025 12:53

wpaulino approved these changes Jul 14, 2025
View reviewed changes

tankyleo approved these changes Jul 14, 2025
View reviewed changes

TheBlueMatt merged commit 7e4598d into lightningdevkit:mainJul 15, 2025

TheBlueMatt added the backport 0.1 label Jul 15, 2025

TheBlueMatt mentioned this pull request Jul 15, 2025
0.1.5 backports #3932
Merged

TheBlueMatt removed the backport 0.1 label Jul 15, 2025

TheBlueMatt added this to Weekly Goals Jul 17, 2025

TheBlueMatt self-assigned this Jul 17, 2025

TheBlueMattand others added 2 commits July 10, 2025 17:56

TheBlueMatt added this to the 0.2 milestone Jul 10, 2025

TheBlueMatt requested a review from wpaulino July 10, 2025 18:16

TheBlueMatt mentioned this pull request Jul 10, 2025
Prune locktimed packages when inputs are spent #3860
Closed

graphite-appBot reviewed Jul 10, 2025
View reviewed changes

Comment threadlightning/src/ln/reorg_tests.rs Outdated

TheBlueMatt added 2 commits July 10, 2025 21:57

TheBlueMatt force-pushed the 2025-07-3860-plus-plus branch from ff95a56 to 21be9c5Compare July 10, 2025 22:19

wpaulino reviewed Jul 11, 2025
View reviewed changes

tankyleo self-requested a review July 11, 2025 16:55

Add a test case for the issues fixed in the previous few commits
d7726ef
This adds a single test which exercises both the ability to prune locktimed packages when inputs are spent as well as the creation-height tracking for locktimed packages.

TheBlueMatt force-pushed the 2025-07-3860-plus-plus branch from 21be9c5 to d7726efCompare July 14, 2025 12:53

wpaulino approved these changes Jul 14, 2025
View reviewed changes

tankyleo approved these changes Jul 14, 2025
View reviewed changes

TheBlueMatt merged commit 7e4598d into lightningdevkit:mainJul 15, 2025

TheBlueMatt added the backport 0.1 label Jul 15, 2025

TheBlueMatt mentioned this pull request Jul 15, 2025
0.1.5 backports #3932
Merged

TheBlueMatt removed the backport 0.1 label Jul 15, 2025

TheBlueMatt added this to Weekly Goals Jul 17, 2025

TheBlueMatt self-assigned this Jul 17, 2025

TheBlueMattand others added 2 commits July 10, 2025 17:56

TheBlueMatt added this to the 0.2 milestone Jul 10, 2025

TheBlueMatt requested a review from wpaulino July 10, 2025 18:16

TheBlueMatt mentioned this pull request Jul 10, 2025
Prune locktimed packages when inputs are spent #3860
Closed

graphite-appBot reviewed Jul 10, 2025
View reviewed changes

Comment threadlightning/src/ln/reorg_tests.rs Outdated

TheBlueMatt added 2 commits July 10, 2025 21:57

TheBlueMatt force-pushed the 2025-07-3860-plus-plus branch from ff95a56 to 21be9c5Compare July 10, 2025 22:19

wpaulino reviewed Jul 11, 2025
View reviewed changes

tankyleo self-requested a review July 11, 2025 16:55

Add a test case for the issues fixed in the previous few commits
d7726ef
This adds a single test which exercises both the ability to prune locktimed packages when inputs are spent as well as the creation-height tracking for locktimed packages.

TheBlueMatt force-pushed the 2025-07-3860-plus-plus branch from 21be9c5 to d7726efCompare July 14, 2025 12:53

wpaulino approved these changes Jul 14, 2025
View reviewed changes

tankyleo approved these changes Jul 14, 2025
View reviewed changes

TheBlueMatt merged commit 7e4598d into lightningdevkit:mainJul 15, 2025

TheBlueMatt added the backport 0.1 label Jul 15, 2025

TheBlueMatt mentioned this pull request Jul 15, 2025
0.1.5 backports #3932
Merged

TheBlueMatt removed the backport 0.1 label Jul 15, 2025

TheBlueMatt added this to Weekly Goals Jul 17, 2025

TheBlueMatt self-assigned this Jul 17, 2025

TheBlueMattand others added 2 commits July 10, 2025 17:56

TheBlueMatt added this to the 0.2 milestone Jul 10, 2025

TheBlueMatt requested a review from wpaulino July 10, 2025 18:16

TheBlueMatt mentioned this pull request Jul 10, 2025
Prune locktimed packages when inputs are spent #3860
Closed

graphite-appBot reviewed Jul 10, 2025
View reviewed changes

Comment threadlightning/src/ln/reorg_tests.rs Outdated

TheBlueMatt added 2 commits July 10, 2025 21:57

TheBlueMatt force-pushed the 2025-07-3860-plus-plus branch from ff95a56 to 21be9c5Compare July 10, 2025 22:19

wpaulino reviewed Jul 11, 2025
View reviewed changes

tankyleo self-requested a review July 11, 2025 16:55

Add a test case for the issues fixed in the previous few commits
d7726ef
This adds a single test which exercises both the ability to prune locktimed packages when inputs are spent as well as the creation-height tracking for locktimed packages.

TheBlueMatt force-pushed the 2025-07-3860-plus-plus branch from 21be9c5 to d7726efCompare July 14, 2025 12:53

wpaulino approved these changes Jul 14, 2025
View reviewed changes

tankyleo approved these changes Jul 14, 2025
View reviewed changes

TheBlueMatt merged commit 7e4598d into lightningdevkit:mainJul 15, 2025

TheBlueMatt added the backport 0.1 label Jul 15, 2025

TheBlueMatt mentioned this pull request Jul 15, 2025
0.1.5 backports #3932
Merged

TheBlueMatt removed the backport 0.1 label Jul 15, 2025

TheBlueMatt added this to Weekly Goals Jul 17, 2025

TheBlueMatt self-assigned this Jul 17, 2025

TheBlueMattand others added 2 commits July 10, 2025 17:56

TheBlueMatt added this to the 0.2 milestone Jul 10, 2025

TheBlueMatt requested a review from wpaulino July 10, 2025 18:16

TheBlueMatt mentioned this pull request Jul 10, 2025
Prune locktimed packages when inputs are spent #3860
Closed

graphite-appBot reviewed Jul 10, 2025
View reviewed changes

Comment threadlightning/src/ln/reorg_tests.rs Outdated

TheBlueMatt added 2 commits July 10, 2025 21:57

TheBlueMatt force-pushed the 2025-07-3860-plus-plus branch from ff95a56 to 21be9c5Compare July 10, 2025 22:19

wpaulino reviewed Jul 11, 2025
View reviewed changes

tankyleo self-requested a review July 11, 2025 16:55

Add a test case for the issues fixed in the previous few commits
d7726ef
This adds a single test which exercises both the ability to prune locktimed packages when inputs are spent as well as the creation-height tracking for locktimed packages.

TheBlueMatt force-pushed the 2025-07-3860-plus-plus branch from 21be9c5 to d7726efCompare July 14, 2025 12:53

wpaulino approved these changes Jul 14, 2025
View reviewed changes

tankyleo approved these changes Jul 14, 2025
View reviewed changes

TheBlueMatt merged commit 7e4598d into lightningdevkit:mainJul 15, 2025

TheBlueMatt added the backport 0.1 label Jul 15, 2025

TheBlueMatt mentioned this pull request Jul 15, 2025
0.1.5 backports #3932
Merged

TheBlueMatt removed the backport 0.1 label Jul 15, 2025

TheBlueMatt added this to Weekly Goals Jul 17, 2025

TheBlueMatt self-assigned this Jul 17, 2025

TheBlueMattand others added 2 commits July 10, 2025 17:56

TheBlueMatt added this to the 0.2 milestone Jul 10, 2025

TheBlueMatt requested a review from wpaulino July 10, 2025 18:16

TheBlueMatt mentioned this pull request Jul 10, 2025
Prune locktimed packages when inputs are spent #3860
Closed

graphite-appBot reviewed Jul 10, 2025
View reviewed changes

Comment threadlightning/src/ln/reorg_tests.rs Outdated

TheBlueMatt added 2 commits July 10, 2025 21:57

TheBlueMatt force-pushed the 2025-07-3860-plus-plus branch from ff95a56 to 21be9c5Compare July 10, 2025 22:19

wpaulino reviewed Jul 11, 2025
View reviewed changes

tankyleo self-requested a review July 11, 2025 16:55

Add a test case for the issues fixed in the previous few commits
d7726ef
This adds a single test which exercises both the ability to prune locktimed packages when inputs are spent as well as the creation-height tracking for locktimed packages.

TheBlueMatt force-pushed the 2025-07-3860-plus-plus branch from 21be9c5 to d7726efCompare July 14, 2025 12:53

wpaulino approved these changes Jul 14, 2025
View reviewed changes

tankyleo approved these changes Jul 14, 2025
View reviewed changes

TheBlueMatt merged commit 7e4598d into lightningdevkit:mainJul 15, 2025

TheBlueMatt added the backport 0.1 label Jul 15, 2025

TheBlueMatt mentioned this pull request Jul 15, 2025
0.1.5 backports #3932
Merged

TheBlueMatt removed the backport 0.1 label Jul 15, 2025

TheBlueMatt added this to Weekly Goals Jul 17, 2025

TheBlueMatt self-assigned this Jul 17, 2025

TheBlueMattand others added 2 commits July 10, 2025 17:56

TheBlueMatt added this to the 0.2 milestone Jul 10, 2025

TheBlueMatt requested a review from wpaulino July 10, 2025 18:16

TheBlueMatt mentioned this pull request Jul 10, 2025
Prune locktimed packages when inputs are spent #3860
Closed

graphite-appBot reviewed Jul 10, 2025
View reviewed changes

Comment threadlightning/src/ln/reorg_tests.rs Outdated

TheBlueMatt added 2 commits July 10, 2025 21:57

TheBlueMatt force-pushed the 2025-07-3860-plus-plus branch from ff95a56 to 21be9c5Compare July 10, 2025 22:19

wpaulino reviewed Jul 11, 2025
View reviewed changes

tankyleo self-requested a review July 11, 2025 16:55

Add a test case for the issues fixed in the previous few commits
d7726ef
This adds a single test which exercises both the ability to prune locktimed packages when inputs are spent as well as the creation-height tracking for locktimed packages.

TheBlueMatt force-pushed the 2025-07-3860-plus-plus branch from 21be9c5 to d7726efCompare July 14, 2025 12:53

wpaulino approved these changes Jul 14, 2025
View reviewed changes

tankyleo approved these changes Jul 14, 2025
View reviewed changes

TheBlueMatt merged commit 7e4598d into lightningdevkit:mainJul 15, 2025

TheBlueMatt added the backport 0.1 label Jul 15, 2025

TheBlueMatt mentioned this pull request Jul 15, 2025
0.1.5 backports #3932
Merged

TheBlueMatt removed the backport 0.1 label Jul 15, 2025

TheBlueMatt added this to Weekly Goals Jul 17, 2025

TheBlueMatt self-assigned this Jul 17, 2025

Uh oh!

Conversation

TheBlueMatt commented Jul 10, 2025

Uh oh!

ldk-reviews-bot commented Jul 10, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ldk-reviews-bot commented Jul 11, 2025

Uh oh!

ldk-reviews-bot commented Jul 14, 2025

Uh oh!

TheBlueMatt commented Jul 14, 2025

Uh oh!

TheBlueMatt commented Jul 15, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

TheBlueMatt commented Jul 10, 2025

Uh oh!

ldk-reviews-bot commented Jul 10, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ldk-reviews-bot commented Jul 11, 2025

Uh oh!

ldk-reviews-bot commented Jul 14, 2025

Uh oh!

TheBlueMatt commented Jul 14, 2025

Uh oh!

TheBlueMatt commented Jul 15, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

TheBlueMatt commented Jul 10, 2025

Uh oh!

ldk-reviews-bot commented Jul 10, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

ldk-reviews-bot commented Jul 10, 2025•
edited
Loading

ldk-reviews-bot commented Jul 10, 2025•
edited
Loading

ldk-reviews-bot commented Jul 10, 2025•
edited
Loading

ldk-reviews-bot commented Jul 10, 2025•
edited
Loading