Core Lightning

This commit adds a new internal data-format definition (a 'wire format') for a Core Lightning plugin called 'bwatch'. It describes how the plugin will store block history and 'watch' records in its database. There is no executable code in the change—only a build-file update and a CSV file that defines data structures. Nothing in the commit suggests a security vulnerability, fix, or exposure.

This is a small internal code cleanup in how JSON strings are added to output streams. It replaces a less efficient formatting-based path with a direct string-copying helper, and consolidates two similar functions. There is no user-visible behavior change and no security relevance in the diff itself.

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 user-facing configuration option called xpay-user-layer for the xpay payment plugin in Core Lightning. It lets node operators permanently specify routing layers that xpay will apply to every payment, which is useful when xpay is handling the older pay command where layers cannot be passed directly. The change is a straightforward feature addition with no security-relevant behavior.

This commit is a routine code cleanup: it moves two small helper functions for handling plugin options that can be set multiple times from a test-only file into the shared plugin library so other plugins can reuse them. There is no security-relevant change.

This is a routine test-only fix. A single pytest test case was still calling an old, deprecated RPC command named 'getroute'. The patch replaces it with the current helper method 'single_route'. There is no change to production code, no security bug, and no vulnerability.

This change turns off a privacy feature that made all network messages the same size by default. The feature was causing connection problems with some other Lightning nodes that didn't handle the extra padding bytes correctly, and the existing detection of those broken nodes wasn't reliable enough. It is a compatibility and reliability fix, not a security patch for an exploitable vulnerability.

This commit adds an optional timeout to the 'graceful' RPC command in Core Lightning, which operators use when preparing a node to shut down. Previously, graceful would wait indefinitely until all payment commitments (HTLCs) finished and idle peers disconnected. Now, if a timeout is provided, the command returns after that many seconds and reports any still-pending HTLC expiry heights and connected peers. This is a usability improvement for scripting shutdowns, not a security fix. The code changes are straightforward and do not appear to introduce a vulnerability.

This commit updates the systemd service file that manages the Core Lightning daemon so that it shuts down the service gracefully instead of abruptly killing it. The change adds a two-step stop command: first a graceful shutdown with a 20-second window, then a hard stop if needed, plus a 60-second timeout. This is an operational reliability fix, not a security vulnerability fix. It reduces the risk of data corruption or inconsistent state from a forced shutdown, but it does not introduce or patch an exploit.

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 only changes user-facing error messages in the Core Lightning routing plugin (askrene). It makes failure explanations clearer when payment channels are disabled, and removes double spaces from messages. There is no code behavior change, no security fix, and no vulnerability.

This is a code-quality fix inside Core Lightning's xpay plugin. It moves the assignment of a payment's unique ID earlier in the payment's lifetime so that logging functions can safely use it. The bug caused valgrind warnings (use of uninitialized data) and could have led to confusing log output, but it is not an exploitable security vulnerability.

This change adjusts how the Core Lightning routing plugin (askrene) decides to ignore very small payment channels. Previously it only removed small channels when the payer did not support multi-part payments. Now it also does so when the caller explicitly requests a single payment part (maxparts=1). The effect is to make single-part route searches faster and more reliable, but it could also change which routes are chosen or whether any route is found at all.

This change improves the error messages returned by Core Lightning's routing plugin (askrene). Previously, almost all routing failures were reported with a single generic 'route not found' error code. Now the plugin distinguishes cases such as 'route too expensive' or 'timed out' and returns the appropriate error code. This is a quality-of-life improvement for callers, not a fix for an exploitable vulnerability.

This commit is a routine deprecation of an old way to request single-path routing in the Core Lightning `getroutes` RPC. The `auto.no_mpp_support` layer still works for now, but it is marked deprecated and internally is converted to the newer `maxparts=1` option. There is no security vulnerability here.

This is a small internal cleanup in Core Lightning's xpay plugin. It removes a redundant 'disable_mpp' flag and instead uses the existing 'maxparts' setting (set to 1) to achieve the same effect of disabling multi-part payments. The behavior appears functionally equivalent.

This is a routine code cleanup in Core Lightning's xpay plugin. The developer extracted the logic that creates a new payment object into a reusable helper function so it can later be used for a new 'xkeysend' feature. No security bug is being fixed here; the behavior of existing payment handling is intended to remain the same.

This change improves the 'xpay' payment plugin in Core Lightning so that when a payment attempt fails and the error message contains a channel update, xpay uses that update only for the current payment's retry instead of applying it globally. The commit message explicitly says the old global behavior risked leaking information, and the new scoped behavior reduces that privacy risk while still helping payments succeed.

This change makes the newer 'xpay' payment plugin behave like the older 'pay' plugin when an invoice has already been paid. Previously, if xpay tried to pay an invoice that was already settled, it would give up with an error. Now it looks up the previous successful payment details and returns them as if the current request succeeded. This is a compatibility fix to avoid surprising users and callers who expected the old pay plugin's idempotent behavior.

This commit adds a new Python helper for a Lightning RPC command and updates test utilities to use it. There is no security issue visible in the change itself.

This commit only changes test code. It replaces direct calls to the older getroute() RPC helper with a new single_route() wrapper that internally uses the newer getroutes() API. There is no change to production code, no bug fix, and no security relevance.

This commit only updates test code. It replaces old calls to the `getroute` RPC with newer helper methods like `single_route` and `getroutes`, and updates the field names used in test assertions (for example, `amount_msat` becomes `amount_out_msat`). There is no change to the actual Core Lightning node software, so it cannot affect real users or introduce a security vulnerability.

This is a small change to a Python testing helper used only in Core Lightning's test suite. It lets a fake Bitcoin RPC call return None as a signal to fall through to the real RPC call. There is no production code affected and no security issue visible in the patch.

This commit simply marks an older command, getroute, as deprecated and tells users to switch to a newer command, getroutes. It does not fix a bug or change security behavior. The old command still works for now, but tests that use it must explicitly allow deprecated APIs. There is no security issue here.

This commit simply marks the old `keysend` RPC command as deprecated and tells users to switch to a newer command called `xkeysend`. It updates documentation, schemas, and test settings so that tests continue to work while the old command is still available. There is no security bug being fixed here.