rust-lightning

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.

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