Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add HTLCsTimedOut closing reason #2887

Merged
merged 1 commit into from
Mar 20, 2024

Conversation

benthecarman
Copy link
Contributor

@benthecarman benthecarman commented Feb 10, 2024

Closes #2283

Before a force closure from timed out HTLCs was treated the same as when
the user manually force closed the channel. This leads to various UX
issues. This adds a new ClosureReason called HTLCsTimedOut that
signifies that the closure was caused because the HTLCs timed out. To go
along with this, previously we'd always send "Channel force-closed" when
force closing the channel in the error message which was ambigous, now
we send the force closure reason so the peer can know why the channel
was closed.

Copy link

coderabbitai bot commented Feb 10, 2024

Walkthrough

The recent updates introduce a new closure reason, HTLCsTimedOut, for channel closures due to HTLC timeouts, refining the granularity of closure reasons. This change replaces the HolderForceClosed variant in specific scenarios, enhancing the accuracy of monitor events and closure reasons related to channel operations. The modifications span across multiple files, updating logic, tests, and event handling to reflect this new reason, ensuring a more precise representation of channel closure events.

Changes

Files Summary of Changes
.../chain/channelmonitor.rs, .../events/mod.rs Introduced HTLCsTimedOut in MonitorEvent and ClosureReason enums, replacing HolderForceClosed in specific contexts.
.../ln/channelmanager.rs, .../ln/functional_tests.rs, .../ln/monitor_tests.rs, .../ln/reorg_tests.rs Extended logic and tests to handle HTLCsTimedOut, updating closure reasons from HolderForceClosed to HTLCsTimedOut.

Assessment against linked issues

