Fix `update_id` gap during `force_shutdown` by whfuyn · Pull Request #3858 · lightningdevkit/rust-lightning

whfuyn · 2025-06-13T14:32:31Z

When a channel is force-closed, there might be blocked monitor updates not yet applied. But latest_monitor_update_id has been incremented and assigned to these updates. This results in a panic when trying to apply the ChannelForceClosed update. Use the unblocked update id instead.

Resolves: #3857

ldk-reviews-bot · 2025-06-13T14:32:34Z

👋 Thanks for assigning @TheBlueMatt 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.

wpaulino

Thanks! This should work, but do you mind including a test?

There are other scenarios where we also increment by 1, but those should not result in a panic as they are queued in blocked_monitor_updates. The force close update is the only one we let fly through regardless of blocked_monitor_updates.

whfuyn · 2025-06-13T17:33:59Z

Got it! Will add a test later.

codecov · 2025-06-13T23:03:47Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.62%. Comparing base (c48e0a8) to head (ceb5a55).
Report is 4 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3858 +/- ##
==========================================
- Coverage 89.65% 89.62% -0.04% 
==========================================
Files 164 164 Lines 134658 134661 +3 Branches 134658 134661 +3 ==========================================
- Hits 120734 120688 -46 - Misses 11246 11292 +46 - Partials 2678 2681 +3

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

TheBlueMatt

Thanks. I think there's a few more changes I want to make to this pipeline but this change by itself looks good.

wpaulino · 2025-06-20T16:21:47Z

@whfuyn do you mind rebasing this? We're going to merge this as is to include it in a release and follow up with a test later.

When a channel is force-closed, there might be blocked monitor updates not yet applied. But `latest_monitor_update_id` has been incremented and assigned to these updates. This results in a panic when trying to apply the `ChannelForceClosed` update. Use the unblocked update id instead. Resolves: lightningdevkit#3857

whfuyn · 2025-06-24T04:38:27Z

@wpaulino Sorry for the late response.

I had some trouble constructing a proper test without using MPP or multi-hop payments. My original test that triggered this problem only involved sending payments between two nodes connected by a single direct channel. However, when I searched the code related to blocked_monitor_updates, it seems only MPP and multi-hop payments can cause monitor updates to be blocked. This feels strange.

I've rebased this PR.

wpaulino · 2025-06-24T17:54:35Z

A revoke_and_ack monitor update can also become blocked until the PaymentSent event is handled.

TheBlueMatt · 2025-07-15T17:54:54Z

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).

whfuyn · 2025-06-13T14:32:31Z

When a channel is force-closed, there might be blocked monitor updates not yet applied. But latest_monitor_update_id has been incremented and assigned to these updates. This results in a panic when trying to apply the ChannelForceClosed update. Use the unblocked update id instead.

Resolves: #3857

ldk-reviews-bot · 2025-06-13T14:32:34Z

👋 Thanks for assigning @TheBlueMatt 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.

wpaulino

Thanks! This should work, but do you mind including a test?

There are other scenarios where we also increment by 1, but those should not result in a panic as they are queued in blocked_monitor_updates. The force close update is the only one we let fly through regardless of blocked_monitor_updates.

whfuyn · 2025-06-13T17:33:59Z

Got it! Will add a test later.

codecov · 2025-06-13T23:03:47Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.62%. Comparing base (c48e0a8) to head (ceb5a55).
Report is 4 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3858 +/- ##
==========================================
- Coverage 89.65% 89.62% -0.04% 
==========================================
Files 164 164 Lines 134658 134661 +3 Branches 134658 134661 +3 ==========================================
- Hits 120734 120688 -46 - Misses 11246 11292 +46 - Partials 2678 2681 +3

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

TheBlueMatt

Thanks. I think there's a few more changes I want to make to this pipeline but this change by itself looks good.

wpaulino · 2025-06-20T16:21:47Z

@whfuyn do you mind rebasing this? We're going to merge this as is to include it in a release and follow up with a test later.

