rust-lightning

This is a small Rust API cleanup. It changes one method signature so that the future it returns can safely borrow from the object it is called on. There is no security bug being fixed and no behavior change for callers.

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 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 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 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 relaxes an internal requirement about when a special fee rate (used to limit dust exposure) must be provided when computing commitment transaction statistics. Previously, callers had to fabricate a fake fee rate just to avoid triggering a debug assertion, even when they did not care about dust exposure. The change allows callers to pass None for that fee rate, simplifying internal code. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a cleanup/refactoring change.

This commit changes how Lightning Dev Kit calculates 'dust exposure'—a risk measure for tiny outputs that can be abused to make a channel uneconomical to close. The old code only counted extra fees on the counterparty's transaction when the counterparty set a feerate above a configured limit, and it stored that as an optional value. The new code always adds excess fees to dust exposure on counterparty transactions and returns a plain number for the extra exposure if one more accepted HTLC were added. The change appears to fix an accounting gap where excess fees on counterparty commitments were not always included in the local node's dust-exposure check, which could let a remote peer push fees high enough to make the channel unrecoverable.

This commit removes a panic (crash) condition in the Lightning Dev Kit's channel transaction builder. Previously, if a channel's accounting reached an unexpected state where the holder's balance exceeded the total channel value, the code would panic and crash the node. Now it returns a proper error, allowing the node to close the channel gracefully instead of crashing. This is a defensive fix that prevents a potential denial-of-service where a malicious or buggy counterparty could crash your Lightning node by driving channel state into an overdrawn condition.

This commit fixes a bug where setting a configuration value called `maximum_pending_updates` to 0 in a Lightning node persistence helper would cause the program to crash (panic) due to division by zero. The fix makes the code skip storing incremental updates when the limit is 0, which is a valid 'do not store updates' setting. It is a robustness fix rather than an exploitable security vulnerability, and the crash would only affect the node operator who configured the value to 0.

This is a small code cleanup inside a test-only helper. It removes a special case that used a different key format when the secondary namespace was empty, replacing it with one consistent format. It also avoids an unnecessary copy of a byte buffer. The change only affects internal test utilities and does not alter production code or real user data handling.

This commit changes the transaction version used when creating HTLC (Hashed Timelocked Contract) resolution transactions during fee-bumping. For channels that support a specific anchor-based commitment type, the code now uses version 3 instead of version 2. Transaction version 3 enables package relay rules that help ensure child transactions can be broadcast alongside their parents, which is important for anchor-based fee bumping to work reliably on the Bitcoin network. The change appears to be a protocol correctness or compatibility fix rather than a direct vulnerability patch, but using the wrong version could in theory cause transactions to be rejected or fail to propagate, potentially affecting fund recovery in dispute scenarios.

This commit changes how a Lightning node stores and reloads its own internal reasons for payment failures. The old format used a single fixed list of numeric codes, which would have made future upgrades fragile. The new format writes both the standard on-the-wire failure code and a separate internal reason code, plus a placeholder for future extra fields. If an older or newer version reads a reason it does not know, it now falls back to the standard failure code instead of potentially failing to load the data. This is a forward-compatibility improvement, not a fix for an active exploit.

This commit adds one line to a CI lint script, telling the Clippy linter to ignore a newly introduced style warning (manual_is_multiple_of) until the project can require a newer Rust compiler version. It does not change any application code, runtime behavior, or security-sensitive logic.

This commit fixes an incomplete earlier change that was meant to prevent two internal data structures in LDK's channel manager from being locked at the same time. Holding both locks together can create a lock-order dependency, which in the worst case can lead to deadlock (the program freezing up). The fix narrows the use of one lock so the two locks are no longer held together in the affected code path. There is no direct evidence in the commit of an exploitable security vulnerability such as theft of funds.

This commit is a collection of minor cleanups to fix automated documentation and code-quality checks. It removes unnecessary parentheses, fixes broken doc links, corrects a URL in a comment, and adds missing doc links. None of the changes alter program behavior or fix any security issue.

This commit updates how Lightning Dev Kit handles fee-bumping anchor transactions for a newer type of channel (zero-fee commitment channels, or 0FC). It makes two key changes: it uses a much smaller empty witness for the new-style P2A anchor output, and it sets the anchor transaction version to 3 instead of 2. These are protocol-specific adjustments needed so the new channel type can close and fee-bump correctly. The commit does not describe itself as a security fix, and the changes appear to be compatibility/correctness updates rather than a patch for an active vulnerability.

This commit changes how Lightning anchor output amounts are tracked and set in commitment transactions. Previously, anchor outputs used a fixed value constant. The patch makes the anchor value dynamic, reading it from the actual commitment transaction output. This is part of support for a newer Lightning feature called 'zero-fee commitments' where anchor amounts can vary. The change appears to be a correctness fix to ensure the wallet software constructs follow-up transactions using the real anchor value rather than a hardcoded one, which could otherwise cause transaction creation failures or fee estimation errors.

This commit fixes a bug in how Lightning invoice requests are created. Previously, the code generated a fresh random nonce for the invoice request context instead of reusing the nonce from the original offer. Because the two nonces no longer matched, later verification of the invoice request would fail. The fix simply uses the offer's nonce directly. This is a correctness bug in the BOLT 12 offers protocol flow rather than a traditional security vulnerability like theft or denial of service, but it could cause payment flows to break or messages to be rejected.

This commit simply moves the contents of a small helper macro directly into the one place it was used. There is no change to program logic, no bug fix, and no security improvement or regression visible in the diff.

This commit restructures how Lightning Dev Kit handles routing of intercepted payments. Previously, the code required holding one internal lock (forward_htlcs) before acquiring another (pending_intercepted_htlcs). The patch removes that lock-order dependency by checking whether an HTLC should be intercepted before, not after, adding it to the forwarding queue. The stated goal is cleaner future code, not a security fix, but removing unnecessary lock nesting can reduce the risk of deadlocks in multi-threaded code.

This commit moves a safety check so that incoming splice requests from a peer are verified for 'quiescence' earlier in the validation process. Quiescence means the channel is in a quiet, stable state before starting a splice. Previously, the check was performed later in an internal code path, leaving a TODO note suggesting it should also be enforced on incoming splice_init messages. The change removes that TODO and adds the check inside the validation function used for incoming splice requests. This is a defensive hardening fix: without it, a peer might be able to initiate a splice while the channel is not quiescent, potentially causing protocol confusion or errors.

This commit is a simple rename of a method from `feerate_per_kw()` to `negotiated_feerate_per_kw()` across the codebase, plus an update to its documentation. The goal is to make it clearer that the returned value is the fee rate agreed with the peer, not necessarily the actual fee rate used on-chain. There are no logic changes and no security fix.

This commit adds a single line of code that enables serialization (the ability to convert data into a format that can be stored or transmitted) for a list of BlindedMessagePath objects. It is a routine, additive change with no visible security implications. There is no indication this fixes or introduces a vulnerability.

This commit adds a new startup-only API method that lets LDK nodes load already-saved channel monitors without rewriting them to disk. It is a performance and reliability improvement, not a security fix, and does not change how normal channel watching works.