Core Lightning

This commit fixes a bug in Core Lightning where money-transfer promises (HTLCs) stuck in a special 'withheld' channel were silently dropped when that channel was force-closed. Previously, the upstream sender was never told the payment failed, so it would eventually force-close its own channel waiting for a resolution that would never arrive. The patch now explicitly fails those HTLCs back upstream before freeing them, preventing unnecessary channel force-closures and fund lockups.

This change adds the payment preimage to a plugin notification that fires when a forwarded Lightning payment succeeds. The preimage is already known to the node at that moment, so nothing secret is being exposed that wasn't already available internally. It is a feature enhancement, not a security fix or vulnerability.

This fix ensures that when a user opens a 'zero-confirmation' channel whose funding transaction is deliberately withheld and then the channel is closed/aborted, any bitcoin inputs that had been set aside (reserved) for that funding transaction are released back to the wallet promptly. Before this fix, those coins could stay locked up until an automatic timeout expired, making them unavailable for other payments or channel opens.

This commit fixes a bug in Core Lightning's 'reckless' plugin command. Previously, if the external 'reckless' program could not be launched (for example, because it was missing from the system PATH), the RPC command would hang indefinitely instead of reporting an error. The patch makes the plugin return a clear failure message when the program cannot be executed.

This is a small code cleanup in Core Lightning's channel gossip handling. It changes two helper functions so they no longer return a true/false success value. The actual behavior—when to send announcement signatures and when to stop on errors—appears unchanged. The commit title says 'fixup!' which typically means it is polishing an earlier commit rather than fixing a new bug. There is no direct evidence this is a security fix.

This change fixes a compatibility issue between Core Lightning and the Eclair Lightning node implementation during a channel-splicing reconnect. Previously, Core Lightning would fail the connection if Eclair sent a CHANNEL_READY message while a splice was being resumed. The patch teaches Core Lightning to accept and process that out-of-order message instead of treating it as an error. It is a protocol-handling fix rather than a memory-safety or cryptographic bug, and the commit message frames it as interoperability, not security.

This is a small follow-up fix to a recent splice-resume feature in Core Lightning's channel daemon. It removes a hard abort when an unexpected ERROR message arrives during a splice, and instead lets the daemon handle certain allowed out-of-order messages (like CHANNEL_READY) while waiting for the expected splice messages. The change is defensive and appears aimed at preventing the node from crashing during legitimate splice resume flows.

This patch fixes a crash in Core Lightning's lightningd daemon that could occur during splice-related RPC operations. The root cause was that splice command state could be consumed by external failures (like a peer rejecting the splice) while callbacks still held a stale pointer to it. The fix stops storing the splice command pointer inside callback data structures and instead looks it up fresh from the active list when needed, avoiding use-after-free-style crashes.

This commit changes how Core Lightning handles reconnection with another Lightning node. It adds a way for the peer to ask for 'announcement signatures' again after reconnecting, and makes the node resend them when asked. This is part of a protocol update for splicing. It is not a traditional security fix; it is a protocol compliance/robustness change that could help prevent channel announcement issues after reconnections or splices.

This commit fixes a log message in Core Lightning's channel daemon so it correctly lists all three message types the code accepts. It also adds a check during peer reconnection and aborts if an error message is received. The changes are defensive hardening and logging corrections, not a fix for an exploitable security vulnerability.

This change adds logging when the Core Lightning routing plugin (askrene) fails to remove a temporary channel-capacity reservation. Previously these failures were silently ignored, which could cause reservations to 'leak' and remain in place longer than intended. The patch only adds diagnostics; it does not fix the underlying removal failure or the leak itself.

This commit adds a hidden developer-only option called dev_remove_all to the askrene-unreserve command. When enabled, it clears all capacity reservations managed by the Askrene plugin instead of only unreserving the specific path provided. The feature is marked as hidden and intended for development/testing use. There is no indication in the commit that this fixes a security vulnerability; it appears to be a convenience tool for developers.

This commit only adds a new automated test to check that a routing-reservation leak does not occur. It does not change any production code, so by itself it cannot introduce or fix a security vulnerability in running software. The test may be related to a known bug, but the commit message and diff do not describe a fix or disclose security relevance.

