Core Lightning

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 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 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 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 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 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 change makes Core Lightning's gossip map (the data structure tracking network routing announcements) fall back to non-memory-mapped file access when it detects internal inconsistencies. Previously the code just forced the gossip store file to disk with fsync and then crashed if the map still looked wrong. Now it disables memory mapping first and refreshes the view, only crashing if the mismatch persists. This is a robustness improvement that may avoid unnecessary node failures and could prevent or mask a class of crashes/undefined behavior caused by stale mmap views of the gossip store.

This commit simply removes an unused flag bit and its display in a developer debugging tool. There is no security-relevant change: no code behavior is altered, no vulnerability is fixed, and no new risk is introduced.

This commit adds a way for Core Lightning to deliberately stop using memory-mapped file access for its network gossip data and fall back to ordinary read() calls. The change itself is a routine helper function; it does not fix a crash or stop an attacker on its own. It appears to be infrastructure for a follow-up change, likely to work around a consistency problem between mmap and pwritev() on OpenBSD.

This change fixes a bug in how Core Lightning refreshes its network map (gossmap). Previously, if the gossip store file stayed the same size, the code would skip re-reading it entirely, even though the last entry might have been partially written or updated in place. Now it always re-parses the map contents, which can prevent stale or incomplete routing data from being used.

This commit hardens how Core Lightning reads its own 'gossip store' file so that it skips records that have not been fully written yet. Previously, readers could try to process half-written or incomplete records, which could lead to crashes, incorrect routing data, or corrupted state. The fix adds a 'wait for completed bit' check in C and Python gossip-map readers and in a diagnostic dump tool.

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.

This commit only updates test data files used by the Python client library's test suite. The files are compressed binary gossip store snapshots, and the change sets a flag (GOSSIP_STORE_COMPLETED_BIT) so tests match current expectations. There is no change to production code, no user-facing behavior change, and no security issue.

This commit hardens how Core Lightning writes its gossip store file. It adds a 'COMPLETED' flag that is set only after a full record has been safely written, so the program can detect and skip partial/corrupted records on restart. The change is defensive: it makes crashes or unclean shutdowns less likely to leave the gossip store in a broken state, especially on filesystems other than Linux ext4. There is no direct evidence in the commit of an exploitable security vulnerability.

This commit updates a test fixture and its matching test data in the pyln-client test suite. The old gossip store file used an outdated network message format (private channel announcements) that was removed in Core Lightning v13, so the test was failing. The change replaces the binary fixture with a freshly generated one and updates the expected channel ID and timestamps in the test code. There is no security fix here—this is purely a maintenance update to keep tests passing after a protocol cleanup.

This commit adds a new developer-only command-line tool called convert-gossmap. It upgrades old Lightning network gossip store files used in testing to a newer format. There is no change to the live node software, no network-facing code, and no indication this fixes or introduces a security issue.

This commit only updates unit-test data and test helpers so that fake gossip store records carry a 'completed' flag. It does not change any production code, network protocol, or wallet logic. There is no security issue here.

This commit removes an old build-system check that tested whether the operating system supports a function called pwritev(). The project no longer uses pwritev() in its code, so the check is unnecessary. This is a routine cleanup with no security relevance.

This change is a defensive fix for Core Lightning's gossip daemon, which stores network routing information on disk. On some filesystems (the commit specifically mentions ZFS on Linux), writes to this store can appear incomplete or out of order when later read back, causing the daemon to detect corruption. The patch keeps a short-term copy of recent writes in memory, disables memory-mapped reads when a mismatch is detected, and rewrites the last records with an explicit disk sync. It is a reliability/recovery fix, not a typical security vulnerability patch, and there is no evidence it was triggered by an attacker.

This commit removes a rarely-used diagnostic helper called gossmap_fetch_tail that could crash the gossip daemon when it tried to read the tail of a corrupted or truncated gossip map. The crash happened during an internal error path (the daemon was already about to exit), so it is more of a crash-on-failure than an exploitable vulnerability. The fix simply stops calling the helper and reports the remaining file data from the regular file descriptor instead.