rust-lightning

This change is a small observability improvement, not a security fix. When a Lightning channel is force-closed because an HTLC (a conditional payment) timed out, the payment hash of the blamed HTLC is now included in the channel-closed event. Previously only a generic 'HTLCs timed out' reason was reported. This helps developers debug payment failures but does not change when or how channels close, nor does it fix any vulnerability.

This commit only changes a log message to include the payment hash when Lightning Dev Kit force-closes a channel because of an HTLC timeout. It is a debugging/observability improvement, not a security fix.

This commit is a simple internal rename of a Rust struct from 'StoredWebhook' to 'Webhook' within the LSPS5 service module. It changes no behavior, logic, or public interfaces and has no security relevance.

This commit is a simple internal code cleanup in the LSPS2 liquidity module. It replaces an inline tuple (payment hash + list of HTLCs) with a named struct called PaymentQueueEntry. No behavior changes, no security fixes, and no user-facing changes are visible in the diff.

This commit only adds a new fuzzing test target for StaticInvoice deserialization. It does not change any production code, fix any bug, or alter behavior. It is a testing/infrastructure addition with no direct security relevance.

This commit changes the LSPS5 webhook notification cooldown from 1 hour to 1 minute. The shorter cooldown means the same type of notification can be sent to a client's webhooks far more frequently. This is not a code vulnerability in itself, but it increases the risk of accidental or intentional notification spam, which could stress webhook endpoints, generate extra network traffic, and make it easier to overwhelm a receiving service. The change is purely a configuration/default-value adjustment with documentation and test updates.

This commit removes a compile-time feature flag called `async_payments` so that the new async-receive Lightning functionality is always included. It is a feature-enablement/refactoring change, not a patch for a known vulnerability. The code being exposed was already present but hidden behind the flag. There is no direct evidence in the commit of a security bug being fixed; rather, the change makes an experimental API public now that it is considered usable.

This commit changes internal numeric identifiers (called TLV types) used by a new experimental Lightning feature called async payments. The old numbers accidentally overlapped with another feature's numbers, which only caused test failures when a specific configuration flag was enabled. The fix simply picks new, non-overlapping numbers. There is no evidence this caused real-world fund loss or could be exploited by an attacker.

This commit changes how Lightning payment offers are refreshed in the cache. Previously, the software decided an unused offer was 'stale' based on when its invoice was confirmed saved by a server. Now it uses the offer's own creation time. The goal is to keep offers fresher and improve privacy by not reusing the same offer repeatedly. There is no obvious security vulnerability being fixed; it reads as a correctness and privacy improvement.

This change is a performance and resource-usage improvement, not a security fix. It stops a Lightning node from sending a fresh invoice to the static invoice server every minute for every active offer. Instead, it now only refreshes invoices after a two-hour threshold (or immediately if the offer is still pending confirmation). That reduces unnecessary network traffic and load on the server, and lowers the chance that a bug or misconfiguration could accidentally flood the server with updates.

This commit changes how a Lightning node tracks timing information for cached asynchronous payment offers. It replaces the previous 'reply path expiry' timestamp with a new 'invoice creation time' timestamp. The stated goal is to enable less frequent refreshes of static invoices in a follow-up commit. A side effect is that the node no longer ignores 'invoice persisted' messages just because the reply path is a little stale. The change is framed as a refactor/preparation step, not a security fix.

This commit changes how a Lightning node sets up 'async receive' offers. Previously, the node only asked the static invoice server to create offers during periodic timer ticks. Now it also sends that request immediately when the user configures the invoice server paths. This is a functional/availability improvement to make async receiving ready sooner after startup, not a fix for an exploitable vulnerability. There is no evidence in the commit of a security bug being patched.

This is a small internal code cleanup in the Lightning Dev Kit library. It removes an unnecessary 'duration' argument from a private helper function and instead computes that value inside the function. There is no security-relevant change visible in the diff.

