Core Lightning

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 experimental support for a new Lightning protocol feature called LSPS2 'just-in-time' (JIT) channels. It lets a user request a payment invoice that, when paid, causes a Lightning Service Provider (LSP) to open a new channel on the fly and forward the payment. The code is marked experimental and contains several TODO/FIXME comments noting that important safety checks are not yet implemented, such as verifying the payment is not a forwarded payment, preventing double payment for the same channel, and checking that the LSP is trusted before accepting a zero-confirmation channel.

This commit adds ordinary helper functions for reading and writing 64-bit unsigned integers inside a type-length-value (TLV) data structure used by a Lightning Network plugin. It is a straightforward feature addition with no visible security bug or fix.

This commit removes a runtime call to unwrap() in a Core Lightning plugin that handles incoming channel requests. Previously, if the JSON payload did not contain an 'openchannel' field, the plugin would panic and crash. The fix introduces a proper typed request structure so the plugin can gracefully handle malformed or unexpected input instead of crashing. It is a defensive hardening change rather than a fix for an active exploit.

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

This commit updates a standalone HTML helper tool used to visualize Core Lightning node logs. It adds logic to recognize log formats produced by continuous integration (CI) runs and Python tests, then strips the node-identifying prefix before rendering. There is no change to the actual Core Lightning daemon, wallet, network protocol, or any cryptographic code. It is a developer/debugging utility enhancement with no security relevance.

This commit adds a new internal telemetry feature: the connection daemon now measures how long ping probe responses take and reports those timings to the main lightningd process. It is a straightforward feature addition with no apparent security implications.

This commit adds a new automatic cleanup feature to the Core Lightning 'autoclean' plugin. By default, network event logs (connections, disconnections, pings) older than 30 days will now be deleted automatically. Users can change or disable this with a new configuration option. There is no indication this is a security fix; it is a routine data-retention and housekeeping feature.

This change improves how Core Lightning reports connection failures. It adds a flag telling the main daemon whether the node actually tried to connect to any address, or couldn't even attempt one (for example, because the peer only offers Tor addresses and this node has no Tor proxy, or only offers IPv6 and this node can't use IPv6). This helps avoid wrongly marking peers as unreachable when the real problem is local network capability. There is no direct security vulnerability being fixed here; it is a reliability and diagnostic improvement.

This commit adds a new 'networkevents' category to the existing 'wait' API, allowing users to subscribe to notifications about peer connection, ping, and disconnect events. It is a straightforward feature addition with no visible security defect.

This commit adds routine logging of network events—successful connections, failed connections, disconnections, and ping latencies—to the node's internal database. It is a bookkeeping/telemetry change, not a fix for a security flaw, and it does not change how the node handles peers or funds.

This commit adds a new read-only data table called 'networkevents' to the experimental SQL plugin. It lets users query network event history using SQL, similar to existing tables. There is no indication of a security bug or vulnerability fix.

This commit adds database infrastructure to record network events (peer connects, disconnects, failed connects, and pings) in Core Lightning. It creates a new database table, adds functions to save and retrieve those events, and updates test stubs. There is no security fix or vulnerability present in the diff itself; it is a feature/infrastructure change.

This change is a straightforward instrumentation patch: Core Lightning's connection daemon (connectd) now records when a peer connection started and reports how long it lasted when the peer disconnects. The data is passed to the main lightningd process and included in internal peer-disconnect/reconnect messages. There is no evidence in the commit of a security bug being fixed or introduced; it appears to be a metrics/logging improvement.

This commit adds a new read-only RPC command called listnetworkevents to Core Lightning. It lets users query a log of network events such as peer connects, disconnects, failed connects, and pings. The change is purely additive: it exposes existing internal event data through a new API and does not alter how funds, channels, or network connections are handled. There is no indication this fixes a security bug or introduces a vulnerability.

This commit adds a new administrative JSON-RPC command called `delnetworkevent` that lets a node operator delete a single diagnostic network event from the local database by its index. It is intended for housekeeping (for example, the autoclean plugin) and does not affect live channels or funds. There is no indication in the commit that this fixes a security bug; it appears to be a routine feature addition.

This commit is a routine internal improvement, not a security fix. It makes the connection daemon (connectd) report back why a connection was attempted and how long it took, alongside existing success/failure messages. This is observability and diagnostic data being added to inter-daemon messages; it does not change who can connect, what they can do, or how funds are protected.

This commit changes how the clnrest plugin pulls in two Rust helper libraries (utoipa and utoipa-swagger-ui). Previously they were downloaded directly from a personal GitHub fork; now they come from the official crates.io registry. The change was made to fix broken Docker and release builds, not because of a known security flaw. Using registry versions is generally safer and more reproducible than an unreviewed git fork, but the commit itself does not claim to fix any vulnerability.