When a channel is force-closed, there might be blocked monitor updates not yet applied. But `latest_monitor_update_id` has been incremented and assigned to these updates. This results in a panic when trying to apply the `ChannelForceClosed` update. Use the unblocked update id instead. Resolves: lightningdevkit#3857

whfuyn · 2025-06-24T04:38:27Z

@wpaulino Sorry for the late response.

I had some trouble constructing a proper test without using MPP or multi-hop payments. My original test that triggered this problem only involved sending payments between two nodes connected by a single direct channel. However, when I searched the code related to blocked_monitor_updates, it seems only MPP and multi-hop payments can cause monitor updates to be blocked. This feels strange.

I've rebased this PR.

wpaulino · 2025-06-24T17:54:35Z

A revoke_and_ack monitor update can also become blocked until the PaymentSent event is handled.

TheBlueMatt · 2025-07-15T17:54:54Z

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).

whfuyn · 2025-06-13T14:32:31Z

When a channel is force-closed, there might be blocked monitor updates not yet applied. But latest_monitor_update_id has been incremented and assigned to these updates. This results in a panic when trying to apply the ChannelForceClosed update. Use the unblocked update id instead.

Resolves: #3857

ldk-reviews-bot · 2025-06-13T14:32:34Z

👋 Thanks for assigning @TheBlueMatt 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.

wpaulino

Thanks! This should work, but do you mind including a test?

There are other scenarios where we also increment by 1, but those should not result in a panic as they are queued in blocked_monitor_updates. The force close update is the only one we let fly through regardless of blocked_monitor_updates.

whfuyn · 2025-06-13T17:33:59Z

Got it! Will add a test later.

codecov · 2025-06-13T23:03:47Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.62%. Comparing base (c48e0a8) to head (ceb5a55).
Report is 4 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3858 +/- ##
==========================================
- Coverage 89.65% 89.62% -0.04% 
==========================================
Files 164 164 Lines 134658 134661 +3 Branches 134658 134661 +3 ==========================================
- Hits 120734 120688 -46 - Misses 11246 11292 +46 - Partials 2678 2681 +3

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

TheBlueMatt

Thanks. I think there's a few more changes I want to make to this pipeline but this change by itself looks good.

wpaulino · 2025-06-20T16:21:47Z

@whfuyn do you mind rebasing this? We're going to merge this as is to include it in a release and follow up with a test later.

When a channel is force-closed, there might be blocked monitor updates not yet applied. But `latest_monitor_update_id` has been incremented and assigned to these updates. This results in a panic when trying to apply the `ChannelForceClosed` update. Use the unblocked update id instead. Resolves: lightningdevkit#3857

whfuyn · 2025-06-24T04:38:27Z

@wpaulino Sorry for the late response.

I had some trouble constructing a proper test without using MPP or multi-hop payments. My original test that triggered this problem only involved sending payments between two nodes connected by a single direct channel. However, when I searched the code related to blocked_monitor_updates, it seems only MPP and multi-hop payments can cause monitor updates to be blocked. This feels strange.

I've rebased this PR.

wpaulino · 2025-06-24T17:54:35Z

A revoke_and_ack monitor update can also become blocked until the PaymentSent event is handled.

TheBlueMatt · 2025-07-15T17:54:54Z

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).

whfuyn · 2025-06-13T14:32:31Z

When a channel is force-closed, there might be blocked monitor updates not yet applied. But latest_monitor_update_id has been incremented and assigned to these updates. This results in a panic when trying to apply the ChannelForceClosed update. Use the unblocked update id instead.

Resolves: #3857

ldk-reviews-bot · 2025-06-13T14:32:34Z

👋 Thanks for assigning @TheBlueMatt 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.

wpaulino

Thanks! This should work, but do you mind including a test?

There are other scenarios where we also increment by 1, but those should not result in a panic as they are queued in blocked_monitor_updates. The force close update is the only one we let fly through regardless of blocked_monitor_updates.

whfuyn · 2025-06-13T17:33:59Z

Got it! Will add a test later.

