rust-lightning

This commit is a performance-focused internal refactor in the Lightning Dev Kit. It moves the freeing of 'holding cells' (temporary queues of pending payment updates inside a channel) from the message-sending path to the moment the channel state changes. The goal is to avoid doing extra work, including possible disk I/O, while the node is trying to send messages. The commit does not fix a known exploit, but it changes how and when channel state is updated and persisted, which has security-adjacent implications for consistency and denial-of-service.

This commit adds a new 'dummy hop' feature for blinded payment routes in LDK. It lets senders insert fake intermediate routing steps before the real recipient in a private Lightning payment path. Because these dummy hops look and behave like real forwarding nodes, outside observers watching timing or route structure have a harder time figuring out where the payment actually ends up. The change is defensive: it strengthens recipient privacy rather than fixing an active bug or vulnerability.

This commit only adds an extra assertion to an existing test case. It checks that the change output in a splicing transaction has the expected value. There is no change to production code, no bug fix, and no security-relevant behavior change.

This commit refactors a Bitcoin transaction fee and change-calculation routine to use the strongly-typed Amount type instead of raw u64 satoshi values. The main functional change is that input/output totals now use checked_add/checked_sub, which prevents silent overflow/underflow wraparound when summing large amounts. It also tightens one subtraction so an unexpected negative value panics instead of silently wrapping. This is a defensive hardening change rather than a fix for a known exploitable bug.

This commit is a straightforward internal code cleanup. It changes how a data structure called SpliceContribution is represented in the code—from a choice between two fixed shapes (an enum) to a more flexible container (a struct) with helper constructors. This prepares the code for a future feature (mixed splice-in/splice-out) but does not change any security-sensitive behavior, fix a bug, or alter how user funds are handled.

This commit is a memory-use optimization, not a security fix. It changes the Lightning network graph so that it only pre-allocates large hash-map capacity when running on the real Bitcoin mainnet. On test networks, it starts with zero pre-allocated capacity, reducing memory consumption during tests. There is no security-relevant behavior change.

This commit changes how a saved Lightning network graph is loaded back into memory. Instead of always reserving a large fixed amount of memory, it now reserves memory based on the actual number of nodes and channels being loaded, plus a small buffer. This is a performance and resource-usage improvement, not a security fix.

This commit only changes a fuzzing test harness (chanmon_consistency) so it can simulate asynchronous channel-monitor persistence from the very start of channel creation. It does not modify production Lightning Dev Kit code, network behavior, or any user-facing logic. There is no direct security vulnerability in the commit itself; it is a test-coverage improvement that may help find bugs in the async persistence path through fuzzing.

This commit only adds documentation to the fuzz testing README explaining how to use an existing `-D` (development) build flag for faster fuzzing builds. It changes no code, build scripts, or security-sensitive behavior.

This commit simply updates two internal capacity estimates in the Lightning network routing code to reflect the current size of the public Lightning network. It changes how much memory is initially reserved for channel and node data structures. There is no security issue.

This commit is a pure rename of an internal Rust function in the Lightning Dev Kit codebase. The function `update_channel_monitor` is renamed to `handle_new_monitor_update_locked_actions_handled_by_caller` because its old name did not make clear that callers must manually handle certain follow-up actions after the monitor update. No logic, behavior, or security properties of the code change. It is a code-quality and maintainability improvement intended to reduce the risk of future misuse by developers working on LDK itself.

This commit removes a harmless debug-only assertion in the Lightning Dev Kit's channel handling code. The assertion could be triggered during normal operation when an HTLC (a conditional Bitcoin payment) in a 'holding cell' couldn't be added to a channel due to a dust-exposure limit. Debug assertions only fire in test builds, so production nodes were never affected. The commit also adds a regression test to exercise this edge case.

This commit is a straightforward code cleanup: it removes an internal Rust macro and replaces its two uses with direct calls to the underlying function. There is no indication of a bug fix, behavior change, or security issue.

This commit refactors a Rust macro into a regular method in the Lightning Dev Kit's channel manager. The stated goal is to let callers release internal locks before running follow-up completion actions. The change itself is a code-quality/locking refactor; there is no direct evidence in the commit message or diff that it fixes a known security vulnerability or that any exploit exists.

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's channel manager. It replaces a Rust macro used to handle channel monitor updates with two regular methods, and updates all places that called the macro. There is no change to user-facing behavior, protocol logic, or security-sensitive operations; it is purely a refactoring to make the code easier to maintain and to satisfy Rust's borrow checker.

This commit is a simple code cleanup: it takes a small helper macro used in three places and replaces each use with the macro's actual contents. The behavior of the program is unchanged; only the internal structure is simplified. There is no security issue here.

This commit is a code cleanup: it replaces a Rust macro with a regular method. The behavior is unchanged, but the new method lets callers explicitly drop locks before running follow-up work. There is no indication of a security bug being fixed.

This commit is a code cleanup: it takes a large block of logic embedded in a macro and moves it into two ordinary helper methods, with a new enum carrying the intermediate result between them. There is no change to what the code actually does—only how it is organized. The commit message and diff both describe this as a pure refactor.

This commit is a straightforward internal code reorganization in the Lightning Dev Kit's channel manager. It converts two standalone helper functions into methods on the ChannelManager struct and moves them to a different location in the same file. The only functional change is that a logging context object is now created inside the method when needed, rather than being passed in by callers. There is no user-visible behavior change and no security fix or vulnerability introduced.

This is a documentation-only change that updates an internal code comment to match renamed variable names. No code behavior was altered, and there is no security impact.

This commit changes how the Lightning Dev Kit (LDK) node restores its record of in-flight payment forwards after a restart. Previously, the code preferred newly reconstructed forward maps built from channel monitor data, which required complex de-duplication logic to avoid processing the same HTLC twice. The commit switches production code to always use the older, persisted forward maps instead, while keeping the new reconstruction path active only in tests (randomly or via an environment variable). It also adds a small guard to avoid pushing duplicate intercept events if a restart re-processes an already-handled intercept forward.

This commit is a straightforward performance optimization in the Lightning Dev Kit's channel manager. It changes how pending payment packets (HTLCs) are looked up and removed from a tracking map, replacing a full scan of all entries with a direct lookup by channel identifier. There is no security-relevant change visible in the diff.

This commit fixes a bug in the Lightning Dev Kit where, after restarting a forwarding node, an already-forwarded payment could be forwarded a second time. The bug only affected the node that restarts, and could lead to duplicate HTLCs being sent downstream, potentially causing funds to be locked or payment failures. The fix prunes already-forwarded HTLCs from a rebuilt in-memory map during startup.

This commit is a pure code restructure: it moves an existing `if is_channel_closed` check inside the loops that process HTLCs, rather than wrapping the loops from the outside. The commit message explicitly says it is 'necessary for the next commit and makes it easier to read.' No behavior changes are visible in the diff, and there is no security fix here.

This commit only adds documentation comments to a Rust function. It clarifies which feature flags and conditions are needed to use the splicing feature. No code behavior was changed, so there is no security issue.