Core Lightning

This commit only adds a new test to the test suite. It checks that old payment records (HTLCs) are not deleted from the database immediately when a channel closes, but are instead cleaned up later when the node restarts. There is no code change that fixes or changes any behavior.

This commit only changes test code. It makes pytest skip certain tests when the software is built without Rust support, so those tests no longer fail in non-Rust builds. There is no change to the actual Lightning node or wallet code, and no security issue is introduced or fixed.

This commit removes one object file (hsm_encryption.o) from a fuzz-testing Makefile. It is a build/test maintenance change with no visible security relevance to the actual Core Lightning software.

This commit adds a missing 'uv' tool installation step to an internal GitHub workflow that synchronizes RPC documentation to a readme server. It is a routine build/CI fix with no apparent security relevance.

This commit fixes a simple off-by-one bug in the bookkeeper plugin. When restarting, the plugin reloads saved 'rebalance' records from its database. The code was reading the wrong part of the database key, so it could not split the two stored numbers apart and would log a 'weird' error and skip the record. The fix changes one number so it reads the correct key segment. A previously-failing test is now enabled. There is no direct security exploit here; the main risk is that accounting records could be missing or inconsistent after a restart.

This commit adds a new test that demonstrates a bug in Core Lightning's bookkeeping plugin: after a node restart, 'rebalance' fee records are lost and the plugin logs a 'BROKEN' warning about an unparsable datastore entry. The test is marked as expected-to-fail (xfail) so it documents the bug without breaking CI. It is a test-only change, not a fix, and there is no security exploit here.

This commit removes an old JSON-RPC field named `blinding` from the `decode` command output. It was already renamed to `first_path_key` in a previous version and has now been fully removed after a deprecation period. This is a routine cleanup, not a security fix.

This commit removes an old, duplicate field name from a plugin hook used when receiving onion-routed messages. The field 'blinding' is being dropped in favor of the newer name 'first_path_key'. It is a planned API cleanup, not a security fix, and does not change how messages are processed or validated.

This commit removes two old command-line flags, --experimental-quiesce and --experimental-offers, from the Core Lightning node software. These features became standard behavior in version 24.11, so the flags were only kept around temporarily to avoid breaking old configurations. There is no security issue here; it is ordinary cleanup of deprecated options.

This commit only reformats a documentation table so the columns line up nicely. No code, no behavior, and no security-related changes are present.

This commit removes an experimental BOLT12 feature called `start_any_period` from Core Lightning's offer recurrence system. It is a protocol/API cleanup change, not a security patch. The functionality is replaced by the existing `absolute_expiry` mechanism for restricting when offers can be used. There is no direct evidence in the commit of a vulnerability being fixed.

This commit updates Core Lightning's implementation of BOLT12 recurring payments to match a newer draft of the specification. It renumbers data fields, splits a setting into compulsory and optional versions, moves a proportional-amount setting into a different field, and adds a new invoice-request cancellation field. The changelog explicitly notes this is an experimental/draft feature change that breaks backward compatibility with old recurring offers. There is no direct evidence in the commit of a security vulnerability.

This change updates how Core Lightning handles recurring payment offers after they expire. Previously, an expired offer could not be used at all. Now, the first invoice request must still happen before expiration, but follow-up recurring payments can continue even after the offer's expiration date. This is an intentional spec change, not a security bug, but it slightly loosens a time-based restriction.

This commit removes a small restriction in Core Lightning's BOLT 12 'offers' feature. Previously, when creating an offer, you were not allowed to set 'quantity_max' to exactly 1. The code now permits that value. The change is described by the author as a convenience for just-in-time stock management, not as a security fix. There is no evidence in the commit or supplied references that this addresses a vulnerability.

This commit adds a spelling check to the project's tooling. It prevents developers from misspelling the word 'recurrence' as 'recurrance' in the codebase. There is no security relevance.

This commit removes the 'years' time unit from BOLT 12 recurring payment offers in Core Lightning, replacing it with 12-month equivalents. It is a protocol alignment change for an experimental feature, not a security fix. There is no indication it addresses an active vulnerability or attack.

This is a small, preparatory code change in Core Lightning's invoice-fetching plugin. It lets the plugin send a message without asking the recipient to send a reply back. The change itself does not fix a bug or close a security hole; it adds a capability that will be used later for canceling recurring invoice requests. There is no direct security impact visible in this commit.

This commit is a simple renaming of a field and its comments from 'max_period' to 'max_period_index' to match a minor BOLT12 specification wording cleanup ('spec neating'). There is no functional code change, no bug fix, and no security relevance.

This commit adds support for cancelling recurring Lightning invoices. Previously, the code rejected invoice requests that lacked a reply path, amount, or quantity. Now, if the request carries the special 'invreq_recurrence_cancel' flag, those requirements are relaxed and the node creates an immediately-expiring invoice instead of returning a usable one. This is a protocol-compliance change that prevents a cancelled recurring invoice from being paid again.

This commit updates Core Lightning's BOLT12 (recurring payment offers) implementation to match the latest specification wording and field names. It is primarily a code-comment and logic-alignment change, not a fix for a known active exploit. One small functional tightening is added: when an invoice request is not recurring, the code now also rejects a previously-allowed `invreq_recurrence_cancel` field. The rest of the changes rename internal checks to match the current spec and adjust when recurrence is detected, which could subtly change validation behavior for recurring offers.

This commit is a simple code cleanup: it moves the logic that parses BIP 353 human-readable names (like ₿name@domain.com) into a reusable helper function. The same validation rules are applied in the same order, and the behavior is unchanged. There is no security fix here.

This commit adds a brand-new experimental RPC command called cancelrecurringinvoice to Core Lightning. It lets a user politely tell a recurring BOLT 12 invoice issuer 'please stop sending me further invoices.' The change is purely additive: it introduces a new command, its documentation, and the code to build and send a cancellation message. Nothing in the commit removes protections, weakens authentication, or changes existing behavior of other commands.

This commit simply moves an existing block of code into a new helper function without changing what the code does. It is a routine code cleanup (refactoring) in preparation for a future feature called cancelrecurringinvoice. There is no security-relevant change visible in this patch.

This commit tightens parameter validation in the 'offers' plugin of Core Lightning. It swaps a less strict validation helper for a stricter one and ensures that when the command is only being checked (not actually executed), the plugin reports completion correctly. The change also fixes an outdated comment describing the stricter helper. There is no direct evidence in the commit of an exploitable security bug, but the change removes a validation gap that could in principle let malformed or incomplete offers slip through.

This change makes Core Lightning's network-map reader (gossmap) stop using memory-mapped file access whenever it hits a read error or bad checksum. On some filesystems like ZFS on Linux, mmap can return stale or partially written data, which makes the daemon think the gossip store is corrupt. The patch falls back to ordinary read calls, which should see the correct data. It is a robustness fix for a reliability problem rather than a clear-cut security vulnerability.