codecov · 2025-06-13T23:03:47Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.62%. Comparing base (c48e0a8) to head (ceb5a55).
Report is 4 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3858 +/- ##
==========================================
- Coverage 89.65% 89.62% -0.04% 
==========================================
Files 164 164 Lines 134658 134661 +3 Branches 134658 134661 +3 ==========================================
- Hits 120734 120688 -46 - Misses 11246 11292 +46 - Partials 2678 2681 +3

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

TheBlueMatt

Thanks. I think there's a few more changes I want to make to this pipeline but this change by itself looks good.

wpaulino · 2025-06-20T16:21:47Z

@whfuyn do you mind rebasing this? We're going to merge this as is to include it in a release and follow up with a test later.

When a channel is force-closed, there might be blocked monitor updates not yet applied. But `latest_monitor_update_id` has been incremented and assigned to these updates. This results in a panic when trying to apply the `ChannelForceClosed` update. Use the unblocked update id instead. Resolves: lightningdevkit#3857

whfuyn · 2025-06-24T04:38:27Z

@wpaulino Sorry for the late response.

I had some trouble constructing a proper test without using MPP or multi-hop payments. My original test that triggered this problem only involved sending payments between two nodes connected by a single direct channel. However, when I searched the code related to blocked_monitor_updates, it seems only MPP and multi-hop payments can cause monitor updates to be blocked. This feels strange.

I've rebased this PR.

wpaulino · 2025-06-24T17:54:35Z

A revoke_and_ack monitor update can also become blocked until the PaymentSent event is handled.

TheBlueMatt · 2025-07-15T17:54:54Z

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).

whfuyn · 2025-06-13T14:32:31Z

When a channel is force-closed, there might be blocked monitor updates not yet applied. But latest_monitor_update_id has been incremented and assigned to these updates. This results in a panic when trying to apply the ChannelForceClosed update. Use the unblocked update id instead.

Resolves: #3857

ldk-reviews-bot · 2025-06-13T14:32:34Z

👋 Thanks for assigning @TheBlueMatt 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.

wpaulino

Thanks! This should work, but do you mind including a test?

There are other scenarios where we also increment by 1, but those should not result in a panic as they are queued in blocked_monitor_updates. The force close update is the only one we let fly through regardless of blocked_monitor_updates.

whfuyn · 2025-06-13T17:33:59Z

Got it! Will add a test later.

codecov · 2025-06-13T23:03:47Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.62%. Comparing base (c48e0a8) to head (ceb5a55).
Report is 4 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3858 +/- ##
==========================================
- Coverage 89.65% 89.62% -0.04% 
==========================================
Files 164 164 Lines 134658 134661 +3 Branches 134658 134661 +3 ==========================================
- Hits 120734 120688 -46 - Misses 11246 11292 +46 - Partials 2678 2681 +3

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

TheBlueMatt

Thanks. I think there's a few more changes I want to make to this pipeline but this change by itself looks good.

wpaulino · 2025-06-20T16:21:47Z

@whfuyn do you mind rebasing this? We're going to merge this as is to include it in a release and follow up with a test later.

When a channel is force-closed, there might be blocked monitor updates not yet applied. But `latest_monitor_update_id` has been incremented and assigned to these updates. This results in a panic when trying to apply the `ChannelForceClosed` update. Use the unblocked update id instead. Resolves: lightningdevkit#3857

whfuyn · 2025-06-24T04:38:27Z

@wpaulino Sorry for the late response.

I had some trouble constructing a proper test without using MPP or multi-hop payments. My original test that triggered this problem only involved sending payments between two nodes connected by a single direct channel. However, when I searched the code related to blocked_monitor_updates, it seems only MPP and multi-hop payments can cause monitor updates to be blocked. This feels strange.

I've rebased this PR.

wpaulino · 2025-06-24T17:54:35Z

A revoke_and_ack monitor update can also become blocked until the PaymentSent event is handled.

TheBlueMatt · 2025-07-15T17:54:54Z

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).

whfuyn · 2025-06-13T14:32:31Z

When a channel is force-closed, there might be blocked monitor updates not yet applied. But latest_monitor_update_id has been incremented and assigned to these updates. This results in a panic when trying to apply the ChannelForceClosed update. Use the unblocked update id instead.

