Core Lightning

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 is a one-line type correction in a Lightning plugin. The code now reads an unsigned 64-bit integer (u64) instead of a truncated unsigned 64-bit integer (tu64) when fetching the optional 'extra_fee' amount from custom TLV data. The change aligns the implementation with BLIP-25's specification and is best understood as a protocol-compliance fix, not a security patch. There is no direct evidence in the commit or supplied references that this fixes an exploitable vulnerability.

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 is a minor cleanup of test code only. It replaces a manual three-step process for adding money to a test Lightning node with a single helper call. No production code was changed, and there is no security relevance.

This commit adds experimental support for multi-part payments (MPP) in a new Lightning Service Provider (LSP) feature called LSPS2. It is a feature addition with test code, not a security fix. There is no indication in the commit that it patches a vulnerability or that the project treats it as a security-relevant change.

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 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 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 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 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 changes a single number in the code that creates 'just-in-time' (JIT) channels for Lightning Service Providers (LSPs). The old number enabled 'anchor' channels, which are a newer channel type. The new number disables anchors and falls back to a more basic channel type. The stated reason is that the Elements sidechain does not support anchor channels yet. This is a compatibility/configurability change, not a fix for an active security flaw.

This commit temporarily stops an experimental Lightning Service Provider (LSP) plugin from advertising a specific protocol feature to other nodes. The change is described by the developer as a short-term workaround to make automated tests pass, not as a security fix. It removes the public announcement of a feature bit while leaving the rest of the plugin's code in place, with a note that the underlying startup-order problem should be fixed later.

This commit removes a line that forced a channel reserve to zero in a Lightning plugin's response. A zero reserve could let one side drain a payment channel without keeping the usual safety buffer, potentially making it easier to cheat or destabilize the channel. The change is small and self-described as a development mistake, but the security implications depend on how the plugin is used and whether other protections remain in place.

This change makes a Core Lightning plugin less strict about a peer advertising a specific optional feature flag (the 'LSP feature bit'). Previously, if a peer didn't advertise that bit, the plugin would refuse to talk to it. Now it logs a warning and continues. This is a spec-compliance/usability improvement, not a clear security fix, but it slightly increases the chance of connecting to a peer that doesn't truthfully advertise its capabilities.

This commit is a small cleanup in a Core Lightning plugin. It moves the logic for reversing a list of feature bits into a shared helper function so callers don't have to remember to reverse the bytes themselves. The change is defensive: it reduces the chance of future mistakes when checking whether a peer supports a particular Lightning feature. There is no direct evidence in the commit of an active security bug being fixed, but the change is security-relevant because incorrect feature-bit checks could cause the plugin to misidentify peer capabilities.

This commit only adds user-facing documentation describing three already-existing experimental configuration options for a Lightning Service Provider (LSP) plugin. There are no code changes, no behavior changes, and no security fixes.

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 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 improves error handling in a Core Lightning plugin's list-protocols feature. It replaces a programming panic (an abrupt crash) with proper error messages when something goes wrong, and adds clearer logging. There is no direct evidence this fixes an exploitable security vulnerability, but it does make the plugin more robust and easier to diagnose.

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