rust-lightning

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

This commit only updates version numbers in package configuration files after a software release. It changes references from version 0.2.0 to 0.3.0 across several related crates and bumps the main crate's version label from 0.2.0+git to 0.3.0+git. There are no code changes, no security fixes, and no behavior changes.

This commit only updates the project's CHANGELOG.md file. It adds the release date for version 0.2, adds a note that Bitcoin Knots blocks certain transactions by default, clarifies documentation about a socket method's behavior, adds release statistics and contributor names, and adds a new section for version 0.1.8 bug fixes. No actual code was changed.

This commit is purely a code-formatting cleanup. It removes a #[rustfmt::skip] annotation and lets Rust's automatic formatter reformat one function in the Lightning channel manager. No logic, behavior, or security properties of the code are changed.

This commit only adds and adjusts log messages to help developers debug channel state. It does not change program logic, permissions, or data handling. There is no security issue here.

This commit simply adds another build-output directory to the project's .gitignore file. It has no effect on running code, user data, or security.

This commit only changes how an internal test helper is exposed. It renames a private test-only function and makes it callable from integration tests, with no effect on normal production code. There is no security issue.

This commit adds three new error-code names to an existing internal lookup table that converts numeric codes into human-readable failure reasons. It is a straightforward code-completion change with no visible security effect.

This commit only changes the text of an error message. It does not alter any logic, checks, or behavior. The old message was misleading because it suggested a validation failure, while the actual failure is an arithmetic underflow when calculating the next hop's amount or timelock. The new message describes the real cause more accurately.

This commit fixes a bug in the Lightning Dev Kit (LDK) where a channel could get stuck waiting on itself after a multi-path payment (MPP) was claimed. Previously, when a monitor update completed but another monitor update was blocked, LDK skipped important follow-up actions, such as emitting the PaymentClaimed event and releasing held HTLCs. The fix ensures these follow-up actions run even when the channel still has blocked monitor updates, preventing channels from hanging.

This commit only updates documentation comments in the source code. It explains that certain channel details stay the same during a splice until the splice is finalized. No code behavior was changed, so there is no security issue.