Resolves: #3857

ldk-reviews-bot · 2025-06-13T14:32:34Z

👋 Thanks for assigning @TheBlueMatt 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.

wpaulino

Thanks! This should work, but do you mind including a test?

There are other scenarios where we also increment by 1, but those should not result in a panic as they are queued in blocked_monitor_updates. The force close update is the only one we let fly through regardless of blocked_monitor_updates.

whfuyn · 2025-06-13T17:33:59Z

Got it! Will add a test later.

codecov · 2025-06-13T23:03:47Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.62%. Comparing base (c48e0a8) to head (ceb5a55).
Report is 4 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3858 +/- ##
==========================================
- Coverage 89.65% 89.62% -0.04% 
==========================================
Files 164 164 Lines 134658 134661 +3 Branches 134658 134661 +3 ==========================================
- Hits 120734 120688 -46 - Misses 11246 11292 +46 - Partials 2678 2681 +3

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

TheBlueMatt

Thanks. I think there's a few more changes I want to make to this pipeline but this change by itself looks good.

wpaulino · 2025-06-20T16:21:47Z

@whfuyn do you mind rebasing this? We're going to merge this as is to include it in a release and follow up with a test later.

When a channel is force-closed, there might be blocked monitor updates not yet applied. But `latest_monitor_update_id` has been incremented and assigned to these updates. This results in a panic when trying to apply the `ChannelForceClosed` update. Use the unblocked update id instead. Resolves: lightningdevkit#3857

whfuyn · 2025-06-24T04:38:27Z

@wpaulino Sorry for the late response.

I had some trouble constructing a proper test without using MPP or multi-hop payments. My original test that triggered this problem only involved sending payments between two nodes connected by a single direct channel. However, when I searched the code related to blocked_monitor_updates, it seems only MPP and multi-hop payments can cause monitor updates to be blocked. This feels strange.

I've rebased this PR.

wpaulino · 2025-06-24T17:54:35Z

A revoke_and_ack monitor update can also become blocked until the PaymentSent event is handled.

TheBlueMatt · 2025-07-15T17:54:54Z

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).

whfuyn · 2025-06-13T14:32:31Z

When a channel is force-closed, there might be blocked monitor updates not yet applied. But latest_monitor_update_id has been incremented and assigned to these updates. This results in a panic when trying to apply the ChannelForceClosed update. Use the unblocked update id instead.

Resolves: #3857

ldk-reviews-bot · 2025-06-13T14:32:34Z

👋 Thanks for assigning @TheBlueMatt 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.

wpaulino

Thanks! This should work, but do you mind including a test?

There are other scenarios where we also increment by 1, but those should not result in a panic as they are queued in blocked_monitor_updates. The force close update is the only one we let fly through regardless of blocked_monitor_updates.

whfuyn · 2025-06-13T17:33:59Z

Got it! Will add a test later.

codecov · 2025-06-13T23:03:47Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.62%. Comparing base (c48e0a8) to head (ceb5a55).
Report is 4 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3858 +/- ##
==========================================
- Coverage 89.65% 89.62% -0.04% 
==========================================
Files 164 164 Lines 134658 134661 +3 Branches 134658 134661 +3 ==========================================
- Hits 120734 120688 -46 - Misses 11246 11292 +46 - Partials 2678 2681 +3

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

TheBlueMatt

Thanks. I think there's a few more changes I want to make to this pipeline but this change by itself looks good.

wpaulino · 2025-06-20T16:21:47Z

@whfuyn do you mind rebasing this? We're going to merge this as is to include it in a release and follow up with a test later.

When a channel is force-closed, there might be blocked monitor updates not yet applied. But `latest_monitor_update_id` has been incremented and assigned to these updates. This results in a panic when trying to apply the `ChannelForceClosed` update. Use the unblocked update id instead. Resolves: lightningdevkit#3857

whfuyn · 2025-06-24T04:38:27Z

@wpaulino Sorry for the late response.

