rust-lightning

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's channel state management. It replaces an enum (a type with two distinct variants) with a struct (a simple container of fields) for tracking the holder's per-commitment point. The behavior is intended to be equivalent; the change only simplifies naming and removes redundant pattern matching. There is no indication of a security fix or vulnerability being addressed.

This commit only updates comments in a fuzz test file. It changes wording to reflect that recent code changes have made the tests less fragile. No code behavior is modified, and there are no security implications.

This commit is a fuzz-testing infrastructure change, not a security fix. It changes how a test harness feeds fake fee estimates to the Lightning library during automated fuzzing so that existing test inputs don't become useless every time the library asks for fees in a slightly different place. There is no change to production code or to how real users' fee estimates are handled.

This commit changes only a fuzzing test harness, not production code. It alters how fake random numbers are generated during automated fuzz testing so that test inputs remain useful even when the underlying software changes. There is no security vulnerability or fix to a real system here.

This commit is a minor code cleanup. It removes leading underscore prefixes from variable names (like `_recipient_id` becoming `recipient_id`) after a feature flag was removed. These underscores are a Rust convention meaning 'this variable is currently unused.' Once the feature became always-enabled, the variables are now used, so the underscores were no longer appropriate. There is no functional change and no security impact.

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