rust-lightning

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

This commit relaxes Rust lifetime requirements ('static bounds) on generic arguments in two background-processor async functions. It is a code-quality and API-ergonomics change: it makes the functions easier to call with non-static data, but does not change runtime behavior, fix a crash, or address a security vulnerability.

This commit is a routine internal cleanup: it removes unnecessary Arc (reference-counting pointer) wrappers around a KVStoreSyncWrapper type and adds a Clone derive so the wrapper can still be duplicated when needed. There is no user-visible behavior change, no bug fix, and no security relevance in the diff itself.

This commit is a straightforward internal code cleanup. It removes unnecessary Arc (reference-counted pointer) wrappers around internal objects in two sync-wrapper types, replacing them with direct ownership. To keep existing tests compiling, the tests use a small unsafe block to create a static reference. There is no user-facing behavior change and no security fix.