I had some trouble constructing a proper test without using MPP or multi-hop payments. My original test that triggered this problem only involved sending payments between two nodes connected by a single direct channel. However, when I searched the code related to blocked_monitor_updates, it seems only MPP and multi-hop payments can cause monitor updates to be blocked. This feels strange.

I've rebased this PR.

wpaulino · 2025-06-24T17:54:35Z

A revoke_and_ack monitor update can also become blocked until the PaymentSent event is handled.

TheBlueMatt · 2025-07-15T17:54:54Z

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).

whfuyn · 2025-06-13T14:32:31Z

When a channel is force-closed, there might be blocked monitor updates not yet applied. But latest_monitor_update_id has been incremented and assigned to these updates. This results in a panic when trying to apply the ChannelForceClosed update. Use the unblocked update id instead.

Resolves: #3857

ldk-reviews-bot · 2025-06-13T14:32:34Z

👋 Thanks for assigning @TheBlueMatt 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.

wpaulino

Thanks! This should work, but do you mind including a test?

There are other scenarios where we also increment by 1, but those should not result in a panic as they are queued in blocked_monitor_updates. The force close update is the only one we let fly through regardless of blocked_monitor_updates.

whfuyn · 2025-06-13T17:33:59Z

Got it! Will add a test later.

codecov · 2025-06-13T23:03:47Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.62%. Comparing base (c48e0a8) to head (ceb5a55).
Report is 4 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3858 +/- ##
==========================================
- Coverage 89.65% 89.62% -0.04% 
==========================================
Files 164 164 Lines 134658 134661 +3 Branches 134658 134661 +3 ==========================================
- Hits 120734 120688 -46 - Misses 11246 11292 +46 - Partials 2678 2681 +3

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

TheBlueMatt

Thanks. I think there's a few more changes I want to make to this pipeline but this change by itself looks good.

wpaulino · 2025-06-20T16:21:47Z

@whfuyn do you mind rebasing this? We're going to merge this as is to include it in a release and follow up with a test later.

When a channel is force-closed, there might be blocked monitor updates not yet applied. But `latest_monitor_update_id` has been incremented and assigned to these updates. This results in a panic when trying to apply the `ChannelForceClosed` update. Use the unblocked update id instead. Resolves: lightningdevkit#3857

whfuyn · 2025-06-24T04:38:27Z

@wpaulino Sorry for the late response.

I had some trouble constructing a proper test without using MPP or multi-hop payments. My original test that triggered this problem only involved sending payments between two nodes connected by a single direct channel. However, when I searched the code related to blocked_monitor_updates, it seems only MPP and multi-hop payments can cause monitor updates to be blocked. This feels strange.

I've rebased this PR.

wpaulino · 2025-06-24T17:54:35Z

A revoke_and_ack monitor update can also become blocked until the PaymentSent event is handled.

TheBlueMatt · 2025-07-15T17:54:54Z

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).

ldk-reviews-bot requested a review from jkczyz June 13, 2025 14:42

wpaulino reviewed Jun 13, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs Outdated

wpaulino removed the request for review from jkczyz June 13, 2025 16:25

whfuyn force-pushed the fix-update-id-gap branch from 446155b to 5e6e74cCompare June 13, 2025 17:23

TheBlueMatt previously approved these changes Jun 16, 2025
View reviewed changes

whfuyn dismissed TheBlueMatt’s stale review via 0866405June 24, 2025 04:06

whfuyn force-pushed the fix-update-id-gap branch from 5e6e74c to 0866405Compare June 24, 2025 04:06

whfuyn force-pushed the fix-update-id-gap branch from 0866405 to ceb5a55Compare June 24, 2025 04:11

wpaulino approved these changes Jun 24, 2025
View reviewed changes

wpaulino requested a review from TheBlueMatt June 24, 2025 17:54

TheBlueMatt added the backport 0.1 label Jun 24, 2025

TheBlueMatt approved these changes Jun 24, 2025
View reviewed changes

TheBlueMatt merged commit 0fe51c5 into lightningdevkit:mainJun 24, 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