Core Lightning

This commit is a routine code-generation update for Core Lightning's gRPC and RPC bindings. It adds support for three new JSON-RPC commands (createproof, xkeysend, graceful) and a new primitive type (ProofField) used by createproof. The changes are entirely in generated binding code, not in the core daemon logic that actually processes payments, proofs, or shutdowns. There is no indication of a security fix or vulnerability.

This commit is a large, routine cleanup of API metadata in Core Lightning. It marks many old RPC commands and fields as deprecated, removes some long-deprecated fields from generated gRPC/JSON schemas, and fixes version annotations in the code generator. There is no direct evidence of a security vulnerability being patched; the changes are about API lifecycle management and generated bindings.

This is a routine weekly update to the Rust dependency lock file (Cargo.lock), bumping four small helper libraries to their latest patch versions. There is no indication in the commit or supplied references that any of these updates fix a security issue, and the commit message explicitly says 'Changelog-None'.

This commit adds a single entry named 'bwatch' to the .gitignore file inside the plugins directory. A .gitignore file simply tells Git which files or folders to ignore when tracking changes. There is no code change, no bug fix, and no security relevance visible in this commit.

This commit is a routine version bump for a new release candidate (v26.06rc1) of Core Lightning. It updates version strings in packaging files and adds a detailed changelog. No actual source code behavior changes are included in this commit, so it does not introduce or fix any security issue by itself.

This is a routine weekly update to the Rust dependency lock file (Cargo.lock). It bumps several third-party library versions by patch or minor increments and removes one unused dependency. There is no indication in the commit of any security fix, vulnerability, or behavior change in Core Lightning itself.

This commit only adds a README file for the currencyrate plugin. It contains documentation describing how to configure price sources and warning users that stopping the plugin can interrupt invoice creation. There are no code changes and no security fix or vulnerability introduced.

This commit simply deletes an old test that was written to document a known bug. The bug itself was already fixed in an earlier commit, and another test now serves as the regression test. No code behavior changes, and no new security issue is introduced here.

This commit hardens crash recovery in Core Lightning's new block-watching plugin (bwatch). Previously, bwatch would immediately fetch the next Bitcoin block after saving one. Now it waits for lightningd's 'watchman' component to confirm it has also recorded the same block height before continuing. This prevents a situation where bwatch moves ahead of the main daemon, so if the node crashes and restarts, no block that bwatch acted on is invisible to the rest of the system.

This commit adds blockchain reorganization (reorg) handling to Core Lightning's 'bwatch' plugin. A reorg happens when the Bitcoin network temporarily replaces a known block with a different one. Previously, bwatch appears to have blindly trusted each new block's parent hash, which could have left the plugin tracking an invalid or forked chain. The patch detects mismatched parent hashes, rolls back its internal tip one block at a time, and tells another component ('watchman') to do the same. It is a defensive correctness fix rather than an active exploit patch; the commit message notes that notifying users whose transactions were affected is deferred to a later commit.

This commit fixes a crash in Core Lightning's `setconfig` command. Previously, if a user tried to change a plugin option that accepts multiple values and can be changed while running, the node would hit an internal assertion and crash. The fix allows `setconfig` to handle these multi-value options properly by accepting an array of values and replacing all existing values at once.

This commit adds a new JSON-RPC command called 'graceful' that lets a Core Lightning node operator tell their node to prepare for shutdown. When invoked, the node stops accepting new HTLCs (payment forwarding commitments), declines to reestablish idle channels, disconnects peers that have no active HTLCs, and waits for any remaining in-flight HTLCs to resolve before returning. It is an operational/administrative feature, not a vulnerability fix. The commit does not change authentication or authorization rules; it only adds a new state (LD_STATE_GRACE) and the logic to enter and exit it safely.

This commit is a routine API deprecation notice. It marks the old 'pay' and 'paystatus' JSON-RPC commands as deprecated and tells users to switch to the newer 'xpay' and 'listpays' commands. The commands still work if a node operator explicitly allows deprecated APIs. There is no security bug being fixed here.

