rust-lightning

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.

This commit is a routine internal refactoring of the Lightning Dev Kit's LSPS1 service handler. It replaces a manual user-provided timestamp parameter with an internal TimeProvider trait, so the code automatically fills in the creation time when a new order is created. There is no security bug being fixed here; it is purely a cleaner API design change.

This commit is a straightforward internal code cleanup. It removes a thin wrapper struct named OutboundCRChannel and uses the underlying ChannelOrder type directly in a hash map. There is no change to user-facing behavior, no bug fix, and no security-related modification.

This commit changes how a Lightning liquidity service responds to order-status lookups. Instead of asking the user/LSP to check payment status every time a client asks, it now answers immediately from saved state and lets the user/LSP push updates only when something actually changes. The change removes one event type and one callback step. It is a design/API refactor, not a clear security fix, though it does add a proper 'order not found' error response for unknown orders.

This commit fixes a bookkeeping bug in the LSPS1 (liquidity service) module. Previously, when a service updated an order's status (e.g., paid, channel opened), it did not actually store the new state or channel details in its internal record. The response was sent with the new state, but the internal `ChannelOrder` was left stale. This could cause the service to report inconsistent order information later, for example when a client later queries the order. The patch now stores and updates the order state and channel details correctly.

This commit removes several risky 'unwrap' calls in the LSPS1 liquidity service by making the 'supported_options' configuration field mandatory. Previously, if a service operator forgot to set this field, the code would panic (crash) when handling certain requests. Now the compiler enforces that the field is always provided, preventing that crash path at build time.

This commit refactors how LSPS1 (a liquidity service protocol) tracks pending requests. Previously, code directly inserted or removed entries from an internal map. Now it uses two controlled methods that check for duplicate request IDs and unknown request IDs, returning clear errors instead of silently overwriting or missing entries. This is a defensive hardening change that reduces the chance of request-state confusion, but the commit itself does not claim to fix a specific exploitable vulnerability.

This is a small internal code cleanup in the experimental LSPS1 (liquidity service) module. It hides a private map behind two helper methods and renames some fields for clarity. The commit message explicitly says it does not fix any bug, only improves isolation. There is no direct security fix here.

This commit simply removes a former team member's contact information from the project's security policy file. It is an administrative cleanup, not a code change, and has no security vulnerability or functional impact.

This commit makes HTLC resolution events durable in the ChannelMonitor so they survive restarts. Previously, if a ChannelMonitor was persisted but the ChannelManager crashed before persisting, monitor events could be lost, potentially causing payment failures or funds to be stuck. The fix adds an acknowledgment mechanism: events are retained until the ChannelManager explicitly acks them, and unacked events are replayed on startup. A large test that verified the old, lossy behavior was removed.

This change only modifies an internal fuzz-testing harness. It splits a test control so that a simulated signer can be re-enabled for one channel at a time instead of all channels at once, purely to improve fuzzing coverage. There is no change to production code, no user-facing behavior, and no security fix.

This is a tiny code cleanup that removes two unnecessary .clone() calls in a Lightning channel implementation. It does not change behavior, fix a bug, or address any security issue. It is purely a performance/maintainability micro-optimization.

This commit only changes where and how debug log messages are printed during peer reconnection. It moves a single log line deeper into the code and adds more detailed logging for each type of reconnection message. There is no change to program logic, message handling, or security behavior.

This commit is a routine API refactor for the experimental splicing feature in rust-lightning. It moves feerate parameters from the splice_channel/rbf_channel calls into the later FundingTemplate methods, and exposes a minimum RBF feerate floor so users can pick a valid feerate. It is not a security patch and does not fix a known vulnerability; it changes how users interact with the splicing API.

This commit changes how Lightning Dev Kit handles internal notifications called 'monitor events' that report things like completed payments or forced channel closures. Previously these events were not formally acknowledged after being processed. Now the code immediately acknowledges each event after handling it. This is a groundwork change to allow these events to be stored persistently in the future, so they can be safely replayed after a restart. It is described by the authors as behaviorally equivalent to the old code for now, not a security fix.

This commit simply removes a GitHub Actions workflow that automatically used an Anthropic Claude AI tool to review pull requests. The project maintainers decided to run that review process externally instead of inside GitHub's CI system. No application code, cryptographic logic, or user-facing behavior changed.

This commit is a pure code cleanup in a test file. It rewrites parts of the reorg_tests.rs file so lines are shorter and easier to read, without changing what the tests actually do or any production code.

This change loosens the maximum 'dust limit' that rust-lightning will accept from a channel peer, but only for modern channel types that use zero-fee HTLC transactions (keyed-anchor and 0FC channels). For older channel types the old, stricter 546-satoshi limit remains. The patch is a protocol-compliance/robustness fix rather than a clear vulnerability fix, and it includes a test update.

This commit changes how Lightning channels set a minimum 'reserve' amount that each side must keep in the channel. The reserve is now forced to be at least as large as the other side's 'dust limit' (the smallest transaction output considered worth tracking). Without this, a peer could set a very high dust limit while the reserve stayed low, potentially allowing tiny outputs to be treated as non-existent or causing the channel's accounting rules to disagree between the two sides. The change is defensive and prepares for a later feature allowing larger dust limits.