This commit is a small internal cleanup in the Lightning Dev Kit's code for handling 'offers' (a way to request payments). It removes a duplicate copy of a list of network paths used to contact a static invoice server. Previously the same list was stored in two places, which created a risk that the two copies could become inconsistent. Now the code keeps a single copy in the async receive offer cache and reads it from there. There is no direct security bug being fixed, but the change prevents a future maintenance issue that could lead to incorrect or stale routing paths being used.

This is a small API refactor in a Lightning network library. It changes one internal persistence helper from returning a generic 'writeable' object to returning raw bytes, so it can be more easily used across language bindings. There is no direct evidence this fixes a security vulnerability.

This is a one-word documentation comment correction. It changes a comment from saying peers must be connected to 'send' onion messages to saying they must be connected to 'receive' onion messages. No code behavior changes.

This commit widens the visibility of several internal Lightning payment-offer APIs from crate-internal to public. It is a routine API exposure change so that non-ChannelManager users can reuse the async-payment offer flow. There is no direct security bug in the diff, but making previously internal state-management methods public slightly enlarges the attack surface and places more responsibility on callers to persist state correctly.

This commit removes two public programming interfaces (APIs) from the Lightning Dev Kit library that let users manually create special Bitcoin Lightning offers and invoices for async/offline payments. The library now wants users to rely on a newer automated server-based protocol instead. The change is a routine API cleanup, not a security fix.

This patch fixes a bug in how a Lightning node signs 'justice' transactions—on-chain penalty transactions that reclaim funds when a counterparty tries to cheat. Before the fix, the code always used the current funding channel parameters when signing, but with splicing there can be multiple funding scopes. If the wrong parameters were used, the justice transaction signature could be invalid, potentially preventing the node from successfully penalizing a cheating counterparty in a spliced channel. The fix looks up the correct funding scope based on which commitment transaction is being claimed.

This commit is a small internal refactoring in the Lightning Dev Kit's channel monitoring code. It changes a helper function so that the caller explicitly passes in the channel parameters, rather than the helper always grabbing them from a fixed internal field. The commit also adds safety comments and debug-only checks (debug_assert!) confirming this path is only used when there is a single active funding scope. There is no direct evidence in the commit or supplied references that this fixes an active security vulnerability; it appears to be a defensive code-quality change that makes future multi-funding-scope logic safer.

This commit fixes a bug in how the Lightning Dev Kit's on-chain channel monitor matches a confirmed commitment transaction to the correct funding state. Previously, the code always looked at the primary channel funding state (`self.funding`) when deciding whose commitment transaction was broadcast and which HTLCs/outputs to claim. After splicing-style channel upgrades, a commitment transaction can spend an alternative (pending) funding output. If the monitor used the wrong funding state, it could fail to recognize the commitment, miss HTLC claims, or use stale channel parameters—potentially leading to stuck funds or an inability to claim outputs during a force-close. The fix introduces a helper that selects the funding state actually confirmed on-chain.

This commit is a temporary CI workaround, not a security fix. It tells the Rust compiler to ignore 'unused import' warnings during automated lint checks because a known bug in the compiler is causing false positives. No product code was changed, and no vulnerability is present.

This commit is a simple cleanup that removes unnecessary 'allow unused import' annotations and rewrites trait imports to be explicit. It has no security relevance—it only affects compiler warnings and code style.

This commit is a minor cleanup in test-only code. It changes which Rust compiler configuration flag controls a small helper struct used only when generating test vectors. There is no security issue, no vulnerability fix, and no change to production behavior.

This change fixes a situation in the Lightning Dev Kit where, after a blockchain reorganization that undoes an alternative funding transaction, the user's own commitment transaction could fail to be broadcast automatically. Previously the code would cancel stale claims but then wait for a new funding transaction to confirm before broadcasting the user's valid commitment. If that confirmation never happened, the user might not recover funds from a force-closed channel. The patch now broadcasts the user's latest commitment immediately after such a reorg, without relying on the counterparty or manual action.