Core Lightning

This commit is a simple documentation revert. It undoes a previous change that told macOS users to install GNU make and GNU patch from Homebrew and to put those tools first in their command path. The reverted instructions now omit gpatch and point PATH to a non-existent-looking '/opt/homebrew/opt/' directory, which is likely a mistake or incomplete edit. There is no code change and no direct security issue in the diff itself.

This commit re-adds an old-style 'x' prefix to a string comparison in a test helper script. It is a test-only change with no effect on the actual Core Lightning node software, user funds, network behavior, or security. The change simply restores a defensive shell-coding idiom to avoid a rare edge case in ancient shells.

This commit only updates macOS installation instructions in the documentation. It tells macOS users to install newer GNU versions of 'make' and 'patch' from Homebrew because Apple's built-in tools are too old for building and running source checks. No code, no security fix, no vulnerability.

This commit is a trivial shell script cleanup. It removes an old-fashioned 'x' prefix from a string comparison in a test helper script so that a newer version of the Shellcheck linter stops warning about it. The change does not alter program behavior and has no security relevance.

This commit moves existing code that parses payment amounts (Bitcoin millisatoshis, 'any' amount, or fiat currency amounts) from one plugin file into a shared library so it can be reused by a future feature. It is a code refactoring with no obvious security bug introduced or fixed. The parsing logic is essentially unchanged, just relocated and slightly tightened.

This is a routine internal cleanup commit in Core Lightning. It removes an unused helper function and simplifies how JSON-RPC request IDs are stored and formatted, since the project now always uses string IDs for non-command JSON traffic. The changes are refactor-style and do not appear to fix a security bug.

This commit is a routine code cleanup: it moves a small string-hashing helper function into a shared header file so it can be reused without being copied and pasted. There is no change to behavior, no bug fix, and no security relevance.

This is a database downgrade helper fix, not a live network vulnerability. Core Lightning's downgrade tool previously failed to strip out new 'channel impression' records when rolling a database back to version v26.06. The patch teaches the tool to remove those records during downgrade. If left unfixed, a downgrade could leave newer data in an older database format, which might cause errors or prevent the node from starting after rollback. There is no attacker-controlled path in normal operation.

This commit fixes a typo in a database downgrade helper tool. The bug caused the tool to pass a negative number (turned into a huge positive size) when copying data, which led to an out-of-memory (OOM) error. The fix swaps two variable names so the tool copies the already-processed chunk of data instead of the remaining chunk. It is a reliability bug in an offline maintenance tool, not a network-exploitable vulnerability.

This commit fixes a bookkeeping bug in Core Lightning's xpay plugin. Previously, when a payment succeeded, xpay did not tell the askrene routing-helper that the route worked. As a result, askrene kept stale or overly pessimistic ideas about which channels could carry payments, which could make future payments fail unnecessarily or take worse routes. The patch adds the missing 'payment succeeded' notification for every non-local hop. It is a reliability/performance fix, not a direct theft-of-funds vulnerability.

This commit fixes a bug in Core Lightning's routing helper (askrene) where two kinds of channel information—hard limits called 'constraints' and usage estimates called 'impressions'—were being applied in the wrong order. Because impressions are time-relative, applying them out of order could make the router think a channel has more or less available capacity than it really does. The patch merges the two data structures and keeps them sorted by timestamp so they are applied in the correct sequence. The included test demonstrates that the wrong ordering could cause a payment route to be accepted when it should be rejected, or vice versa.

This commit fixes a memory leak in the askrene plugin of Core Lightning. When individual channel intelligence entries were deleted, the code removed the entry from its array but forgot to free two internal pointers (impression and constraint). Over time, this could cause the node process to consume more memory than necessary. The fix explicitly hands those pointers to a temporary context so they are cleaned up when the operation finishes.

This commit only updates test files so that automated checks expect slightly different error wording from the xpay payment command. It does not change any production code, so it cannot introduce a security vulnerability or fix one on its own.

This change tightens the lifetime of recurring invoices priced in foreign currencies (like USD) to 10 minutes by default, and refreshes them with current exchange rates when they expire. Previously, such invoices could remain valid for the full recurrence period, meaning a merchant or payer could be locked into an outdated exchange rate for a long time. The patch also improves error messages so users can tell the difference between a cancelled invoice and one that simply expired.

This commit tightens the expiration time on invoices created from BOLT12 offers. Previously, all such invoices defaulted to a 2-hour payment window. Now, if the offer has an absolute expiry, the invoice expires when the offer expires; and if the offer uses a foreign currency, the invoice expires in 10 minutes (or a developer-tunable value). This reduces the window in which an attacker can exploit stale exchange rates or expired offers.

This commit removes local timing checks in Core Lightning's fetchinvoice plugin for recurring payments. Instead of the plugin refusing too-early or too-late invoice requests, it now lets the remote node decide and report back. The change is described by the author as a simplification, moving responsibility to a separate plugin and the user. It is not presented as a security fix, and the tests are updated to expect remote error messages rather than local ones.

This commit removes a local sanity check in Core Lightning's experimental 'createinvoicerequest' command. Previously, when creating a recurring invoice request, the code looked up past payments by label to verify the previous recurrence was paid and to copy timing data. Now it skips that lookup and lets the remote node decide. The change also renames the 'recurrence_label' parameter to the simpler 'label'. It is described by the author as a cleanup of an undocumented interface, not as a security fix.

This commit fixes how the fetchinvoice plugin handles user-supplied labels that contain special characters such as backslashes, quotes, tabs, and newlines. Previously these labels were passed as raw strings, which could cause JSON encoding problems when the plugin forwarded the label to other parts of the lightning node. The change now parses the label through a JSON-aware escaping helper and writes it back out as a safely escaped JSON string. The included test demonstrates that weird labels now work correctly for recurring invoices and cancellations.

This commit only adds a new automated test file that checks how a helper function (str_to_u64) converts text strings to unsigned 64-bit integers. It does not change any production code, so it cannot by itself introduce a security vulnerability or fix one. The tests verify that the function correctly handles normal numbers, overflow, invalid characters, and leading zeros.

This commit only adds a new pytest test file. It does not change any production code. The test describes desired future behavior for the askrene routing module's error messages when a payment source or destination lacks enough channel capacity. Because no actual code behavior is modified, this commit cannot introduce or fix a security vulnerability on its own.

This commit adds a regression test for Core Lightning's database downgrade path. It ensures that when a user downgrades from an upcoming v26.09 release to an older version (v26.06), the new 'impressions' data added by the askrene routing subsystem is cleanly removed while other askrene data survives. The code change itself is purely a test and a marker comment in the migration list; it does not fix an active security vulnerability.

This commit is a small internal code cleanup in Core Lightning's payment routing plugin. It replaces a loop that removes old routing hints one-by-one with a single bulk removal. There is no indication this fixes a security bug or changes externally visible behavior.

This commit improves an internal diagnostic message inside Core Lightning's payment routing plugin (askrene). It adds a new explanation category called 'known_usable' so that when a payment fails, the software can more precisely report that the failure was due to insufficient usable liquidity that is both known to the node and currently enabled. There is no indication this fixes a security vulnerability; it is a correctness/usability improvement to failure reporting.