rust-lightning

This commit is a routine internal cleanup in the Lightning Dev Kit's gossip message handling code. It removes a method that let users set a UTXO (unspent transaction output) lookup provider after the object was created, because the codebase no longer needs that late-setup workaround. The change only affects how the code is structured and how tests are set up; it does not fix a security bug or introduce a known vulnerability.

This commit refactors how Lightning Dev Kit handles background verification of gossip data (the routing information nodes share). Previously, the gossip verifier, the gossip sync component, and the peer manager held circular references to each other, which could prevent memory from being freed when LDK was unloaded. The change replaces those circular references with a notification mechanism: the background processor now waits directly for a 'validation completed' signal. This is primarily a memory-leak and architectural cleanup, not a direct exploit fix, but it removes a design that could keep resources alive unexpectedly.

This commit refactors how Lightning Dev Kit handles asynchronous checks of Bitcoin transaction outputs (UTXOs) used to validate gossip messages about the network graph. Previously, resolving these checks required direct circular references between components, which could cause memory leaks when LDK was unloaded. The new design uses a notification/polling pattern instead, making the code cleaner and avoiding leaked objects. It is a defensive architectural fix rather than a patch for an active exploit.

This commit is a small internal cleanup in the Lightning Dev Kit Rust library. It changes how background tasks are notified when an asynchronous UTXO (unspent transaction output) lookup finishes, so that circular references between gossip-sync objects can eventually be removed. There is no direct security vulnerability being fixed here; it is a design refactor that may help prevent memory leaks in the future.

This commit is a straightforward internal code cleanup in the Lightning Dev Kit Rust library. It replaces several hand-written helper functions for waiting on 2, 3, or 4 background tasks with a single helper that accepts any number of tasks using Rust's standard iterator features. There is no indication this fixes a security bug or changes user-facing behavior.

This change turns on automatic cleanup of old, resolved Lightning channel monitoring data by default in LDK's background processor. Previously this cleanup existed but was not enabled by default because archiving a monitor too early could risk losing funds. After broader real-world use, the developers now enable it automatically on a timer, which helps prevent denial-of-service/resource-exhaustion issues caused by keeping stale monitors around forever. The commit itself is a defensive hardening change, not an active vulnerability fix.

This commit is a small internal cleanup in the Lightning Dev Kit's channel manager. It replaces calls to a more general force-close helper with a more specific helper meant for channels that have not yet been funded. The change removes duplicated parameters and makes the code clearer, but there is no direct evidence in the commit or supplied references that it fixes an active security vulnerability or changes externally observable behavior.

This commit only renames several internal helper methods in the Lightning channel manager to make their purpose clearer (for example, 'convert_channel_err' becomes 'locked_handle_force_close'). No behavior changes, security fixes, or bug fixes are present in the diff.

This commit is a minor code cleanup that changes how two error messages are formatted in Rust. It uses a newer, more concise syntax for embedding variables inside strings. There is no functional change and no security relevance.

This is a routine fix to an internal GitHub Actions CI workflow. The change ensures that when testing pull requests against the LDK Node project, the local copy of rust-lightning is patched in correctly even when LDK Node depends on it via a Git URL rather than crates.io. It has no effect on shipped code or user-facing security.

This commit simply moves a group of channel-closing helper methods to a different location within the same file. No code behavior was changed, so it has no security impact on its own.

This commit is a simple code cleanup: it turns an internal macro (a reusable code snippet) into a regular Rust method. The actual behavior of the program does not change. There is no security fix or vulnerability here.

This commit only adds one line to a shell script used in continuous integration. It tells the Clippy code-analysis tool to ignore a newly introduced lint about assertions on constant values. The change does not modify any actual Rust source code, runtime behavior, or security-sensitive logic.

This commit is purely a code-formatting cleanup. It uses rustfmt to rewrap long function signatures, break up long macro invocations, and adjust indentation in a single Rust source file. No logic, behavior, or security properties of the code were changed.

This commit simply removes formatting-suppression annotations from several Rust methods. It does not change any executable code, logic, or security behavior. It is a code-style cleanup with no security relevance.

This commit is a straightforward internal code cleanup: it turns a Rust macro named convert_channel_err into a regular method on the ChannelManager struct. The logic inside the conversion stays the same, and all call sites are updated to use the new method. There is no change to user-facing behavior, network protocol handling, or security-sensitive checks.

This commit is a straightforward code cleanup: it turns a small Rust macro used only for funded-channel error handling into a regular method. The behavior appears unchanged; the same internal function is called with the same arguments. There is no indication this fixes or introduces a security issue.

This is a small internal code cleanup in the Lightning Dev Kit's Rust implementation. It removes a rarely-used macro branch and replaces two calls with direct function calls. There is no visible security change: the same function runs, with the same arguments, in the same order. The commit message and diff give no indication of a bug fix or security issue.

This commit is a straightforward code cleanup: it turns a small macro used only for cooperative channel closures into a regular Rust method. No behavior changes, no security fixes, and no bug fixes are visible in the diff.

This commit is a simple code cleanup: it turns two standalone helper functions into methods attached to the ChannelManager struct. The actual logic inside the functions is copied almost verbatim, with only mechanical changes like replacing `cm.get_cm()` and `cm.logger` with `self.logger`, and `cm.short_to_chan_info` with `self.short_to_chan_info`. There is no change to behavior, no bug fix, and no security improvement or regression visible in the diff.

This commit adds new automated tests to make sure that payment forwarding state created by an older version (0.2) of the Lightning Dev Kit library still works correctly after upgrading to the upcoming 0.3 version. It does not change production code and is not a security fix or vulnerability.

This commit is a preparatory internal refactoring in the Lightning Dev Kit's rust-lightning code. It changes how the ChannelManager reconstructs a list of pending forwarded payments when it is loaded from disk, gathering the data from individual channels instead of relying on a previously stored map. The new reconstructed map is created but not yet used in this commit; a follow-up commit will start using it. There is no direct security vulnerability introduced here, but the change is part of a larger effort to avoid dangerous inconsistencies between two key data structures (ChannelManager and ChannelMonitor) that could lead to forced channel closures if they get out of sync.

This commit changes how a Lightning node rebuilds its internal list of in-flight forwarded payments when it restarts. The goal is to eventually stop requiring a separate snapshot of the ChannelManager, instead reconstructing state from the more-reliable ChannelMonitor. The patch adds logic to avoid duplicate HTLC entries when both old and new reconstruction sources are present, and fixes a test helper so reload tests use the node's actual configuration. It is a forward-looking infrastructure change with safety implications if the deduplication logic is wrong, but it does not appear to introduce a remotely exploitable vulnerability.

This commit changes how the Lightning Dev Kit stores information about incoming payment commitments inside a channel. It keeps a copy of the original 'update_add' message alongside committed inbound HTLCs so that, after a restart, the node can rebuild its internal payment-forwarding maps from Channel and ChannelMonitor data rather than relying on the separate ChannelManager persistence. The change is framed by the authors as a reliability improvement to avoid force-closure when ChannelManager and ChannelMonitor get out of sync on restart. It is not a direct security patch and does not appear to fix an active exploit, but it touches consensus-adjacent state and serialization, so mistakes here could affect funds safety.

This commit is a small internal code cleanup in the Lightning Dev Kit's channel manager. It pulls out duplicated code for creating an 'HTLC intercepted' event into a shared helper function. The change does not fix a security bug and does not alter user-facing behavior; it is preparation for a future reliability improvement around restarting the channel manager without losing track of intercepted payments.