rust-lightning

This commit fixes a subtle timing bug in how Lightning payment deadlines are recorded. When a node receives a payment, it was writing down the deadline the sender asked it to honor rather than the actual deadline attached to the incoming payment. Normally those two numbers are the same, but in a special 'trampoline' routing case a node can end up giving itself less time than it really has to claim funds. The fix makes the node use the real deadline from the incoming payment instead.

This commit only adds a new safety check inside an internal fuzz test harness. It does not change production code, user-facing behavior, or network protocol handling. The change makes the test suite verify that when a payment is claimed by a receiver, the sender eventually receives a matching 'payment sent' confirmation. It is a test-quality improvement, not a security fix or vulnerability.

This change fixes a state-handling bug in the Lightning Dev Kit where a channel that is about to be closed could still try to enter a 'quiet' negotiation phase used for splicing (modifying a channel's funds). After a recent refactor removed an 'awaiting quiescence' flag, the code could send a 'stfu' (stop, wait) message for a channel the user actually wants to shut down. The patch makes shutdown cleanly abandon any pending splice/quiescent action and notify the user with a SpliceFailed event. It is a protocol-correctness and user-experience fix rather than a direct funds-loss vulnerability.

This commit is a code cleanup in a Lightning network implementation. It removes a duplicate internal flag used to track whether a channel is trying to become quiet (quiescent) for operations like splicing. The same information is now tracked by checking whether a pending 'QuiescentAction' exists. The change frees up a bit in the channel state flags for future use and simplifies state management. It does not appear to fix a known security vulnerability, but any change to state-machine logic in payment channel code carries some risk of introducing subtle bugs.

This commit fixes a bug in the Lightning Dev Kit where a node could send a 'stop the flow and update' (stfu) message too early during a channel splice. If a splice was already pending and a new one was requested, the old code path could send stfu prematurely, potentially causing the splice protocol to get out of sync with the peer. The fix merges two similar code paths into one and adds a regression test.

This commit is a simple rename of a field and method from `message_paths` to `held_htlc_available_paths` in the code that handles a specific type of Lightning invoice (a 'static invoice'). The change was made because two different invoice types had methods with the same name that returned different kinds of paths, which was confusing for developers. There is no functional change to how the software behaves, and no security issue is present in the commit.

This commit is a routine cleanup of the project's fuzz-testing infrastructure. It changes how fuzz tests are compiled and run, adds a new way to feed test input via standard input, and removes an unused dynamic-library build mode. There is no indication it fixes or introduces a security vulnerability in the actual Lightning library code.

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's Rust implementation. It removes a helper method called subtract_non_htlc_outputs from a trait and replaces its uses with direct calls to a similar helper function. The commit message explicitly states there is no functional change, and the diff shows the new helper behaves identically to the removed method. There is no indication this fixes or introduces a security issue.

This commit is a code cleanup in the Lightning Dev Kit's rust-lightning project. It removes a helper method called `commit_tx_fee_sat` from a transaction-building trait and moves the fee-checking logic into a more central place when opening channels. The goal is to keep the same behavior while simplifying the code. There is no direct evidence in the commit that this fixes a security vulnerability.

This commit is a straightforward internal code reorganization in the Lightning Dev Kit's transaction-building code. It renames and restructures a method so that a new wrapper, `get_channel_stats`, returns the same underlying commitment statistics inside a new container struct. The commit message explicitly states there are no functional changes beyond the API rename, and the diff shows only mechanical renames and field-access adjustments (e.g., `stats.nondust_htlc_count` becomes `stats.commitment_stats.nondust_htlc_count`). There is no indication of a security fix, vulnerability, or behavior change.

This is a small code cleanup in the Lightning payment channel logic. The developer rewrote how the maximum next HTLC (payment) amount is calculated, using simpler arithmetic and removing a debug assertion. The commit message explicitly states there are no functional changes, and the diff appears to preserve the same end result while making the code easier to read.

This commit fixes a bug where retrying a multi-part Lightning payment could fail because the original 'total payment amount' setting stored in the onion was lost and replaced with a default value. The fix stores that onion total directly in the pending payment record so retries preserve it. There is no direct evidence this is exploitable by an attacker; it appears to be a reliability/functional bug for legitimate users, especially those splitting payments across multiple wallets.

This commit is a preparatory refactor in LDK's payment-sending code. It adds a new `total_mpp_amount_msat` field to `RecipientOnionFields` so that, in future commits, a payer can send an HTLC that is only one part of a larger multi-part payment. For now the new field is always required and is asserted to match the existing payment amount, so behavior is unchanged. The commit also fixes a small related bug where probe payments were not including a payment preimage as intended. There is no immediate security vulnerability here; it is a feature-building change with a minor bug fix.

This commit only adds a changelog note warning users that two newly introduced payment options will prevent downgrading to version 0.2 while a payment is in progress. There is no code change, no bug fix, and no security issue in the commit itself.

This commit is a code cleanup and feature-enabling refactor in the Lightning Dev Kit (LDK). It moves the total amount for multi-path payments (MPP) out of individual function arguments and into a structured object called `RecipientOnionFields`. This makes it possible for future callers to send partial payments that add up to a larger total, which is useful for wallets that hold funds in multiple places. The commit itself does not appear to fix a known bug or vulnerability; it is preparation for a new capability.

This commit adds a new, optional feature to the Lightning Dev Kit (LDK) that lets multiple wallets or devices team up to pay a single Lightning invoice. Each participating wallet can pay just part of the total, and the merchant's node sees the combined payment as one normal multi-path payment. It is a deliberate feature addition, not a bug fix, and the code includes validation to prevent obvious misuse such as paying less than promised.

This commit removes a redundant copy of the expected total payment amount from each individual HTLC record in LDK's channel manager. The expected total is now stored once per payment in the required 'RecipientOnionFields' structure. The change also tightens serialization/deserialization checks so that all HTLCs in a multi-part payment must agree on the total amount. It appears to be a code-cleanup and hardening change rather than a fix for an active vulnerability, though it removes a potential source of inconsistency that could have led to incorrect payment handling.

This commit removes old backward-compatibility code in a Lightning network node library. It now requires a newer data field (RecipientOnionFields) when handling incoming payments and refuses to load very old saved state. The change is a cleanup that tightens data handling but does not by itself create a new security vulnerability.

This commit adds safety checks inside the Lightning payment code to make sure the route finder (the 'Router') actually follows the rules it was given. Before sending a payment, the code now verifies that the chosen route does not exceed the user-set maximum fee, does not contain useless empty paths, and does not include unnecessary multi-path payment (MPP) parts. If the router misbehaves, the payment is abandoned instead of being sent. It is a defensive hardening change rather than a fix for a known active attack.

This commit adds a new version of a file-based storage backend (FilesystemStoreV2) for the Lightning Dev Kit. It is a feature addition, not a security patch. The code introduces pagination support and a consistent directory layout using a special marker directory named '[empty]'. There is no direct evidence in the commit of a vulnerability being fixed, but the new code touches filesystem paths and page-token parsing, which are typical places where bugs can hide. The changes appear defensive and well-tested.

This commit is a pure code reorganization (refactor) with no security-relevant behavior change. It splits the existing FilesystemStore implementation into a shared common module and a v1 module, in preparation for a future FilesystemStoreV2. All call sites are updated to use the new module path, but the actual file-reading, writing, locking, and listing logic is moved unchanged.

This commit adds new Rust programming interfaces (traits) for listing stored data in pages rather than all at once. It does not change any existing behavior, fix a bug, or alter how data is stored or protected. It is a feature addition to support more efficient key listing in future code.

This commit is a code-quality refactor in the Lightning Dev Kit's block-sync module. It replaces the use of Rust's generic input/output error type with more specific string-based error messages when parsing HTTP and RPC responses. It does not appear to fix a security vulnerability, change network behavior, or introduce a new attack path. The main risk is that some error classifications may have shifted slightly (for example, parse errors are now consistently treated as persistent rather than transient), which could affect retry behavior but is not directly exploitable.

This commit is a straightforward code cleanup in the project's test suite. It replaces a Rust macro used only in tests with an equivalent regular function. There is no change to the actual Lightning node logic that runs in production, and no security-relevant behavior is altered.

This commit is a straightforward code cleanup in the project's test suite. It removes a helper macro used only in tests and replaces it with direct calls to an existing function. There is no change to the actual Lightning node logic that runs in production, and nothing in the commit suggests a security fix.