rust-lightning

This commit only updates test-only development dependencies and adjusts the corresponding test import paths. It does not change any production code, network behavior, or cryptographic logic, so it has no security relevance for users of the library.

This commit simply updates a dependency version number in a configuration file, bumping the electrum-client library from version 0.24.0 to 0.25. There is no code change, no disclosed security fix, and no indication of any vulnerability. It appears to be a routine maintenance update.

A bug in the LSPS5 (webhook) service meant that one failed disk/storage write could permanently disable all future saves of webhook state until the program was restarted. The code used a counter to make sure only one save runs at a time, but it only reset that counter on success. After any error, every later save call silently did nothing and returned success, so operators saw no errors while important data was lost. The patch resets the counter even when writes fail, so retries happen normally.

This commit adds a new safety check inside a fuzz-testing harness, not in production code. After simulated Lightning payments settle, it now asserts that no payment promises (HTLCs) are left stuck in any test channel. It does not change how real users' funds are handled and does not fix an active bug by itself.

This commit is a pure code cleanup and refactoring of an internal fuzz-testing harness in the rust-lightning project. It moves existing test setup, state, and message-processing logic into a new `Harness` struct so the main `do_test` function only reads fuzz input bytes and dispatches actions. No production code, network behavior, or security logic was changed.

This commit is a simple code cleanup inside a fuzz test file. It moves a helper macro (a reusable chunk of code) to a higher scope so that more parts of the test can use it later. No production code, no security fix, and no behavior change.

This commit is a code cleanup inside a fuzz test file. It replaces four separate message queues with one struct and moves some routing logic into methods. There is no change to the actual Lightning node library, network protocol, or cryptographic handling, so it does not affect real users or funds.

This commit is a pure internal refactoring of a fuzz test harness. It moves payment bookkeeping helpers into a new PaymentTracker struct but does not change the actual Lightning library code, network protocol handling, or any behavior visible to users. There is no security relevance.

This commit is a straightforward internal cleanup of a fuzz test file. It removes duplicated local variables (monitor_a/b/c, keys_manager_a/b/c) and changes helper functions to read those values directly from a shared HarnessNode structure. There is no change to production code, cryptographic logic, network behavior, or user-facing behavior. It is purely refactoring to make the test harness easier to maintain.

This commit is a code cleanup inside a fuzzing test file. It moves bookkeeping variables (like saved node state, block heights, and fee values) into a test helper struct and converts some closures into methods. There is no change to the actual Lightning protocol logic or to any production code, so it cannot affect real users or funds.

This commit is a straightforward internal code cleanup in a fuzzing test harness. It moves helper functions that operate on test nodes into methods on the HarnessNode struct, reducing the need to pass many arguments around. There is no change to production code, no security fix, and no externally visible behavior change.

This commit is a small internal cleanup of a fuzz-testing harness in the rust-lightning project. It replaces a macro that immediately ended the test with a normal labeled loop break, and moves one final consistency check to after the loop. There is no change to production Lightning code, no fix for a real vulnerability, and no security impact on users.

This commit is a code cleanup inside a fuzzing test harness. It groups together repeated code for managing simulated peer connections and channel monitor updates into a new helper structure called PeerLink. There is no change to the actual Lightning protocol logic or to any code that runs in production; it only affects how a test file is organized.

This commit is a code cleanup inside a fuzz test file. It moves the creation of test-only helpers (loggers, keys, monitors, broadcasters, wallets, fee estimators) into a single struct method and removes duplicated local closures. There is no change to production code, no change to cryptographic behavior, and no fix for a security bug.

This commit is a pure code cleanup inside a fuzz-testing file. It takes four blocks of test-setup logic that were previously copy-pasted as macros and turns them into ordinary Rust helper functions. No production code, no protocol behavior, and no security logic were changed. The commit message explicitly says the goal is to make later refactors easier to review while leaving fuzz scenario behavior unchanged.

