rust-lightning

This commit removes a harmless debug-only assertion in the Lightning Dev Kit's channel handling code. The assertion could be triggered during normal operation when an HTLC (a conditional Bitcoin payment) in a 'holding cell' couldn't be added to a channel due to a dust-exposure limit. Debug assertions only fire in test builds, so production nodes were never affected. The commit also adds a regression test to exercise this edge case.

This commit is a straightforward code cleanup: it removes an internal Rust macro and replaces its two uses with direct calls to the underlying function. There is no indication of a bug fix, behavior change, or security issue.

This commit refactors a Rust macro into a regular method in the Lightning Dev Kit's channel manager. The stated goal is to let callers release internal locks before running follow-up completion actions. The change itself is a code-quality/locking refactor; there is no direct evidence in the commit message or diff that it fixes a known security vulnerability or that any exploit exists.

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's channel manager. It replaces a Rust macro used to handle channel monitor updates with two regular methods, and updates all places that called the macro. There is no change to user-facing behavior, protocol logic, or security-sensitive operations; it is purely a refactoring to make the code easier to maintain and to satisfy Rust's borrow checker.

This commit is a simple code cleanup: it takes a small helper macro used in three places and replaces each use with the macro's actual contents. The behavior of the program is unchanged; only the internal structure is simplified. There is no security issue here.

This commit is a code cleanup: it replaces a Rust macro with a regular method. The behavior is unchanged, but the new method lets callers explicitly drop locks before running follow-up work. There is no indication of a security bug being fixed.

This commit is a code cleanup: it takes a large block of logic embedded in a macro and moves it into two ordinary helper methods, with a new enum carrying the intermediate result between them. There is no change to what the code actually does—only how it is organized. The commit message and diff both describe this as a pure refactor.

This commit is a straightforward internal code reorganization in the Lightning Dev Kit's channel manager. It converts two standalone helper functions into methods on the ChannelManager struct and moves them to a different location in the same file. The only functional change is that a logging context object is now created inside the method when needed, rather than being passed in by callers. There is no user-visible behavior change and no security fix or vulnerability introduced.

This is a documentation-only change that updates an internal code comment to match renamed variable names. No code behavior was altered, and there is no security impact.

This commit changes how the Lightning Dev Kit (LDK) node restores its record of in-flight payment forwards after a restart. Previously, the code preferred newly reconstructed forward maps built from channel monitor data, which required complex de-duplication logic to avoid processing the same HTLC twice. The commit switches production code to always use the older, persisted forward maps instead, while keeping the new reconstruction path active only in tests (randomly or via an environment variable). It also adds a small guard to avoid pushing duplicate intercept events if a restart re-processes an already-handled intercept forward.

This commit is a straightforward performance optimization in the Lightning Dev Kit's channel manager. It changes how pending payment packets (HTLCs) are looked up and removed from a tracking map, replacing a full scan of all entries with a direct lookup by channel identifier. There is no security-relevant change visible in the diff.

This commit fixes a bug in the Lightning Dev Kit where, after restarting a forwarding node, an already-forwarded payment could be forwarded a second time. The bug only affected the node that restarts, and could lead to duplicate HTLCs being sent downstream, potentially causing funds to be locked or payment failures. The fix prunes already-forwarded HTLCs from a rebuilt in-memory map during startup.

This commit is a pure code restructure: it moves an existing `if is_channel_closed` check inside the loops that process HTLCs, rather than wrapping the loops from the outside. The commit message explicitly says it is 'necessary for the next commit and makes it easier to read.' No behavior changes are visible in the diff, and there is no security fix here.

This commit only adds documentation comments to a Rust function. It clarifies which feature flags and conditions are needed to use the splicing feature. No code behavior was changed, so there is no security issue.

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.