rust-lightning

This commit only rewords a documentation comment in the source code. It does not change any code logic, fix a bug, or alter behavior. The change clarifies that each pending monitor update ID must still be individually marked complete even after a full ChannelMonitor has been persisted. There is no security vulnerability being patched here.

This commit is a straightforward code cleanup inside the project's test suite. It pulls repeated setup code for creating a fake ChannelMonitor into a single shared helper function called dummy_monitor. There is no change to production behavior, no bug fix, and no security-sensitive logic added or altered.

This commit is a pure code reorganization (refactor) in the Lightning Dev Kit's chain monitoring code. It moves the existing logic for watching and updating a channel into new internal helper methods, while the public trait methods now simply call those helpers. No behavior changes, security fixes, or new features are introduced.

This commit adds a new 'deferred' mode to ChainMonitor, a component that watches blockchain events for Lightning payment channels. When deferred=true, the watch methods currently panic with unimplemented!(). All existing callers pass false, so normal behavior is unchanged. This appears to be a partial feature implementation, not a security fix or vulnerability.

This commit fixes validation checks in a Lightning service feature (LSPS1) that lets users place orders for liquidity. Previously, the code did not verify that an order's requested channel size and confirmation settings stayed within the service's advertised limits. The patch adds those missing checks and also protects against a rare integer overflow when adding two balance amounts together. A malicious or malformed order could have slipped through and caused the service to accept terms it never intended to offer.

This small patch fixes a messaging bug in a Lightning liquidity service. Previously, if a client sent a duplicate request ID, the server would log an error but would not tell the client that the request was rejected, leaving the client waiting for a response. Now the server sends an explicit rejection message back to the client. The main risk is a mild denial-of-service or confusion from duplicate/lingering request IDs, not theft of funds or remote code execution.

This commit adds rate limits to the LSPS1 (a Lightning liquidity service protocol) server code. It caps how many unfinished order requests a single peer can have open, how many total unfinished requests can exist across all peers, and how many distinct peers can be tracked. Requests that exceed these limits are rejected with a standard error. This is a defensive hardening change to prevent a malicious or buggy peer from consuming excessive server memory or processing time.

This commit fixes a bug in two Lightning liquidity service modules (LSPS1 and LSPS2). Previously, if saving data to disk failed partway through, an internal 'persistence in flight' counter would stay stuck above zero. Once stuck, the code would skip all future disk-saving attempts for the lifetime of the running service. This could silently stop important state from being saved, potentially leading to data loss or inconsistent service state after a restart. The fix wraps the save loop in a helper function and always resets the counter to zero afterward, whether the save succeeded or failed.

This commit adds a new method so a Lightning Service Provider (LSP) can cleanly reject a customer's order when the LSP only accepts on-chain Bitcoin payments but the customer did not supply a refund address. Before this change, the code had no explicit way to reject such orders, which could have led to confused or stuck orders. The change is a defensive API improvement, not a fix for an active exploit.

This commit simply removes an unused event variant called Refund from a Lightning Service Provider Specification (LSPS1) event enum. It is a cleanup change with no security relevance: the variant was never used in the code, so removing it cannot introduce or fix a vulnerability.

This commit simply removes an unused data structure called LSPS1OnchainPayment from the rust-lightning codebase. There is no functional code change, no bug fix, and no security impact. It is a routine cleanup that deletes 12 lines of dead code.

This commit only adds new automated integration tests for an existing Lightning Service Provider Specification 1 (LSPS1) order state API. It does not change production code, fix bugs, or introduce new functionality. There is no security-relevant change.

This commit only adds a new automated integration test. It does not change any production code. The test verifies that expired LSPS1 orders are removed from memory during persistence and are not restored after a restart. There is no security fix or vulnerability patch here.

This commit adds a new 'Hold' payment state to the LSPS1 (Lightning Service Provider Specification 1) implementation in rust-lightning. Previously, when a customer paid for a channel, the system immediately marked it as 'Paid' even though the channel had not been opened yet. The new 'Hold' state correctly reflects that the payment has been received but the channel opening is still pending. This is a protocol/specification compliance change that improves state accuracy and reduces the chance of misleading status reporting, but it does not fix a memory-safety bug or an active exploit.

This commit is a code-quality refactor, not a security patch. It replaces a loose 'update_order_status' call with a stricter state machine for tracking LSPS1 channel orders. The change makes invalid transitions explicit errors and keeps payment/channel data tied to the correct states, which reduces the chance of accidental misuse but does not by itself fix a known exploitable vulnerability.

This commit adds validation checks in the LSPS1 (liquidity service) code to make sure a service provider cannot accidentally offer on-chain Bitcoin refunds when the customer never gave a refund address. It also requires at least one payment method and ensures each payment method starts in the correct initial state. The change is defensive: it prevents protocol non-compliance and reduces the risk of funds being sent to an unknown address if a channel opening fails.

This commit adds a new automated test to verify that an LSPS1 service's order state survives a node restart. It does not change production code; it only adds a test case. There is no indication of a security bug being fixed or introduced.

This commit only adds a new automated test for an existing feature. It does not change any production code, fix a bug, or introduce new behavior. There is no security issue here.

This commit adds a new API method called invalid_token_provided to the LSPS1 (Liquidity Service Provider Specification 1) service handler in rust-lightning. It lets a Lightning Service Provider (LSP) tell a client that the token they used to request a channel is invalid or stale, using error code 102 as proposed in a community draft. The change also removes an unused token field from the service configuration struct. There is no direct security vulnerability here; it is a protocol/API improvement that makes error handling clearer and removes dead configuration.

This commit changes two peer-disconnection handlers in the lightning-liquidity crate so they take a read lock instead of a write lock on shared peer state. The stated reason is simply that a write lock is unnecessary. The change reduces lock contention and may prevent a potential performance or liveness issue, but the diff alone does not show a concrete security vulnerability being fixed.

This commit is a routine code cleanup that fixes style warnings reported by the Clippy linter. It replaces three uses of `format!("static string")` with the equivalent `"static string".to_string()`. There is no functional change, no bug fix, and no security relevance.

This commit removes a Rust compile-time feature flag named `lsps1_service` from the `lightning-liquidity` crate. Previously, LSPS1 server-side code was only included when that flag was set. Now it is always compiled in. This is a build and API cleanup change, not a security fix. There is no indication in the commit or supplied references that this addresses a vulnerability.

This commit fixes a startup bug in the Lightning Dev Kit's liquidity service module. Previously, the LSPS1 service handler was created with an empty set of peer states, ignoring any previously saved data. Now it reads saved peer state from the key-value store during startup, matching how LSPS2 and LSPS5 already worked. This is a reliability/consistency fix rather than an active security vulnerability, but ignoring persisted state could previously lead to duplicate orders, lost channel state, or protocol confusion after a restart.

This commit adds the ability for an LSPS1 (a Lightning service protocol) server to save its per-peer state to disk and to clean up old, expired state. It mirrors the persistence and pruning patterns already used for LSPS2/LSPS5. The change is defensive: it reduces the risk of losing order state across restarts and limits unbounded state growth. There is no direct evidence in the commit of a security vulnerability being fixed; it is a reliability and operational-hygiene improvement.

This commit adds code to save and load LSPS1 peer state data to disk. It is a routine feature addition for persistence. There is no direct evidence in the commit that it fixes a security vulnerability; it is more likely a correctness/robustness improvement for a new feature.