rust-lightning

This is a small code cleanup inside a fuzz testing harness. It removes an unnecessary retry loop and changes a helper function to return a plain value instead of an optional value. It does not change production Lightning code, user-facing behavior, or security-sensitive logic.

This commit only adds bookkeeping inside a fuzzing test harness. It tracks which payments are in-flight versus finished so the test can later check consistency after simulated node restarts. There is no change to production code, no user-facing behavior change, and no security fix.

This commit is a simple variable rename in a fuzz testing file. It changes 'chan_id' to 'scid' (short channel ID) in two helper functions to make the code clearer. There is no functional change and no security impact.

This commit only adds extra checks inside a fuzz test harness. It makes the test's fake transaction broadcaster record any transactions it is asked to broadcast, clears that record after initial channel setup, and then asserts that no further broadcasts happen during normal fuzzing operation. It does not change production code, user-facing behavior, or fix a known bug.

This commit is a code cleanup inside a fuzzing test file. It converts helper functions into closures and changes how payment identifiers are passed around. There is no change to the actual Lightning node logic that runs in production, and nothing in the commit suggests a security fix or vulnerability.

This commit is a code cleanup inside a fuzzing test file. It merges two separate counters used to generate fake payment identifiers into one counter. There is no change to the actual Lightning network library code that users rely on, and nothing in the commit suggests a security fix or vulnerability.

This commit adds a safety check (a debug-only assertion) inside a Rust Lightning library function that handles follow-up work after events. The function expects callers to already hold a specific read lock, and one caller was recently fixed to do so. The new assertion is meant to catch future mistakes where a caller forgets the lock. It is a defensive hardening change, not a fix for an active exploit.

This commit adds support for 'mixed mode splicing' in the Lightning Dev Kit, where a user can add funds to a channel and remove funds in the same transaction. The change fixes how fees are calculated so that the check uses the actual value of inputs being added, not just the net difference between added and removed funds. Previously, a net splice-out (more removed than added) could have caused the fee check to behave incorrectly because it used a negative net value. The commit also adds new tests for this behavior.

This commit adds a new optional feature to rust-lightning that lets the networking code connect to peers through the Tor anonymity network. It is a feature addition, not a fix for a known security bug. The code uses fresh random data for each connection to keep Tor streams isolated, which is a privacy-conscious design choice. There is no indication in the commit that it addresses an active vulnerability or that a security issue was disclosed.

This commit adds a new automated test for a feature called 'dummy hops' in blinded payment paths. It only touches test code and does not change any production logic. There is no security issue here.

This commit changes how LDK builds private payment routes for BOLT12 offers. Instead of revealing the real number of hops to the payee, it now pads every blinded payment path with three fake 'dummy hops' by default. This is a privacy improvement, not a security bug fix. The code itself does not appear to fix a vulnerability; it adds a feature that makes payment paths look longer and more uniform, which can help hide the recipient's network position. The change also updates many tests to expect these extra dummy hops.

This commit only changes internal test helper code in the Lightning Dev Kit repository. It adds new optional arguments to testing utilities so that future tests can simulate payments that include fake 'dummy hops' in blinded payment paths. There is no change to production code, no user-facing behavior change, and no security fix or vulnerability.

This commit adds support for 'dummy hops' in Lightning payment routes. These are fake routing steps used to pad and hide the real path of a payment. The change lets a node strip off one of these padding layers locally and continue processing the payment, instead of trying to forward it over a real channel. It is a feature addition, not a clear-cut security fix, but it touches sensitive onion-routing code where mistakes could let an attacker bypass fees, routing checks, or forward payments incorrectly.

This commit adds a new internal-only constructor for creating private payment routes that can include fake 'dummy hops' between the sender and the real recipient. The goal is to make it harder for outside observers to guess how far apart two users are or to identify the final recipient. It is a privacy enhancement, not a fix for an active security bug. The new API is marked pub(crate), meaning it is not exposed to outside users yet, and the commit message includes a TODO noting that end-to-end tests are still needed before it becomes public.

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.