rust-lightning

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 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 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 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 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 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 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 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 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 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 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 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.

This commit is a routine internal code cleanup in the Lightning Dev Kit's Rust implementation. It removes a wrapper type called ChannelSignerType that previously distinguished between different kinds of channel signers, because the project now plans to support only one signer type (ECDSA). The change simplifies function signatures and removes now-unnecessary pattern matching, but does not fix a security bug or change cryptographic behavior.

This commit removes an unused experimental Taproot/MuSig2 code path from the rust-lightning project. It deletes the optional `musig2` dependency, removes the `taproot` build flag, and strips out all conditional Taproot-related message fields and serialization logic. There is no indication this fixes a security vulnerability; it is a cleanup change because Taproot support is not currently planned and the external `musig2` crate is now owned by a third party.

This commit removes an unfinished Taproot-specific signer type from the Lightning Dev Kit codebase. The removed code was behind a special compile-time flag ('taproot') and consisted almost entirely of placeholder 'todo!()' stubs that did not actually sign anything. The change is a cleanup/refactoring step toward having one unified channel signer type, not a security fix.