rust-lightning

This commit is a minor code cleanup in the LSPS2 liquidity service. It removes an unnecessary copy (clone) of a Bitcoin transaction when retrieving and broadcasting a funding transaction. The change returns a reference to the existing transaction instead of duplicating it. There is no security issue here—only a small performance improvement and cleaner code.

This commit only adds a documentation comment explaining an existing behavior in the code. It does not change any logic, fix any bug, or alter how the software operates. There is no security issue present in the change itself.

This commit adds a new LSPS2 trust model called client_trusts_lsp. In this model, a Lightning Service Provider (LSP) delays broadcasting the Bitcoin funding transaction for a new channel until the client has actually paid the channel-opening fee via a forwarded payment. The commit also adds a new ChannelManager method that lets LDK validate a funding transaction without immediately broadcasting it. The changes are primarily a feature addition with safety checks to avoid broadcasting funding transactions after a channel has closed or force-closed.

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 fixes race conditions in how two liquidity-service modules (LSPS2 and LSPS5) save their state to disk. Previously, multiple 'persist' operations could run at the same time, which could cause stale or partially-written state to overwrite newer data, or cause a peer's state to be removed incorrectly. The fix adds a simple in-flight flag so only one persist runs at a time, and if new changes arrive during a persist, the process loops around and saves them before finishing.

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