rust-lightning

This commit only adds new test code to verify how an existing 'accountable' flag is forwarded between Lightning nodes. It does not change production logic, so it cannot introduce a new security vulnerability by itself. The tests check that the flag is correctly propagated (or not propagated) across a three-node payment path.

This is a small code cleanup that removes an unnecessary clone (duplicate copy) of update_add data when serializing a Lightning channel to bytes. It changes the vector to hold references instead of owned copies, with no functional change to behavior or security.

This commit adds a new boolean flag called 'accountable' to outbound payment records (HTLCs) in a Lightning Network implementation. It ensures the flag is saved to disk and restored correctly when the node restarts. The change appears to be a data-model fix to support tracking which payments should be held financially accountable, likely as part of a larger feature. There is no direct evidence in the commit that this fixes an active security vulnerability, but incomplete state serialization can lead to incorrect behavior after a restart.

This commit adds a new 'accountable' flag to forwarded Lightning payments that is preserved when an HTLC is queued in a channel's holding cell. The flag appears intended to track whether a downstream node can be held financially responsible if a forwarded payment fails after the upstream side has already been settled. The change itself is a data plumbing patch; it does not contain an obvious active vulnerability, but it is part of a larger accountability mechanism whose security implications depend on how the flag is consumed elsewhere.

This commit adds a new boolean flag called incoming_accountable to an internal data structure (PendingHTLCInfo) used when routing Lightning payments. The flag records whether the node is expected to be 'accountable' for resolving an incoming payment on time. It is read from an optional TLV field in the incoming message and defaults to false when not present. The change is a straightforward plumbing/data-model update; it does not by itself fix or introduce a security flaw, but it is part of work that could affect how reputation and payment-timeout penalties are tracked in the future.

This commit adds a new experimental flag called 'accountable' to the Lightning update_add_htlc message. The flag is purely informational right now: it is sent and received, but the code does not use it to make any forwarding or security decisions. It is marked experimental and is not treated as authoritative. There is no obvious security vulnerability in the change itself.

This commit adds a missing macro rule in a Rust serialization helper so that optional fields can use a custom byte encoding. It is a feature addition with a regression test; there is no indication it fixes a security vulnerability.

This commit is a performance optimization, not a security fix. It changes how Lightning node data is loaded from storage when the program starts up. Previously, certain update records were read one at a time; now they are read in parallel. The commit message and code changes only describe speed improvements and reducing network round trips. There is no indication of a vulnerability being fixed.

This commit adds a new optional method that lets a Lightning node read its saved channel monitors in parallel, including the CPU-heavy step of turning stored data back into usable objects. It is a performance improvement, not a security fix. The existing single-threaded method remains available and unchanged in behavior.

This commit is a performance and robustness improvement, not a fix for an active security bug. It changes how Lightning channel monitor data is loaded on startup so that the code lists available update files first, rather than repeatedly trying to read update files until it gets a 'not found' error. This removes one round-trip to storage for users with no pending updates and makes the loader no longer depend on storage backends correctly returning a specific 'not found' error. The old behavior could, in theory, cause a node to fail to start or misload state if a storage backend returned the wrong error kind, but the commit itself does not describe any such failure being exploited.

This commit is a routine internal API change. It updates the FutureSpawner trait so that spawning a background future can return the future's result, similar to tokio::spawn. It does not fix a security bug and does not introduce obvious security flaws; it is preparation for a later feature.

This commit is a performance improvement, not a security fix. It changes how Lightning Dev Kit loads saved channel data on startup so that multiple pieces can be read at the same time rather than one after another. The change introduces a small amount of `unsafe` Rust code, but the included safety comment explains why the authors believe it is correct. There is no indication in the commit that this fixes a vulnerability or that it creates one.

This commit adds a test-only option to make hash map iteration order deterministic. It does not change production code and has no security relevance. It is purely a testing convenience for comparing test logs across runs.

This change only affects internal test code. It adds an environment variable so developers can choose a fixed block-connect style during testing instead of having one picked at random. There is no production code change and no security impact.

This commit is a pure code cleanup: it extracts long error message strings into local variables before building the same error return values. There is no functional change, no security fix, and no change to what the program does.

This is a minor internal code cleanup in the Lightning Dev Kit's channel handling. It changes how a function accepts several lists of pending actions, switching from mutable references that append into internal storage to a style that consumes the vectors directly. There is no user-visible behavior change and no security relevance.

This commit is purely a code-formatting cleanup. It removes `#[rustfmt::skip]` annotations from three methods in the Lightning channel code and lets rustfmt reformat the function signatures, calls, and log statements across multiple lines. No logic, behavior, or security checks were changed.

This commit only adds a logging parameter to an internal helper function and its callers. It does not change program logic, state handling, or security behavior. The change is purely for better observability when channel monitor updates are paused.

This commit only adds a pending changelog note. It documents that outbound payments waiting for a BOLT 12 invoice response will fail to complete after upgrading to version 0.3. There is no code change, no vulnerability, and no security fix in this commit itself.

This commit refactors how the Lightning Dev Kit tracks whether a BOLT12 invoice is tied to a Refund versus a regular InvoiceRequest. Previously, one shared context type was used for both, which could lead to ambiguous handling. The change splits that shared context into two distinct variants and adds checks so that Refund-only contexts are only accepted for Refund invoices and InvoiceRequest contexts only for Offer invoices. It is a hardening/correctness change rather than a clear-cut security fix, but it removes ambiguity that could in principle be abused to trick the code into accepting an invoice in the wrong context.

This commit changes how Lightning Dev Kit builds private 'blinded paths' used to route messages without revealing the recipient's exact location. It makes the default router choose shorter, more compact paths when the message is part of a BOLT 12 offer that might be encoded in a QR code, and longer, padded paths otherwise. The goal is to balance privacy with fitting data into QR codes and payment onions. The change itself is a privacy-tuning improvement, not a direct security bug fix, though it touches code that affects how easily a recipient can be identified.

This commit fixes a privacy leak in Lightning onion messages. When building a blinded path with fake 'dummy' hops, the program previously did not always hide the size of the data carried at each hop. That made the dummy hops easy to spot, defeating their purpose. The patch adds a new padding mode so that every non-final hop is padded to the same length, keeping dummy hops indistinguishable from real ones. It also lets compact paths use this same minimal padding instead of skipping padding entirely.

This commit only adds a three-line documentation comment explaining when developers might want to use a specific message-routing helper. It does not change any code behavior, fix a bug, or alter security logic.

This commit adds a small convenience helper that converts an LSPS5 webhook notification into a JSON string. It is purely a developer-experience improvement and does not change any security behavior.

This is a routine code cleanup that changes how a BOLT 11 invoice exposes its payment hash. Previously the function returned a raw SHA-256 hash object; now it returns a typed PaymentHash wrapper. All callers are updated to use the new type. There is no security bug being fixed here and no behavior change to the Lightning protocol logic.