This commit is a small internal cleanup of a fuzz test file. It wraps test node objects in a new HarnessNode struct so related pieces (channel manager, chain monitor, key manager) stay together, and it removes some repetitive function arguments. There is no change to production code, no change to security behavior, and no fix for a vulnerability.

This commit fixes a bug in Lightning Dev Kit's splicing logic for zero-fee-commitment (0FC) channels. Previously, when calculating the required channel reserve after a splice, the code would cap the reserve at the total channel value. In a special case where the splice acceptor had no balance and no HTLCs existed, this cap allowed the splice initiator to withdraw more than they should—effectively reducing their balance below the required reserve. The only thing stopping a full drain was a separate dust-limit check. The fix makes the reserve calculation return an error if the computed reserve would exceed the post-splice channel value, and it uses each side's actual dust limit instead of a global constant when validating splice contributions.

This commit tightens how Lightning Dev Kit calculates the channel reserve for older-style (v1) channels. The reserve is a portion of channel funds that must stay untouched to guarantee both parties can pay penalties if someone cheats. Previously, a misconfigured or malicious proportion could make the calculated reserve exceed the entire channel value, or a tiny channel/dust limit could produce a nonsensical reserve. Now the code rejects those cases outright and also caps the proportional reserve at 100%. The change is defensive: it prevents opening channels with impossible reserve settings rather than silently accepting them.

This commit renames and flips the meaning of a flag used during Lightning channel splice negotiations. It changes when the software decides to keep or discard an in-progress splice after a disconnect or abort. The change appears intended to support a new 'user manually cancels' case, but the logic is subtle: several call sites now pass the opposite boolean, and the function's internal cases were reordered. There is no direct evidence this fixes an exploitable vulnerability, but the change touches safety-critical state cleanup during channel funding/splicing, where mistakes can lead to stuck funds or inconsistent channel state.

This commit adds a new public API that lets a Lightning node operator cancel a splice funding negotiation they started, as long as they have not yet signed the funding transaction. It replaces an older test-only cancellation path with a safer, more complete implementation that checks the user actually contributed inputs or outputs and refuses cancellation once signatures have been sent. The change is a defensive feature improvement rather than a fix for an active vulnerability.

This commit improves how the Lightning Dev Kit node keeps track of funds involved in a 'splice' (a way to resize a Lightning channel while it is open). Previously, if the channel closed while a splice was still pending, the wallet only received a generic reference to the old funding transaction. Now it receives the actual inputs and outputs the user contributed, making it easier to recover those funds safely. The change is a feature completeness / robustness improvement rather than a fix for an active exploit.

This commit refactors how a Lightning node reports which transaction outputs a user is contributing during channel funding or splicing. Instead of sharing full output details (including amounts), it now shares only the output scripts (addresses). The stated reason is that amounts can change across RBF (fee-bump) attempts, so scripts are a more stable identifier. The change also fixes filtering logic so duplicate outputs are correctly recognized by their script, preventing a user's own change output from being incorrectly reported as a new contribution in later rounds.

This commit fixes a security gap in LDK's string sanitizer, PrintableString, which is used to display untrusted text like node names and invoice descriptions in logs and user interfaces. Previously it only stripped traditional control characters (like newlines and tabs) but left behind Unicode 'format' characters, including invisible bidirectional override characters and zero-width spaces. These can trick a human reader into seeing a different string than what the software processes—an attack family known as 'Trojan Source.' The patch now replaces those format characters with the standard replacement symbol (), so spoofed strings render safely.

This commit adds a small informational flag to a public API so that users of the Lightning library can tell whether a recent payment was a 'probe' (a test payment used to check network liquidity) rather than a real payment. It is a feature/API improvement, not a security fix, and does not change how funds are handled.

This commit changes how a Lightning node reports 'discarded' bitcoin inputs and outputs when a splice attempt is replaced by a newer version (RBF). Instead of discarding whole transactions, it now reports only the specific inputs and outputs that were unique to the abandoned splice round. This is a correctness and wallet-recovery improvement, not a clear-cut security fix, but a prior bug in this area could leave funds unrecovered or confuse wallet tracking.