rust-lightning

This patch fixes a race condition in the Lightning Dev Kit's liquidity service plugins (LSPS2 and LSPS5). Previously, when the code decided a peer's state should be removed from disk, it could drop the in-memory lock before deleting the stored data. In that gap, another operation could re-add state for the same peer. The removal could then delete the newly-written state, or an outdated write could overwrite newer data, leading to lost or inconsistent peer records. The fix holds the appropriate locks until the storage write or remove operation is started, and re-checks whether the peer is still removable before deleting anything. If the peer was re-added, it now forces a fresh persist instead of removing.

This commit is a one-word documentation correction in a Rust comment. It changes the recommended idempotency key for handling an LSPS2 service event from a temporary routing identifier (intercept_scid) to a stable user-supplied identifier (user_channel_id). There is no code change, no security fix, and no vulnerability.

This commit only adds automated CI test commands for a newly added optional 'tokio' feature in the lightning-persister crate. It does not change application code, fix a bug, or alter any security-relevant behavior. It is purely a testing/continuous integration configuration change.

This commit simply declares an existing optional dependency as a named Cargo feature. It is a build/package metadata change with no functional code changes and no security relevance.

This commit removes a 'lazy' option from the key-value store's delete operation. Previously, callers could choose to delay or batch deletions for performance, but that created complexity and potential consistency problems with the new async store. Now all deletions are immediate and durable. The change is an API cleanup and simplification; it is not described by the project as a security fix, but it does reduce a small reliability risk where lazy deletes could be lost after a crash.

This commit fixes a Rust async/locking issue in the LSPS2 service handler. Previously, the code used explicit `drop` calls to release locks before awaiting asynchronous persistence operations, and suppressed clippy warnings about holding locks across await points. The commit replaces those explicit drops with scoped blocks so locks are released automatically. This resolves build failures in downstream LDK Node caused by the lock guard type not being `Send`, which matters for async code. It is a code-quality and correctness fix rather than a direct exploit fix, but holding locks across await points can cause deadlocks or async runtime problems.

This commit is a code cleanup in the Lightning Dev Kit Rust library. It removes an awkward API that mixed synchronous storage with an asynchronous sweeper component, and instead lets callers pass a fully synchronous sweeper where synchronous storage is expected. There is no direct security vulnerability being fixed; it is an API-consistency and maintainability change.

This commit is a straightforward internal code cleanup in the rust-lightning project's liquidity module. It removes unnecessary Arc (reference-counted pointer) wrappers around a few fields and switches an internal future type to borrow from its parent queue instead of cloning Arcs. There is no indication this fixes a security bug; it appears to be a refactor for simplicity and reduced overhead.

This commit is a small internal cleanup in the rust-lightning project. It removes unnecessary reference-counting wrappers (Arc) around a simple, zero-sized clock helper called DefaultTimeProvider, and adds a Deref implementation so the helper can be passed directly where an Arc was previously expected. There is no security-relevant change here.

This commit is a straightforward internal code refactor in the interactive transaction negotiation code. It moves existing validity checks from one function into another without changing the rules being enforced. There is no indication this fixes or introduces a security vulnerability.

This commit is a simple internal code cleanup in the rust-lightning library. It rearranges the order in which a transaction-building constructor validates its inputs, moving the creation of the transaction object earlier so that future error messages can include more detail. There is no functional security change visible in the diff itself.

This commit fixes a timing bug in Lightning Dev Kit's 'async payments' feature. When a payment is held for an offline recipient, the sender's Lightning Service Provider (LSP) normally moves the held HTLC into an internal 'pending intercepts' map after decoding its onion. If the recipient comes online and sends a 'release' message before that move happens, the old code would miss the release instruction and eventually fail the payment backward. The fix makes the release handler also look in the pre-decode map and mark the HTLC to be released as soon as it is ready. The commit adds a regression test and extends the release message format to carry the channel alias and HTLC id needed for that lookup.

This commit changes a single Rust test annotation so that an existing test named `test_insane_zero_fee_channel_open` is included in the project's exported/external test suite. It does not modify production code, protocol logic, or any behavior visible to users or network peers. There is no security-relevant change.

