rust-lightning

This commit adds extra sanity checks inside a Lightning payment routing library to catch cases where time-lock (CLTV) values on payment paths are internally inconsistent. The checks live in a debug-only assertion helper, so they do not change normal runtime behavior; they mainly help developers detect bugs during testing. The patch also fixes one unit test that previously relied on an unrealistic CLTV value and adjusts how the first-hop CLTV is computed when building onion payloads for trampoline/blinded routes.

This commit is a simple variable rename in the code that builds Lightning payment onion payloads. The old name `starting_htlc_offset` was misleading because the value is actually the current block height, so it was renamed to `cur_block_height`. No behavior changed.

This commit fixes a mismatch between the documented behavior and the actual code for building trampoline payment onions in the Lightning Dev Kit. The documentation said that a route hop's time-lock delta already includes any trampoline hops, but the onion-building code was not doing that. The fix changes the code to match the documented (and simpler, more backwards-compatible) behavior. In practical terms, before the fix, trampoline payments could have been constructed with incorrect CLTV (time-lock) values, which could cause payment failures or, in edge cases, affect safety margins for time-locked refunds.

This is a one-line code change in how the first hop of a blinded (private) Lightning payment path calculates its expiry deadline. The change switches from using the current accumulated CLTV value to using the starting HTLC offset when computing the final expiry for the first blinded hop. The commit title says it only 'marginally clarifies' the value selection, suggesting it is a minor correctness or readability fix rather than a serious security bug. There is no vendor statement that this is security-relevant, and no independent researcher is credited.

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