Core Lightning

This commit is a straightforward internal bookkeeping change in the xpay plugin. It adds a list that tracks currently active payments and a helper function to check whether a payment is still in progress. There is no security fix or vulnerability here; it is preparation for a future feature (making listpays aware of xpay payments).

This change moves the `listpays` command from the older `pay` plugin to the newer `xpay` plugin. The practical effect is that when you ask your node to list recent payments, it now checks whether `xpay` is still retrying a payment before marking it as failed. Previously, `listpays` could wrongly report an ongoing payment as failed because it only looked at the old `pay` plugin's state. There is no new attack or remote exploit here; it is a bug-fix/refactor that improves reporting accuracy.

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 fixes a build-tool quirk that could pick the wrong function prototype when generating test mock stubs for deeply nested source directories. The wrong prototype would produce a test stub with mismatched function parameters, which could cause test compilation to fail or tests to behave incorrectly. It is a build/test reliability fix, not a directly exploitable security vulnerability in running software.

This commit adds a new optional 'destination' parameter to the 'injectpaymentonion' JSON-RPC command in Core Lightning. It is a feature addition that lets callers explicitly tell the node the final recipient of a payment, so payment-listing commands show the right destination even when no invoice string is provided. There is no indication this fixes a security vulnerability.

This commit adds a new command called xkeysend to Core Lightning, which lets users send money to another node without needing an invoice. The code itself is a feature addition, not a bug fix. It includes a note that keysend payments do not provide cryptographic proof-of-payment, which is a known limitation of the keysend design. There is no direct evidence in the commit of a security vulnerability being fixed or introduced.

This commit only adds Python test coverage and a new client-side helper for an existing RPC command called xkeysend. There is no change to the actual Core Lightning daemon code that handles payments, so it cannot by itself introduce a security vulnerability. It is a testing and client-library addition.

This commit is a straightforward test-only speedup. It refactors a single pytest test so it creates one pair of test nodes and loops through several payload lengths internally, instead of launching fresh nodes for every length. It also adds a stronger assertion checking invoice descriptions and amounts. There is no change to production code, no security fix, and no security-relevant behavior change.

This commit simply marks the 'renepay' and 'renepaystatus' commands as deprecated. It adds warning text to documentation, lists the commands in the deprecated-features guide, and updates tests to explicitly allow deprecated APIs so they keep passing. There is no security fix or vulnerability here.

This commit adds plumbing for optional extra data fields in Lightning payment onions, but explicitly leaves the feature unused. The new extra_tlvs field is always set to NULL, so no behavior changes for users today. It appears to be preparatory work for future 'keysend' style payments.

This commit only changes the project's internal test suite and a Python test helper. It replaces calls to the older `pay` RPC command with the newer `xpay` command in many tests, updates expected error messages, removes one obsolete test, and adds an `xpay` wrapper to the pyln-client library so tests can call it more easily. There is no change to the actual Core Lightning daemon or wallet code that handles real payments, so this does not fix or introduce a security vulnerability.

This commit only changes test code in the Core Lightning project's test suite. It makes three payment-related tests more robust by removing unnecessary wait calls, switching from high-level 'pay' to lower-level 'sendpay' in one stress test, and using 'xpay' with shadow routes disabled in another. There are no changes to production code, no bug fixes, and no security-relevant behavior changes.

This commit updates the Core Lightning `sendpay` RPC command so it can accept route objects produced by the newer `getroutes` command, in addition to the older `getroute` format. It makes several route fields optional and adds aliases (for example, `short_channel_id_dir` as a newer name for `channel`). The change is primarily an API compatibility and feature enhancement. There is no direct evidence in the commit that this fixes a security vulnerability, but loosening input validation and making previously required fields optional can sometimes hide or introduce edge-case bugs, so it warrants a conservative defensive review.

This commit changes Core Lightning so that the newer 'xpay' plugin silently handles most calls to the older 'pay' command by default. It is a feature migration, not a security patch. The old 'pay' command is marked deprecated, and some of its options (like 'exclude') are removed when xpay takes over. The change is mostly about routing and error-message behavior, not about fixing a vulnerability.

This commit imports a new helper function, json_escape_dup, from the CCAN library into Core Lightning. It simply adds a way to duplicate (copy) an already-escaped JSON string object. There is no visible bug fix, behavior change, or security patch in the diff itself.

This is a routine test-only change in Core Lightning. It updates pytest test code to stop using a soon-to-be-deprecated routing layer name ('auto.no_mpp_support') and instead uses a new 'maxparts=1' parameter to achieve the same test behavior. There is no change to production code, no security fix, and no vulnerability.

This change fixes a small compatibility gap in the xpay plugin, which can take over the older `pay` command. Previously, if a user supplied a `label` or `localinvreqid` argument to `pay`, xpay would silently drop those arguments before forwarding the payment. Now it preserves and forwards them. This is mainly a functional bug fix; the dropped arguments could cause user labels or local invoice request tracking to be lost, but there is no direct evidence of a security vulnerability.

This is a tiny bug fix in the Core Lightning 'xpay' plugin. When a user tried to pay an invoice that had already been paid, the plugin was returning the wrong numeric error code (218 instead of the documented 219). The change makes the returned code match the documentation and the test now checks the exact code. It does not create a security vulnerability or allow anyone to steal funds; it only affects the error message details returned to API callers.

This commit is a routine API cleanup, not a security fix. It renames three fields in the getroutes JSON-RPC response to clearer names and marks the old names as deprecated. The old fields are still emitted for backward compatibility unless a user opts into strict deprecation handling. There is no vulnerability being patched here.

This commit is a routine cleanup of an automated test in the Core Lightning project. It renames test nodes from generic names like 'sender' and 'router' to 'l1', 'l2', etc., removes a 'slow_test' marker, and adjusts the test to wait for all network gossip to be seen before checking the result. There is no change to production code, no security fix, and no vulnerability introduced.

This commit adds two optional parameters, `label` and `localinvreqid`, to the `xpay` RPC command in Core Lightning. These parameters already exist in the older `pay` command and are being brought over for feature parity. `label` lets users tag payments for their own records, while `localinvreqid` links a payment to a local invoice request when paying BOLT12 offers. There is no security-relevant change visible in the diff.

This is a small bug-fix in Core Lightning's experimental 'xpay' payment plugin. When a payment used a privacy feature called a 'blinded path' (a dummy route that hides the real final recipient), the plugin could misidentify which node reported a payment failure. The actual payment behavior was unchanged, but the internal reasoning used to decide what to do next was misleading. There is no direct security exploit here; it is a correctness fix that prevents a wrong diagnostic from potentially causing a poor routing decision later.

This commit is a straightforward internal code cleanup in Core Lightning's routing plugin (askrene). It replaces a shared route-hop structure with a locally-defined one, renames fields for clarity, and adjusts how route amounts and delays are computed and printed. There is no indication of a security fix or behavior change that would affect users or funds.

This is a routine internal change to which payment plugin Core Lightning uses when automatically paying invoices created via the experimental 'invoicerequest' flow. It switches from the older 'pay' plugin to the newer 'xpay' plugin and updates the corresponding test expectation. There is no security issue visible in the commit.

This is a routine feature change, not a security fix. The `pay` command now accepts either `bolt11` or `invstring` as the name for its invoice-string parameter, so users don't have to change their scripts when a future version renames the command. No vulnerability is present.