rust-lightning

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 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 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 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 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 adds a new optional method that lets a Lightning node read its saved channel monitors in parallel, including the CPU-heavy step of turning stored data back into usable objects. It is a performance improvement, not a security fix. The existing single-threaded method remains available and unchanged in behavior.

This commit is purely a code-formatting cleanup. It removes `#[rustfmt::skip]` annotations from three methods in the Lightning channel code and lets rustfmt reformat the function signatures, calls, and log statements across multiple lines. No logic, behavior, or security checks were changed.

This commit only adds a logging parameter to an internal helper function and its callers. It does not change program logic, state handling, or security behavior. The change is purely for better observability when channel monitor updates are paused.

This commit refactors how the Lightning Dev Kit tracks whether a BOLT12 invoice is tied to a Refund versus a regular InvoiceRequest. Previously, one shared context type was used for both, which could lead to ambiguous handling. The change splits that shared context into two distinct variants and adds checks so that Refund-only contexts are only accepted for Refund invoices and InvoiceRequest contexts only for Offer invoices. It is a hardening/correctness change rather than a clear-cut security fix, but it removes ambiguity that could in principle be abused to trick the code into accepting an invoice in the wrong context.

This commit is a minor code cleanup that changes how two error messages are formatted in Rust. It uses a newer, more concise syntax for embedding variables inside strings. There is no functional change and no security relevance.

This commit only adds one line to a shell script used in continuous integration. It tells the Clippy code-analysis tool to ignore a newly introduced lint about assertions on constant values. The change does not modify any actual Rust source code, runtime behavior, or security-sensitive logic.

This commit is purely a code-formatting cleanup. It uses rustfmt to rewrap long function signatures, break up long macro invocations, and adjust indentation in a single Rust source file. No logic, behavior, or security properties of the code were changed.

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 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 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 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 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 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 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 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 is purely a code formatting cleanup. It removes manual rustfmt skip annotations and lets rustfmt reformat several match statements and function signatures in the Lightning channel code. There are no logic changes, no security fixes, and no behavior differences.

This commit only adds new test cases to the project's test suite. It does not change any production code. The tests verify that the software correctly handles tiny fractions of Bitcoin (millisatoshis) when building special zero-fee Lightning commitment transactions, including cases where dust amounts add up. There is no indication of a security fix or vulnerability being patched here.

This commit improves how the Lightning node handles reconnections after a network interruption. Previously, when re-establishing a channel, the node sometimes had to ask an external signer for a cryptographic proof point and could not proceed until the signer responded. The change keeps the two most recent revoked proof points cached locally so the common case no longer needs to wait for the signer. It only defers to the signer asynchronously in the rare 'stale state' case, where the peer claims our node is behind. That stale case either proves data loss (causing a protective panic) or proves the peer is lying (causing a force-close). The commit is a defensive hardening/feature change, not a fix for an active exploit.