This commit is a routine packaging fix. It moves a Python library called 'mnemonic' from the main project's dependency list into the dependency list of a smaller sub-package (pyln-testing). This ensures that anyone installing only pyln-testing gets the missing library. There is no security vulnerability or code behavior change here.

This commit is a straightforward internal code change in Core Lightning's bookkeeping for payment commitments (HTLCs). It adds a new flag called WILL_SEND to track whether more messages still need to be exchanged before a payment update is fully settled. The change is described by the developer as groundwork for the 'splicing' feature and contains no obvious security fix or vulnerability.

This is a test-only reliability fix. A developer saw an occasional test failure where one background tracing call had not finished by the time the test ended. The patch adds a diagnostic line to the trace output and relaxes the test assertion to allow exactly one suspended call at shutdown, rather than requiring zero. There is no indication this affects real users, funds, or network security.

This patch fixes a hang in Core Lightning's experimental splicing feature. Previously, once a node decided to enter 'quiet' mode (STFU) for splicing, it would stop sending all outgoing channel update messages, including the commitment_signed message the other side was waiting for. The fix lets messages that are already in flight go out, and only blocks brand-new activity once STFU has actually been sent. This prevents the two peers from deadlocking during a splice when a closing payment is still pending.

This commit simplifies how Core Lightning decides whether a channel still has unfinished updates before entering a quiet 'STFU' mode. It removes an 'uncommitted_ok' option that was never actually used as true, and replaces a hand-rolled check with a clearer flag named HTLC_F_WILL_SEND. The change also adds temporary debug logging that prints each HTLC's state when STFU is considered. There is no direct evidence in the commit that this fixes a security bug, but any change to state-machine logic around pending updates can affect protocol correctness.

This is a routine release-version bump from v26.03 to v26.04 across documentation, generated schema files, and one source file. It also fixes a test so that a deprecated database column is actually allowed when deprecated APIs are enabled. There is no security vulnerability here; it is ordinary release housekeeping.

This commit fixes a code-generator bug in Core Lightning's message generator (msggen). Previously, newly added RPC commands and fields could fail to build because version metadata wasn't inherited from parent objects. The patch makes the generator propagate 'added' and 'deprecated' annotations correctly and updates the generated RPC model files, gRPC proto, and JSON schema metadata to match. It is a build/tooling correctness fix, not a runtime security patch.

This commit updates Core Lightning's automatic message-schema generator (msggen) so that the oldest supported protocol/API version is raised from v0.10.1 to v24.11. As a result, many fields that were previously marked optional in the generated gRPC/JSON-RPC bindings are now marked required, because modern Core Lightning always returns them. This is a routine compatibility and code-generation cleanup, not a fix for an exploitable vulnerability.

This commit fixes a bug in the lightning-cli command-line tool. Previously, if a user typed a numeric string starting with zero (like '0123'), the tool would send it to the lightningd server as a bare number. In JSON, numbers with leading zeros are invalid, so plugins written in Rust or Python could crash when parsing the request. The fix forces such strings to be quoted, making them valid JSON strings instead of invalid numbers. A previously-skipped test that checks for valid JSON from the CLI is re-enabled.

This commit only adds a new test case (currently skipped) and a tiny helper plugin. It does not change any production code, so it cannot by itself fix or introduce a security vulnerability. The test is meant to check that the lightning-cli command-line tool sends JSON values correctly when a numeric-looking string has a leading zero, which some JSON parsers reject as invalid integers.

This change makes the 'xpay' payment plugin more willing to take over payments that were originally sent to the older 'pay' command. Previously, if 'pay' received an argument that xpay did not understand, xpay would refuse to handle the payment and the older 'pay' logic would run instead. Now xpay logs that it does not recognize the argument, ignores it, and still redirects the payment through xpay. This is a behavior change, not a clear-cut security fix, and could in theory cause payments to be processed with options that xpay silently drops.

This commit fixes how transaction IDs (txids) are encoded when the 'close' command response is sent over the gRPC interface in Core Lightning. Previously, the txids were likely passed through as plain strings instead of being decoded from hex into raw bytes, which could cause the gRPC layer to produce malformed or unexpected data for clients. The fix also updates the code generator so future txid fields are handled correctly in both directions.