Core Lightning

This commit refactors error handling in a Core Lightning plugin so that when something unexpected happens during payment processing, the plugin returns 'continue' instead of stopping or crashing. The change is defensive: it makes the plugin more resilient by avoiding hard failures that could disrupt normal routing. However, it also means some errors are now silently swallowed and logged only at debug level, which could hide problems. There is no direct evidence this fixes a known security vulnerability; it appears to be a robustness improvement.

This commit adds a cleanup step to the experimental LSPS (Lightning Service Provider Specification) plugin. When a JIT-channel invoice is fully paid, the plugin now deletes its stored record from Core Lightning's datastore. The change is defensive housekeeping rather than a fix for an active vulnerability, and the commit message does not describe any security issue.

This commit only reformats a test file by changing two single-quoted strings to double quotes and adding trailing commas. It does not change any real code behavior or fix any security issue.

This commit is a routine code cleanup (refactor) in the Core Lightning 'lsps-plugin'. It moves the handler for the 'lsps0.listProtocols' JSON-RPC method into its own file and adds a flag so the handler can later include protocol number 2 in its response when enabled. Currently, the flag is hard-coded to false, so the behavior is unchanged from before: the handler still returns an empty list of protocols. There is no security fix or vulnerability visible in this change.

This commit simply renames configuration options and internal command names in the LSPS (Lightning Service Provider Specification) plugin to follow the project's naming convention. 'dev-' prefixed names are changed to 'experimental-' prefixes, and some internal RPC command names are updated. There is no security fix or vulnerability here—it's a cleanup and consistency change.

This commit removes a redundant developer-only configuration flag from an experimental Lightning Service Provider (LSP) plugin. Previously, users had to enable both a general 'LSPS service' flag and a separate 'LSPS2 service' flag. The change makes the LSPS2 flag alone control whether the plugin runs. It also adds a clear error if LSPS2 is enabled but its required secret is missing. There is no direct security vulnerability here; it is a code cleanup that slightly reduces configuration confusion.

This commit only reformats Python test files and a test plugin. It adjusts whitespace, quote style, line breaks, and removes a couple of unused local variables. There is no change to production code, no security fix, and no behavior change in the software users run.

This commit adds a helper function in the LSPS (Lightning Service Provider Specification) plugin that attaches the sender's peer ID to incoming JSON-RPC messages before passing them to the internal handler. It is a plumbing/infrastructure change to make routing responses easier. There is no direct security fix or vulnerability being patched; it is a feature addition with some minor robustness checks.

This commit adds basic building-block types for a new Lightning Service Provider (LSP) plugin in Core Lightning. It introduces Rust code to represent money amounts (millisatoshis), fee rates (parts-per-million), channel IDs, and timestamps, plus tests. There is no security fix or vulnerability here; it is ordinary feature development.

This commit simply renames a parameter in the LSPS (Lightning Service Provider Specification) plugin from 'peer' to 'lsp_id'. It is a straightforward API naming change with no apparent security implications.

This commit hardens a Core Lightning plugin for the Lightning Service Provider (LSP) protocol. Before sending a request, the plugin now verifies that the target peer is currently connected and advertises the required LSP feature bit. It also makes the plugin advertise that feature bit itself. The change is defensive: without it, a user could accidentally send an LSP request to a peer that does not support LSPs, likely causing the request to fail or behave unexpectedly.

This commit adds new data models and configuration options for an experimental LSPS2 (Lightning Service Provider Specification 2) feature in Core Lightning's LSP plugin. It is a feature-implementation patch, not a security fix. There is no indication in the commit or supplied references that it addresses a vulnerability, incident, or security disclosure.

This commit adds a new feature to the experimental LSPS (Lightning Service Provider Specification) plugin, allowing a client to request a 'just-in-time' channel purchase from a service provider and the service to handle that request. It is a feature addition to a development plugin, not a fix for a known security bug. The code includes validation of fee parameters and basic bounds checks, but because it is new and touches payment-related logic, it introduces some risk of implementation flaws.

