rust-lightning

This commit only adds a new automated test for an existing feature. It does not change any production code, so it cannot introduce a security vulnerability or fix one. The test checks that a new asynchronous mode of the ChainMonitor component correctly waits for background writes to finish before reporting them complete.

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 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 Rust code cleanup change. It relaxes the compiler requirements on a trait called FutureSpawner so that it only demands thread-safety guarantees in standard (std) builds, matching the requirements already placed on the spawned futures themselves. There is no security-relevant behavior change.

This commit changes a test-only mock storage helper (TestStore) so that its simulated asynchronous file writes no longer finish instantly. Instead, tests can now manually control when those writes complete. It is purely a testing-infrastructure improvement and does not change any production code, real user data handling, or network behavior.

This commit is a code cleanup in the Lightning Dev Kit's storage layer. It removes a special-case code path that read an old channel monitor just to decide which stale monitor updates to delete. Instead, it reuses an existing list-and-delete helper. The change only affects how old data is cleaned up after a channel is closed, and the commit message explicitly says the removed path is no longer expected to be hit. There is no direct evidence this fixes a security vulnerability.

This commit refactors internal persistence code in the Lightning Dev Kit to support asynchronous storage backends. It does not fix a known bug or add a user-facing feature. The main risk is that the new async plumbing could, if misused in future commits, allow monitor writes to complete out of order or fail silently. Right now the code is marked pub(crate), uses a placeholder spawner that panics in the synchronous wrapper, and includes TODO comments noting that completion notification is not yet implemented. There is no evidence this commit itself introduces an exploitable vulnerability.

This commit adds a new test-only helper that lets the project's own test suite collect and manually run background async tasks. It is not used in production code and does not change any existing behavior that could affect real users.

This commit adds a new beta way for the Lightning Dev Kit's ChainMonitor to save channel state using native Rust async/await. It is a feature/refactoring change, not a fix for a known vulnerability. The commit message explicitly labels the new API as beta and warns that bugs may be triggered by its use. There is no claim in the commit or supplied references that this resolves a security issue.

This commit only changes test code. It replaces direct construction of a test helper object with its public constructor and swaps one test logger for another. There is no change to production code or user-facing behavior, and no security issue is present.

This is a small, intentional behavior change in a Lightning node library. It lets users set a configuration value to 0 to fully turn off a special monitor-update writing mode, making the component act like a simpler default version. The change itself is not a security fix; it is groundwork for a later feature and removes a special marker byte from saved files when the feature is disabled. There is no indication of a vulnerability being patched.

This commit simply moves an existing Rust trait called FutureSpawner from one internal crate (lightning-block-sync) into the main lightning crate so it can be reused more widely. It does not change any behavior, fix a bug, or alter security logic. There is no security issue visible in this patch.

This commit is a routine internal refactoring of a Lightning node storage helper. It rewrites the existing synchronous `MonitorUpdatingPersister` to be a thin wrapper around a new asynchronous implementation, without changing how data is stored, encrypted, or validated. The new async code is explicitly marked as beta and is not yet exposed to users. There is no indication this fixes or introduces a security vulnerability.

This commit is purely a code cleanup and formatting change in a single Rust file. It extracts repeated namespace constants into local variables and adjusts line wrapping to satisfy rustfmt. There is no functional change, no bug fix, and no security relevance.

This commit fixes a flipped comparison in Lightning Dev Kit's gossip message forwarding. During a background sync, nodes share old channel announcements in order. To avoid sending updates before their matching announcements, the code was supposed to temporarily hold back fresh updates for channels not yet synced. Instead, the comparison was backwards, so it held back updates for already-synced channels and forwarded only updates for not-yet-synced channels. The fix changes the comparison direction and adds a test to confirm the correct behavior.

This commit is a developer-convenience change only. It adds named constants like NO_ONION_MESSENGER and NO_LIQUIDITY_MANAGER so users don't have to write out complex Rust type names when they don't need those optional features. There is no security fix or behavior change.

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 only adds explanatory comments to existing code in the Lightning channel re-establishment logic. No behavior was changed, no bugs were fixed, and no security vulnerability was introduced or patched.

This commit tightens the rules for re-sending a 'commitment_signed' message during Lightning channel reconnection when a new interactive funding transaction (such as a splice) is in progress. Previously, the code retransmitted commitment_signed whenever a flag was set; now it also requires that the peer's transaction signatures ('tx_signatures') have not yet been received. This avoids redundant or incorrect retransmissions and better aligns the implementation with the Lightning protocol specification.

This commit is a straightforward internal code cleanup in LDK's interactive transaction construction. It replaces a hand-written transaction weight calculation with the standard Bitcoin library's weight method by storing the actual Transaction object inside ConstructedTransaction. There is no indication this fixes a security bug; it appears to be a refactor to remove duplicated logic and simplify serialization.

This commit removes a stored 'weight' field from a transaction-input data structure and instead calculates the weight on the fly when building a transaction. It is a code-cleanup and data-format simplification. There is no direct evidence in the commit that this fixes a security vulnerability, but any change to fee/weight calculations in Bitcoin-related code deserves a careful look because mistakes there can affect transaction validity or fees.

This commit is a straightforward internal refactoring of how transaction input weights are tracked during interactive transaction construction in the Lightning Dev Kit. It splits the previous estimated input weight into a fixed base weight plus a separately stored 'satisfaction weight' (the variable signature/script portion). The total weight used for fee calculations remains the same, and there is no indication of a security bug being fixed.

This is a routine internal code cleanup in a Bitcoin Lightning library. It changes how funding transaction inputs are passed between components so that one data type (FundingTxInput) is carried further through the code instead of being converted earlier. The commit message says this removes an unnecessary conversion and memory allocation, and prepares for a future refactor. There is no indication of a security fix or behavior change that would affect users.

This commit is a test-only cleanup. It simplifies a single unit test by removing unused setup code and replacing hardcoded cryptographic secrets with deterministic test helpers. There is no change to production code, no security fix, and no vulnerability introduced.