rust-lightning

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.

This commit fixes a bug in the Lightning Dev Kit's splicing/RBF (fee-bump) protocol. If a splice transaction got confirmed while both sides were exchanging 'quiet' (STFU) messages, the code could wrongly try to start a new RBF round for an already-final splice. The fix adds a re-check before sending the RBF initiation message and disconnects the peer if the splice is already locked, preventing protocol confusion and potential loss or locking of funds.

This commit only adds a pending changelog file describing upcoming API renames and additions for splicing-related events. It contains no code changes, no bug fixes, and no security-sensitive behavior changes.

This commit is a routine code cleanup. It removes an unused error type and several helper methods that are no longer called anywhere in the codebase. There is no change to behavior, no bug fix, and no security-related content.

This is a code cleanup change in a Lightning Network library. It replaces an older way of building a failure message during a failed channel splice with a newer, more consistent method. There is no indication in the commit that this fixes a security bug or introduces a vulnerability; it appears to be a refactor to make the code simpler and less error-prone.

This commit fixes a bug in how the Lightning Dev Kit filters duplicate transaction outputs when multiple funding or splicing attempts overlap. Previously, it treated two outputs as duplicates only if both the amount and the destination address matched exactly. The fix now treats outputs as duplicates if only the destination address matches, even if the amounts differ. This prevents a user from accidentally losing control of funds when a second splicing attempt reuses a change address with a different amount, such as after a fee-bump (RBF).