This commit is a routine code cleanup: it introduces two helper functions, tal_arr_append and tal_arr_appendn, to replace repeated open-coded patterns of resizing a memory array and copying data into it. The change touches many files but does not fix any reported security bug. It adds extra memory-checking under Valgrind and a new unit test. There is no indication this patch is a security fix or that it addresses a known vulnerability.

This commit adds a new experimental JSON-RPC command called `createproof` to Core Lightning. It lets a user generate a cryptographically signed receipt (a 'payer proof') showing they successfully paid a BOLT12 invoice or offer. The change is a feature addition, not a fix for a known vulnerability. It exposes a new RPC that signs proof data using the node's keys, so the main security consideration is making sure only authorized callers can use it and that the proof data is signed correctly. The commit itself does not claim to fix any security issue, and there is no evidence of malicious intent or a disclosed vulnerability.

This commit is a code-quality refactor across many files. It changes the 'failure reason' string returned by BOLT11/BOLT12 decoding functions from a mutable 'char *' to a read-only 'const char *'. It also exposes a previously internal helper function and adds memory ownership fixes so callers don't accidentally use freed error strings. There is no direct evidence in the commit message or diff that this fixes an active security vulnerability, but it removes a class of potential memory-management mistakes and makes the API safer for future callers.

This commit adds support for decoding a new experimental BOLT12 format called a 'payer proof' in the Core Lightning node's decode command and related API bindings. It is a feature addition that extends existing decoding logic to recognize and return fields for payer proofs, such as the payment preimage, signature, and merkle proof hashes. There is no direct evidence in the commit that this fixes an active security vulnerability; it appears to be a protocol-support enhancement.

This commit fixes a bug in Core Lightning's `decode` command for recurring payment offers. A previous code change split one offer field into two variants (compulsory and optional), but the `decode` output was not updated to match the new schema. The fix makes `decode` report a single `offer_recurrence` block with a new boolean flag indicating whether recurrence is compulsory. It is a correctness/API bug, not a direct funds-loss vulnerability, because it affects an experimental feature and would mainly cause decoding errors or misleading output rather than unauthorized payments.

This commit adds a missing data field, invreq_recurrence_cancel, to Core Lightning's decode command and related generated code. The field is part of the experimental BOLT12 recurring invoice request format and lets a payer signal that they want to cancel a recurring invoice. The change is mostly schema, RPC, gRPC, and test updates to expose and validate the new field. It is not a traditional security patch, but missing the field could have caused invoice-request decoding or validation to be incomplete for an experimental feature.

This commit only adds test data files (a seed corpus) for a fuzzing test named fuzz-open_channel. Fuzzing corpora are collections of example inputs used to exercise code during automated testing. No production code, protocol logic, or configuration is changed, and the commit message does not describe any security fix or vulnerability.

This commit only adds test data files (a fuzzing seed corpus) for a new fuzz test called fuzz-amount-arith. It does not change any production code, so it cannot introduce a security vulnerability or fix one. It is purely a testing/development aid.

This commit only adds a new test case that demonstrates a known bug in Core Lightning's wallet handling. When a `withdraw` command fails because the Bitcoin node rejects the transaction broadcast (for example, the fee is too low), some funds can remain marked as 'reserved' even though they were never actually spent. The test documents the bug and includes a manual workaround using `unreserveinputs`. It does not fix the underlying issue, so user funds can appear stuck until manually unreserved.

This commit removes a single blank line containing trailing whitespace from a test file. It is a cosmetic lint cleanup with no functional or security relevance.

This is a routine weekly update to the Rust dependency lock file (Cargo.lock). It bumps several third-party library versions, including the TLS/encryption library rustls, the HTTP client reqwest, and some Java/Windows helper crates. The commit message gives no security reason for the update, and no verified security advisory was supplied. Dependency updates can in principle fix security bugs, but this diff alone does not show any specific vulnerability being patched or any change to Core Lightning's own code.

This commit changes how long Core Lightning nodes remember closed Lightning channels in their network map. The delay is increased from 12 blocks to 72 blocks after the funding output is spent, matching an update to the BOLT protocol specification. This is a protocol-compliance and robustness change, not a fix for an active security vulnerability. The main effect is that nodes keep stale channel information longer, which can slightly delay routing around dead channels but also gives more protection against blockchain reorganizations.