This commit only changes a test file. It refactors an existing regression test so it can run in two modes (with and without a newer anchor-channel feature called zero-fee-commitment anchors, or '0FC'), and adds a helper call to set up test funds. No production code is modified, so it cannot introduce a runtime security vulnerability by itself.

This commit only adds a new automated test file for the Lightning Dev Kit. It checks how tiny 'anchor' output amounts are calculated and rounded in zero-fee commitment transactions. There is no change to production code, so by itself it does not fix or introduce a security issue.

This commit fixes a bug in LDK's Lightning channel splicing support. When a channel is 'spliced' (its on-chain funding is changed), its short channel ID can change. Several internal maps that track pending HTLCs (payments being forwarded) were keyed by that changeable ID. If a splice happened while an HTLC was still in flight, the software could lose track of the payment's source and fail to resolve it, potentially causing loss of funds. The fix switches those maps to use the 'outbound SCID alias,' a stable identifier that survives splicing.

This commit only changes test code. It expands an existing test to also exercise a new type of anchor output (P2A anchors) alongside the existing keyed-anchor variant. There is no change to production code, so it does not introduce or fix a live security vulnerability on its own.

This commit is almost entirely a test-file change. It expands existing Lightning channel monitor tests to also cover a new channel type called '0FC' (zero-fee commitments with pay-to-anchor anchors). A tiny non-test change renames a script-weight constant to distinguish 'keyed anchors' from 'pay-to-anchor anchors', but the value stays the same and the constant is only used in tests. There is no production bug fix or security patch here.

This commit only adds and updates test code in a Rust test file. It expands existing reorganization ('reorg') tests to also cover a new channel type called '0FC' (zero-fee commitments / p2a anchors). There are no changes to production code, no bug fixes, and no security patches in the diff.

This commit only adds and updates unit tests for channel anchor output handling in the Lightning Dev Kit library. It does not change any production code, so it cannot introduce a runtime security vulnerability. The change expands test coverage to include a newer channel type known as 'zero-fee commitment' (0FC) channels, ensuring the existing code correctly builds transactions with shared anchors.

This commit removes a test-only restriction so that production builds of rust-lightning now advertise support for 'anchor zero-fee commitments' (0FC), a Lightning channel feature. The change itself is a feature enablement, not a bug fix for an active vulnerability. It could affect protocol compatibility and fee-bumping behavior, but there is no direct evidence in the commit or supplied references that this resolves a security flaw.

This commit updates how transaction weight (a measure of data size) is estimated for Lightning channel fee bumping when handling HTLCs (conditional Bitcoin payments). It distinguishes between two newer channel types: one using 'keyed' anchors and one using 'pay-to-anchor' (P2A) outputs. The P2A variant is slightly lighter because it removes a 1-block CSV delay. The change is a correctness fix for fee estimation; if the weight were wrong, transactions could be under- or over-paying fees, potentially causing delays or stuck funds, but it is not a direct theft or key-leak vulnerability.

This commit adds a test-only assertion to make sure that when a transaction input spends a special 'P2A anchor' output, the witness data (cryptographic proof attached to the input) is empty. It does not change any production code behavior; it only strengthens test coverage for a known protocol detail.

This commit changes an internal test helper, not production code. It relaxes a test-only dust-check so that transactions containing one special below-dust output (a shared anchor used in zero-fee commitment transactions) no longer fail the assertion. There is no direct security vulnerability in the change itself; it is a test-infrastructure update to match new expected on-chain behavior.

This change fixes a functional bug where a Lightning Service Provider (LSP) could fail to pay a mobile client that issued a BOLT12 offer. Previously, if the client was offline and not publicly announced in the network graph, the onion messenger would silently drop the message instead of asking the application to connect to the peer. Now it always emits a 'please connect to this peer' event, even when no network-graph addresses are known, so the app can use a separate wake-up protocol (LSPS5) to reach the client. It is a reliability/availability improvement, not a cryptographic vulnerability.