This commit adds an experimental service-side feature for Core Lightning's LSPS2 plugin that automatically opens a new Lightning channel when a payment arrives for an unknown peer. The code is marked as experimental and incomplete by its own author, with several 'Fixme' notes indicating future hardening is needed. The main operational risk is that a public LSP could have its on-chain funds drained by attackers who trigger many automatic channel opens. The commit itself does not claim to fix a security bug; it is a new feature implementation.

This change adds a warning log in the LSPS (Lightning Service Provider Specification) plugin when the extra fee reported by an LSP does not match the expected amount. It does not actually reject the problematic payment; it only logs a warning and includes a developer note saying a strict implementation should reject it. The change also removes some older placeholder comments and simplifies how the invoice total amount is determined.

This commit adds a security check in Core Lightning's LSPS (Lightning Service Provider Specification) plugin so that the client only accepts 'zero confirmation' channels from LSPs it has previously approved for a JIT (just-in-time) channel. Before this change, the plugin blindly allowed any zero-conf channel opening, which could let a malicious or mistaken LSP open a channel the user never requested. The patch stores an approval record when the user approves a JIT channel, then checks that record when an open-channel request arrives, deleting it after use. A new test confirms that unapproved zero-conf channels are rejected.

This commit changes a Core Lightning plugin so that when a user requests a just-in-time Lightning channel, the label and description they provide are passed through to the generated invoice instead of being replaced with placeholder or auto-generated values. It also removes an unused label generator and simplifies how payment sizes are handled. There is no direct security bug being fixed here; it is mostly an API usability and correctness improvement.

This commit adds a new feature to Core Lightning's experimental LSPS (Lightning Service Provider Specification) plugin. It lets a client ask a service provider for its current fee menu, and the service plugin fetches that menu from a separate policy plugin. The change is mostly feature work, but it introduces a few places where malformed input or a misbehaving policy plugin could cause errors or unexpected behavior. There is no indication this fixes a known security bug or is being treated as a security patch by the project.

This is a small Rust code cleanup in a Lightning Service Provider (LSP) plugin. It changes a function parameter from accepting any value that can be converted into an optional string, to only accepting an already-optional string. There is no indication this fixes a security bug; it appears to be a routine type-simplification change.

This commit adds an opt-in 'dev-lsps-client-enabled' flag so the experimental LSPS client plugin only runs when explicitly enabled. It also renames the existing service flag for consistency and moves the service setup to happen only after the flag is checked. There is no direct security fix here; it is a hardening/guardrail change to prevent an unfinished experimental feature from being active by default.

This commit fixes a bug in Core Lightning's 'keysend' payment feature where invoice descriptions between 641 and 1023 bytes long were incorrectly rejected. The keysend plugin used a hard-coded 1023-byte cutoff, while the rest of the software enforced a stricter 640-byte BOLT11 protocol limit. The patch makes keysend use the same shared limit, so medium-length descriptions now work correctly. This is a reliability/standards-compliance fix rather than a critical security vulnerability.

This fix stops Core Lightning from creating invalid BOLT11 invoices when a user supplies a 640-byte payment description. Previously the software treated 640 bytes as acceptable, but the Lightning protocol only allows 639 bytes, so a 640-byte description produced a malformed invoice that other wallets might reject or fail to parse correctly. The change tightens the length check and updates an internal constant so the limit is now correctly 639 bytes.

This commit simply removes extra debug log messages from a sorting function used during splicing. No code behavior changes; it only reduces log noise.

This commit tightens how Core Lightning handles commitment messages during splicing (a way to resize a Lightning channel). It removes an internal 'await commitment success' flag and instead follows stricter BOLT specification rules: requiring a batch of commitment_signed messages when splices are pending, requiring a funding_txid in those messages, and failing the channel with an error if those rules are violated. The change is framed as spec conformance, but it also removes a lenient 'ignore stale commit_sig' path that previously could have let mismatched messages pass during a splice race.

This commit updates a local HTML helper tool used to view test logs. It adds a convenience feature to open logs from multiple test nodes in separate browser tabs. There is no indication this change affects real Lightning node operations, wallets, network protocol handling, or any production code.