rust-lightning

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.

This is a small internal code cleanup in the Lightning Dev Kit's channel manager. It changes how an in-memory data structure (tracking intercepted HTLCs) is initialized when reading persisted state, so that a future commit can be simpler. There is no indication this fixes a security bug or changes externally observable behavior.

This commit is a simple internal renaming of several data structures in the Lightning node's channel manager. It changes variable names like `forward_htlcs` to `forward_htlcs_legacy` and adds comments explaining that these maps are being kept for backward compatibility while the project moves toward rebuilding this state from channel monitors instead. There is no functional behavior change, no bug fix, and no security patch in the diff.

This commit is a simple internal code cleanup: it pulls out a small block of duplicate logic into a helper function. The behavior of the program is unchanged; no security issue is introduced or fixed.

This commit is a straightforward internal code cleanup: it replaces a Rust macro named `handle_error!` with an equivalent method `handle_error()` on the `ChannelManager` struct. The logic inside the function is identical to the macro, and all call sites are updated to use the new method syntax. There is no change to behavior, no bug fix, and no security relevance.

This commit is a straightforward code cleanup in the Lightning Dev Kit's channel manager. It rewrites an error-handling function to use Rust's `map_err` helper instead of an explicit `match` on `Ok`/`Err`. The behavior is unchanged: the same channel-closing logic, logging, and peer-message generation runs. No security issue is present.

This commit is a pure internal refactoring of the project's test code. It removes a Rust macro named `check_added_monitors!` and replaces every call with an identically-named regular function `check_added_monitors(...)`. There is no change to production code, user-facing behavior, or security logic. It only affects how tests are written.

This commit only adds explanatory documentation comments to an existing internal test helper function. No code behavior was changed, so it cannot introduce or fix a security issue on its own.

This commit is a pure code cleanup and formatting follow-up after rustfmt was run. It renames a local variable from counterparty_node_id to cp_node_id and flattens deeply nested if-let blocks into a more readable match/early-return style. There is no functional change to the program's behavior.

This commit only changes a package version number in a configuration file (from 0.2.0+git to 0.3.0+git) to satisfy an automated SemVer compatibility check. It does not change any code, fix any bug, or alter any behavior.

This commit fixes a Rust library API visibility problem. A data type called AttributionData was supposed to be publicly usable because it appears in public Lightning protocol messages, but it was accidentally kept internal due to how Rust re-exports work. The change makes the containing module public so users can actually reference the type. It is a usability/API completeness fix, not a security vulnerability fix.

This commit is a code cleanup in the Lightning Dev Kit's peer message handling. It changes internal functions so they consistently use a single `wire::Message` wrapper type when preparing messages to send, instead of accepting many different message types directly. It also switches from borrowing messages to moving them. There is no obvious security bug being fixed; it is primarily a maintainability and type-safety improvement.

This is a routine internal code cleanup in the Lightning Dev Kit's message serialization layer. It removes an old helper function (`wire::write`) and a macro (`encode_msg!`), replacing them with direct calls to `Message::write`/`Type::write`. The change does not alter the wire format or add any new behavior; it is purely a refactoring to simplify the code.

This commit fixes a bug in rust-lightning where zero-confirmation (0-conf) Lightning channels were unnecessarily force-closed when their funding transaction was temporarily reorged out of the blockchain. For 0-conf channels, users already trust the funder, so a reorg should not trigger a force close. The fix tracks the old channel ID as a historical ID so payments can still flow, and only force-closes channels that required at least one confirmation. Regular 1+ confirmation channels still force-close on reorg, as before, to protect against double-spend risk.

This commit adds a missing safety check in the Lightning Dev Kit's channel manager. Before allowing a user to initiate a channel splice, it now verifies that the connected peer has advertised support for splicing and for quiescence (a required prerequisite). Without this check, a node could try to start a splice with a peer that doesn't understand the protocol, likely causing the operation to fail or the channel to close unexpectedly. The fix is defensive and prevents API misuse rather than fixing an active remote exploit.

This commit fixes a scheduling bug in a background task runner used by the Lightning Dev Kit. Previously, the runner could keep handling other background work forever and ignore a request to shut down, as long as other work kept appearing. Now it checks the shutdown timer first, so it stops promptly when asked. This is a reliability/availability fix rather than a direct theft-of-funds bug, but in a payment system, failing to shut down on time can contribute to operational problems or resource exhaustion.