Objective Addressed Explanation
Add htlctimeout reason to closure reasons (#2283)
Break ClosureReason::CommitmentTxConfirmed Up Somewhat (#1488) The introduction of HTLCsTimedOut addresses the granularity issue in closure reasons due to HTLC timeouts.

Related issues

  • Issue Break ClosureReason::CommitmentTxConfirmed Up Somewhat #1488 could be linked to this PR, as the changes directly address the objective of breaking up the ClosureReason::CommitmentTxConfirmed by introducing a more specific reason related to HTLC timeouts, enhancing the detail and accuracy of closure reasons.

In the field of green, under the bright lights,
Chiefs and 49ers in a spirited fight.
🏈 Amidst the clash, a rabbit hops with glee,
For every touchdown, and each victory spree.
With a leap and a cheer for the game so bright,
May the best team win, in this thrilling night.
🎉 Let the Super Bowl bring joy, far and wide,
As we celebrate the sport, with pride side by side.

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit-tests for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit tests for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit tests.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • The JSON schema for the configuration file is available here.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between d70124c and 5f91790.
Files selected for processing (6)
  • lightning/src/chain/channelmonitor.rs (3 hunks)
  • lightning/src/events/mod.rs (3 hunks)
  • lightning/src/ln/channelmanager.rs (2 hunks)
  • lightning/src/ln/functional_tests.rs (6 hunks)
  • lightning/src/ln/monitor_tests.rs (1 hunks)
  • lightning/src/ln/reorg_tests.rs (2 hunks)
Files not reviewed due to errors (1)
  • lightning/src/ln/monitor_tests.rs (Error: unable to parse review)
Additional comments: 16
lightning/src/ln/reorg_tests.rs (2)
  • 468-468: The closure reason has been updated from HolderForceClosed to HTLCsTimedOut in the test_set_outpoints_partial_claiming function. This change aligns with the PR's objective to introduce a more accurate closure reason for channels force-closed due to HTLCs timing out.
  • 810-810: The closure reason has been updated from HolderForceClosed to HTLCsTimedOut in the do_test_retries_own_commitment_broadcast_after_reorg function. This change is consistent with the PR's goal to provide a more precise reason for channel closures related to timed-out HTLCs.
lightning/src/events/mod.rs (3)
  • 235-236: The addition of the HTLCsTimedOut variant to the ClosureReason enum correctly implements the new closing reason for channels closed due to HTLCs timing out.
  • 260-260: Ensure the description for HTLCsTimedOut in the Display implementation for ClosureReason is clear and accurately reflects the scenario it represents.
  • 278-278: The serialization of the new HTLCsTimedOut variant in the impl_writeable_tlv_based_enum_upgradable! macro for ClosureReason is correctly implemented.
lightning/src/chain/channelmonitor.rs (3)
  • 158-160: The addition of the HTLCsTimedOut variant to the MonitorEvent enum is correctly implemented. Ensure that all instances where HolderForceClosed was used for HTLC timeouts are updated to use HTLCsTimedOut.
  • 193-193: The serialization mapping for HTLCsTimedOut is correctly added with a unique identifier. Ensure that the removal of HolderForceClosed in this context and the reassignment of identifiers do not conflict with backward compatibility or data migration needs.
  • 2719-2719: The push of MonitorEvent::HTLCsTimedOut to pending_monitor_events is correctly implemented. Verify that this change aligns with the intended logic for handling timed-out HTLCs and that it triggers the appropriate downstream actions.
lightning/src/ln/functional_tests.rs (6)
  • 2420-2420: Ensure the updated closure reason HTLCsTimedOut is consistently applied across all relevant test scenarios, reflecting the intended behavior accurately.
  • 2433-2433: Verify that the change to HTLCsTimedOut accurately represents the scenario being tested, particularly in the context of the channel's state and the events leading to closure.
  • 5685-5685: Confirm that the test scenario and the use of HTLCsTimedOut as the closure reason are aligned with the expected outcomes when HTLCs time out.
  • 5716-5716: Check for consistency in the application of the HTLCsTimedOut reason across similar test cases, ensuring it accurately reflects the test's intent.
  • 5762-5762: Assess whether the introduction of HTLCsTimedOut in this scenario is appropriate, considering the specific conditions under which the channel is closed.
  • 8657-8657: Evaluate the correctness of using HTLCsTimedOut in this context, especially given the specific block height and the state of the channel at the time of closure.
lightning/src/ln/channelmanager.rs (2)
  • 7318-7318: The pattern matching for MonitorEvent::HolderForceClosed and MonitorEvent::HTLCsTimedOut is correctly implemented using a match arm with an or-pattern. This approach is concise and maintains readability.
  • 7336-7340: The logic to determine the ClosureReason based on the type of MonitorEvent is correctly implemented using a match expression. This ensures that the closure reason accurately reflects the event that triggered the channel closure.

@codecov-commenter
Copy link

codecov-commenter commented Feb 10, 2024

Codecov Report

Attention: Patch coverage is 80.39216% with 10 lines in your changes are missing coverage. Please review.

Project coverage is 89.16%. Comparing base (2c9dbb9) to head (9b5ebc4).
Report is 2 commits behind head on main.

Files Patch % Lines
lightning/src/chain/channelmonitor.rs 75.75% 6 Missing and 2 partials ⚠️
lightning/src/events/mod.rs 66.66% 1 Missing ⚠️
lightning/src/ln/channelmanager.rs 80.00% 1 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2887      +/-   ##
==========================================
- Coverage   89.18%   89.16%   -0.02%     
==========================================
  Files         117      117              
  Lines       95541    95574      +33     
  Branches    95541    95574      +33     
==========================================
+ Hits        85205    85220      +15     
- Misses       7840     7858      +18     
  Partials     2496     2496              

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

lightning/src/chain/channelmonitor.rs Outdated Show resolved Hide resolved
@@ -2712,7 +2716,7 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitorImpl<Signer> {
self.best_block.height(), self.best_block.height()
);
let mut claimable_outpoints = vec![commitment_package];
self.pending_monitor_events.push(MonitorEvent::HolderForceClosed(self.funding_info.0));
self.pending_monitor_events.push(MonitorEvent::HTLCsTimedOut(self.funding_info.0));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method won't always be called when HTLCs time out, we need to provide the reason as an argument to it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added, however, this didn't change any tests, a little suspect to me

lightning/src/events/mod.rs Outdated Show resolved Hide resolved
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between 0995de7 and cb51836.
Files selected for processing (6)
  • lightning/src/chain/channelmonitor.rs (10 hunks)
  • lightning/src/events/mod.rs (3 hunks)
  • lightning/src/ln/channelmanager.rs (2 hunks)
  • lightning/src/ln/functional_tests.rs (6 hunks)
  • lightning/src/ln/monitor_tests.rs (1 hunks)
  • lightning/src/ln/reorg_tests.rs (2 hunks)
Files skipped from review as they are similar to previous changes (6)
  • lightning/src/chain/channelmonitor.rs
  • lightning/src/events/mod.rs
  • lightning/src/ln/channelmanager.rs
  • lightning/src/ln/functional_tests.rs
  • lightning/src/ln/monitor_tests.rs
  • lightning/src/ln/reorg_tests.rs

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between a854ccb and 80df48d.
Files selected for processing (6)
  • lightning/src/chain/channelmonitor.rs (7 hunks)
  • lightning/src/events/mod.rs (3 hunks)
  • lightning/src/ln/channelmanager.rs (2 hunks)
  • lightning/src/ln/functional_tests.rs (6 hunks)
  • lightning/src/ln/monitor_tests.rs (1 hunks)
  • lightning/src/ln/reorg_tests.rs (2 hunks)
Files skipped from review as they are similar to previous changes (6)
  • lightning/src/chain/channelmonitor.rs
  • lightning/src/events/mod.rs
  • lightning/src/ln/channelmanager.rs
  • lightning/src/ln/functional_tests.rs
  • lightning/src/ln/monitor_tests.rs
  • lightning/src/ln/reorg_tests.rs

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between 36e434d and adab53c.
Files selected for processing (6)
  • lightning/src/chain/channelmonitor.rs (10 hunks)
  • lightning/src/events/mod.rs (3 hunks)
  • lightning/src/ln/channelmanager.rs (3 hunks)
  • lightning/src/ln/functional_tests.rs (6 hunks)
  • lightning/src/ln/monitor_tests.rs (1 hunks)
  • lightning/src/ln/reorg_tests.rs (2 hunks)
Files skipped from review as they are similar to previous changes (5)
  • lightning/src/events/mod.rs
  • lightning/src/ln/channelmanager.rs
  • lightning/src/ln/functional_tests.rs
  • lightning/src/ln/monitor_tests.rs
  • lightning/src/ln/reorg_tests.rs
Additional comments: 9
lightning/src/chain/channelmonitor.rs (9)
  • 53-53: The import statements and usage of various modules and traits appear to be correctly updated to support the new changes. However, ensure that all newly introduced dependencies are used efficiently and that there are no unnecessary imports after the changes.
  • 158-168: The introduction of the HolderForceClosedWithInfo variant in the MonitorEvent enum is a significant change. This variant enhances the detail provided when a channel is closed, including the closure reason, outpoint, and channel ID. Ensure that all instances where HolderForceClosed was previously used are correctly updated to use HolderForceClosedWithInfo where additional information about the closure is necessary or beneficial.
Verification successful

The review comment is consistent with the findings in the codebase. The introduction of HolderForceClosedWithInfo alongside the retention of HolderForceClosed suggests that the code has been updated to enhance detail where necessary while keeping the simpler variant for contexts where additional information is not required. This approach aligns with the recommendation to update instances of HolderForceClosed to HolderForceClosedWithInfo where additional closure details are beneficial. Without further context indicating that the retained uses of HolderForceClosed are inappropriate, the review comment is considered accurate.

Scripts Executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Search for instances of `HolderForceClosed` to ensure they are correctly replaced or retained based on context.
rg 'HolderForceClosed\('

Length of output: 766

* 198-202: The serialization logic for `HolderForceClosedWithInfo` is correctly updated to include the new fields. However, ensure that the versioning and backward compatibility are maintained, especially when dealing with nodes that may not recognize the new variant.
Verification successful

To verify the serialization logic for HolderForceClosedWithInfo and its impact on backward compatibility, we need to inspect the specific serialization and deserialization code for this variant, including how versioning is handled. The provided rg output does not directly address these aspects. A more targeted search is required.


The serialization logic for HolderForceClosedWithInfo has been correctly updated to include new fields (reason, outpoint, channel_id). Backward compatibility is maintained by writing both HolderForceClosed and HolderForceClosedWithInfo events, ensuring that older versions can still process the HolderForceClosed events. This approach addresses the concerns raised in the review comment.

Scripts Executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Verify that the serialization logic for older versions is not affected by the new changes.
rg 'write_all' --context=5

Length of output: 42357



Script:

#!/bin/bash
# Locate the serialization and deserialization logic for HolderForceClosedWithInfo, focusing on versioning and backward compatibility.
rg 'HolderForceClosedWithInfo' -A 30 -B 5

Length of output: 19870

* 1078-1078: The filtering logic in serialization to include `HolderForceClosedWithInfo` events is correctly updated. This ensures that the new event type is considered when counting and serializing pending monitor events. * 1088-1091: The comment about maintaining backward compatibility by writing a `HolderForceClosed` event along with the `HolderForceClosedWithInfo` event is crucial. This approach ensures that older nodes can still process events, albeit with less detail. It's important to verify that this deduplication does not introduce any unintended side effects in the event handling logic.
Verification successful

The review comment's concerns about maintaining backward compatibility by writing a HolderForceClosed event along with the HolderForceClosedWithInfo event and ensuring this deduplication does not introduce unintended side effects in the event handling logic are addressed in the code. The implementation in channelmonitor.rs and the handling in channelmanager.rs demonstrate a careful approach to backward compatibility and deduplication. The deduplication logic, which prefers HolderForceClosedWithInfo over HolderForceClosed when both are present, is designed to avoid side effects by retaining the most detailed event type. This approach ensures older nodes can process events with the available information without duplicating events, aligning with the comment's intent.

Scripts Executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Verify that the deduplication logic in the reader does not introduce any side effects.
rg 'HolderForceClosedWithInfo' --context=10

Length of output: 12934

* 2763-2773: The logic to generate a `HolderForceClosedWithInfo` event based on the `is_htlc_timeout` flag is a key part of the changes. This logic correctly captures the intent of providing more detailed closure reasons. Ensure that the `is_htlc_timeout` flag is accurately set in all relevant contexts to reflect the actual reason for channel closure. * 2810-2810: The call to `generate_claimable_outpoints_and_watch_outputs` with a hardcoded `false` value for the `is_htlc_timeout` parameter in this context seems appropriate, assuming this is a scenario where HTLC timeout is not the cause of channel closure. However, ensure that the use of hardcoded boolean values is consistent with the intended logic across all calls to this function. * 3813-3813: The conditional call to `generate_claimable_outpoints_and_watch_outputs` with `true` indicates a scenario where HTLCs timing out is the reason for generating new outpoints and outputs. This is a direct application of the new logic introduced by the PR. Ensure that the condition `should_broadcast` accurately reflects scenarios where HTLCs have timed out.
Verification successful

To accurately verify the original comment, we need to examine the implementation of generate_claimable_outpoints_and_watch_outputs and understand how should_broadcast is determined within that context, especially in relation to HTLC timeouts. The provided script output does not directly link should_broadcast to HTLC timeout scenarios in the context of this method. Further investigation into the method's implementation and the conditions under which should_broadcast is set to true is necessary.


The examination of the generate_claimable_outpoints_and_watch_outputs method and its usage of the is_htlc_timeout parameter suggests that the method is designed to handle different scenarios, including those where HTLCs are timing out. The decision to generate new outpoints and outputs based on HTLC timeouts is influenced by the should_broadcast condition, which is determined by the self.should_broadcast_holder_commitment_txn(logger) method. This setup aligns with the original comment's concern about accurately capturing scenarios where HTLCs have timed out.

However, without explicit details on the implementation of should_broadcast_holder_commitment_txn and its direct relation to HTLC timeouts, a full verification of the original comment cannot be conclusively made. The evidence suggests a logical connection between HTLC timeouts and the generation of new outpoints and outputs, but the specific mechanics of this relationship are not fully detailed in the provided output.

Scripts Executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Verify that the `should_broadcast` condition accurately captures scenarios of HTLC timeouts.
rg 'should_broadcast' --context=10

Length of output: 27548



Script:

#!/bin/bash
# Examine the implementation of generate_claimable_outpoints_and_watch_outputs and its usage of should_broadcast
rg "generate_claimable_outpoints_and_watch_outputs" --context=10

Length of output: 5334

* 4640-4649: The deduplication logic to remove `HolderForceClosed` events if `HolderForceClosedWithInfo` events are also present is a thoughtful addition for maintaining backward compatibility while transitioning to the new event type. Ensure that this logic does not inadvertently remove relevant events in scenarios where both event types are legitimately present for different reasons.
Verification successful

The deduplication logic in question is specifically designed for handling backward compatibility during the deserialization process of ChannelMonitor instances. It ensures that redundant HolderForceClosed events are removed when both HolderForceClosed and HolderForceClosedWithInfo events are present due to historical data. This logic does not operate during runtime event processing but rather during the loading of data, addressing concerns about inadvertently removing relevant events in complex scenarios. Based on the provided context and the analysis of how pending_monitor_events is used across the codebase, the implementation appears to correctly handle the deduplication of events for backward compatibility purposes.

Scripts Executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Verify that the deduplication logic does not remove relevant events in complex scenarios.
rg 'pending_monitor_events' --context=10

Length of output: 65314

Copy link
Contributor

@wpaulino wpaulino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just a few minor comments

lightning/src/chain/channelmonitor.rs Outdated Show resolved Hide resolved
lightning/src/chain/channelmonitor.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/events/mod.rs Show resolved Hide resolved
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between 36e434d and df6ed25.
Files selected for processing (6)
  • lightning/src/chain/channelmonitor.rs (10 hunks)
  • lightning/src/events/mod.rs (4 hunks)
  • lightning/src/ln/channelmanager.rs (3 hunks)
  • lightning/src/ln/functional_tests.rs (6 hunks)
  • lightning/src/ln/monitor_tests.rs (1 hunks)
  • lightning/src/ln/reorg_tests.rs (2 hunks)
Files skipped from review as they are similar to previous changes (6)
  • lightning/src/chain/channelmonitor.rs
  • lightning/src/events/mod.rs
  • lightning/src/ln/channelmanager.rs
  • lightning/src/ln/functional_tests.rs
  • lightning/src/ln/monitor_tests.rs
  • lightning/src/ln/reorg_tests.rs

@TheBlueMatt
Copy link
Collaborator

Any update on this @benthecarman? Would be happy to have someone working ft on LDK take this over if you don't have the time.

@benthecarman
Copy link
Contributor Author

Sorry have been traveling, back in action this week though, will get to it

@TheBlueMatt
Copy link
Collaborator

Thanks!

TheBlueMatt
TheBlueMatt previously approved these changes Mar 19, 2024
Copy link
Contributor

@jkczyz jkczyz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly LGTM

lightning/src/chain/channelmonitor.rs Show resolved Hide resolved
@@ -155,6 +155,17 @@ pub enum MonitorEvent {
/// A monitor event containing an HTLCUpdate.
HTLCEvent(HTLCUpdate),

/// Indicates we broadcasted the channel's latest commitment transaction and thus closed the
/// channel. Holds information about the channel and why it was closed.
HolderForceClosedWithInfo {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we name this HolderForceClosed and rename the existing variant to HolderForceClosedWithoutInfo instead? I'm somewhat indifferent on doing this now but seems like the one used going forward shouldn't have a suffix.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imo it makes more sense like this and it can be renamed when HolderForceClosed is removed

Comment on lines +7395 to +7399
let reason = if let MonitorEvent::HolderForceClosedWithInfo { reason, .. } = monitor_event {
reason
} else {
ClosureReason::HolderForceClosed
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you expand upon this change in the commit message? Seems the previous reason used was incorrect?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

lightning/src/chain/channelmonitor.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Show resolved Hide resolved
lightning/src/chain/channelmonitor.rs Show resolved Hide resolved
Before a force closure from timed out HTLCs was treated the same as when
the user manually force closed the channel. This leads to various UX
issues. This adds a new `ClosureReason` called `HTLCsTimedOut` that
signifies that the closure was caused because the HTLCs timed out. To go
along with this, previously we'd always send "Channel force-closed" when
force closing the channel in the error message which was ambigous, now
we send the force closure reason so the peer can know why the channel
was closed.
lightning/src/chain/channelmonitor.rs Show resolved Hide resolved
lightning/src/chain/channelmonitor.rs Show resolved Hide resolved
@TheBlueMatt TheBlueMatt merged commit 9b7bbe1 into lightningdevkit:main Mar 20, 2024
12 of 16 checks passed
@benthecarman benthecarman deleted the htlc-timeout branch March 20, 2024 18:14
k0k0ne pushed a commit to bitlightlabs/rust-lightning that referenced this pull request Sep 30, 2024
v0.0.123 - May 08, 2024 - "BOLT12 Dust Sweeping"

API Updates
===========

 * To reduce risk of force-closures and improve HTLC reliability the default
   dust exposure limit has been increased to
   `MaxDustHTLCExposure::FeeRateMultiplier(10_000)`. Users with existing
   channels might want to consider using
   `ChannelManager::update_channel_config` to apply the new default (lightningdevkit#3045).
 * `ChainMonitor::archive_fully_resolved_channel_monitors` is now provided to
   remove from memory `ChannelMonitor`s that have been fully resolved on-chain
   and are now not needed. It uses the new `Persist::archive_persisted_channel`
   to inform the storage layer that such a monitor should be archived (lightningdevkit#2964).
 * An `OutputSweeper` is now provided which will automatically sweep
   `SpendableOutputDescriptor`s, retrying until the sweep confirms (lightningdevkit#2825).
 * After initiating an outbound channel, a peer disconnection no longer results
   in immediate channel closure. Rather, if the peer is reconnected before the
   channel times out LDK will automatically retry opening it (lightningdevkit#2725).
 * `PaymentPurpose` now has separate variants for BOLT12 payments, which
   include fields from the `invoice_request` as well as the `OfferId` (lightningdevkit#2970).
 * `ChannelDetails` now includes a list of in-flight HTLCs (lightningdevkit#2442).
 * `Event::PaymentForwarded` now includes `skimmed_fee_msat` (lightningdevkit#2858).
 * The `hashbrown` dependency has been upgraded and the use of `ahash` as the
   no-std hash table hash function has been removed. As a consequence, LDK's
   `Hash{Map,Set}`s no longer feature several constructors when LDK is built
   with no-std; see the `util::hash_tables` module instead. On platforms that
   `getrandom` supports, setting the `possiblyrandom/getrandom` feature flag
   will ensure hash tables are resistant to HashDoS attacks, though the
   `possiblyrandom` crate should detect most common platforms (lightningdevkit#2810, lightningdevkit#2891).
 * `ChannelMonitor`-originated requests to the `ChannelSigner` can now fail and
   be retried using `ChannelMonitor::signer_unblocked` (lightningdevkit#2816).
 * `SpendableOutputDescriptor::to_psbt_input` now includes the `witness_script`
   where available as well as new proprietary data which can be used to
   re-derive some spending keys from the base key (lightningdevkit#2761, lightningdevkit#3004).
 * `OutPoint::to_channel_id` has been removed in favor of
   `ChannelId::v1_from_funding_outpoint` in preparation for v2 channels with a
   different `ChannelId` derivation scheme (lightningdevkit#2797).
 * `PeerManager::get_peer_node_ids` has been replaced with `list_peers` and
   `peer_by_node_id`, which provide more details (lightningdevkit#2905).
 * `Bolt11Invoice::get_payee_pub_key` is now provided (lightningdevkit#2909).
 * `Default[Message]Router` now take an `entropy_source` argument (lightningdevkit#2847).
 * `ClosureReason::HTLCsTimedOut` has been separated out from
   `ClosureReason::HolderForceClosed` as it is the most common case (lightningdevkit#2887).
 * `ClosureReason::CooperativeClosure` is now split into
   `{Counterparty,Locally}Initiated` variants (lightningdevkit#2863).
 * `Event::ChannelPending::channel_type` is now provided (lightningdevkit#2872).
 * `PaymentForwarded::{prev,next}_user_channel_id` are now provided (lightningdevkit#2924).
 * Channel init messages have been refactored towards V2 channels (lightningdevkit#2871).
 * `BumpTransactionEvent` now contains the channel and counterparty (lightningdevkit#2873).
 * `util::scid_utils` is now public, with some trivial utilities to examine
   short channel ids (lightningdevkit#2694).
 * `DirectedChannelInfo::{source,target}` are now public (lightningdevkit#2870).
 * Bounds in `lightning-background-processor` were simplified by using
   `AChannelManager` (lightningdevkit#2963).
 * The `Persist` impl for `KVStore` no longer requires `Sized`, allowing for
   the use of `dyn KVStore` as `Persist` (lightningdevkit#2883, lightningdevkit#2976).
 * `From<PaymentPreimage>` is now implemented for `PaymentHash` (lightningdevkit#2918).
 * `NodeId::from_slice` is now provided (lightningdevkit#2942).
 * `ChannelManager` deserialization may now fail with `DangerousValue` when
    LDK's persistence API was violated (lightningdevkit#2974).

Bug Fixes
=========

 * Excess fees on counterparty commitment transactions are now included in the
   dust exposure calculation. This lines behavior up with some cases where
   transaction fees can be burnt, making them effectively dust exposure (lightningdevkit#3045).
 * `Future`s used as an `std::...::Future` could grow in size unbounded if it
   was never woken. For those not using async persistence and using the async
   `lightning-background-processor`, this could cause a memory leak in the
   `ChainMonitor` (lightningdevkit#2894).
 * Inbound channel requests that fail in
   `ChannelManager::accept_inbound_channel` would previously have stalled from
   the peer's perspective as no `error` message was sent (lightningdevkit#2953).
 * Blinded path construction has been tuned to select paths more likely to
   succeed, improving BOLT12 payment reliability (lightningdevkit#2911, lightningdevkit#2912).
 * After a reorg, `lightning-transaction-sync` could have failed to follow a
   transaction that LDK needed information about (lightningdevkit#2946).
 * `RecipientOnionFields`' `custom_tlvs` are now propagated to recipients when
   paying with blinded paths (lightningdevkit#2975).
 * `Event::ChannelClosed` is now properly generated and peers are properly
   notified for all channels that as a part of a batch channel open fail to be
   funded (lightningdevkit#3029).
 * In cases where user event processing is substantially delayed such that we
   complete multiple round-trips with our peers before a `PaymentSent` event is
   handled and then restart without persisting the `ChannelManager` after having
   persisted a `ChannelMonitor[Update]`, on startup we may have `Err`d trying to
   deserialize the `ChannelManager` (lightningdevkit#3021).
 * If a peer has relatively high latency, `PeerManager` may have failed to
   establish a connection (lightningdevkit#2993).
 * `ChannelUpdate` messages broadcasted for our own channel closures are now
   slightly more robust (lightningdevkit#2731).
 * Deserializing malformed BOLT11 invoices may have resulted in an integer
   overflow panic in debug builds (lightningdevkit#3032).
 * In exceedingly rare cases (no cases of this are known), LDK may have created
   an invalid serialization for a `ChannelManager` (lightningdevkit#2998).
 * Message processing latency handling BOLT12 payments has been reduced (lightningdevkit#2881).
 * Latency in processing `Event::SpendableOutputs` may be reduced (lightningdevkit#3033).

Node Compatibility
==================

 * LDK's blinded paths were inconsistent with other implementations in several
   ways, which have been addressed (lightningdevkit#2856, lightningdevkit#2936, lightningdevkit#2945).
 * LDK's messaging blinded paths now support the latest features which some
   nodes may begin relying on soon (lightningdevkit#2961).
 * LDK's BOLT12 structs have been updated to support some last-minute changes to
   the spec (lightningdevkit#3017, lightningdevkit#3018).
 * CLN v24.02 requires the `gossip_queries` feature for all peers, however LDK
   by default does not set it for those not using a `P2PGossipSync` (e.g. those
   using RGS). This change was reverted in CLN v24.02.2 however for now LDK
   always sets the `gossip_queries` feature. This change is expected to be
   reverted in a future LDK release (lightningdevkit#2959).

Security
========
0.0.123 fixes a denial-of-service vulnerability which we believe to be reachable
from untrusted input when parsing invalid BOLT11 invoices containing non-ASCII
characters.
 * BOLT11 invoices with non-ASCII characters in the human-readable-part may
   cause an out-of-bounds read attempt leading to a panic (lightningdevkit#3054). Note that all
   BOLT11 invoices containing non-ASCII characters are invalid.

In total, this release features 150 files changed, 19307 insertions, 6306
deletions in 360 commits since 0.0.121 from 17 authors, in alphabetical order:

 * Arik Sosman
 * Duncan Dean
 * Elias Rohrer
 * Evan Feenstra
 * Jeffrey Czyz
 * Keyue Bao
 * Matt Corallo
 * Orbital
 * Sergi Delgado Segura
 * Valentine Wallace
 * Willem Van Lint
 * Wilmer Paulino
 * benthecarman
 * jbesraa
 * olegkubrakov
 * optout
 * shaavan
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add htlctimeout reason to closure reasons
6 participants