Core Lightning

This is a small bug-fix patch for Core Lightning's internal channel gossip state machine. It adds one previously missing allowed transition between two internal states, preventing the daemon from logging a 'BROKEN' error and potentially misbehaving when a special type of channel (zeroconf, or soon a 'withheld' funding flow) is closed before the funding transaction is mined. There is no indication this allows an attacker to steal funds or take control; it is a robustness fix for an edge case in protocol handling.

This is a small internal refactoring change in the Core Lightning 'offers' plugin. It changes one helper function so it can check for multiple peer features at once (using a bitmap) instead of only one feature at a time. The callers are updated to pass their single feature as a bitmap bit. There is no security fix or behavior change visible to users.

This change tightens which network peers Core Lightning will choose when creating hidden (blinded) payment paths for incoming invoices. Previously it only required support for route blinding; now it also requires support for onion messages. The reason given is that LND nodes were reportedly not forwarding these hidden payments correctly, which could cause payment failures or routing problems. It is a robustness fix rather than a clear-cut security patch, and there is no evidence in the commit of funds being stolen.

This commit updates two JSON schema files used by Core Lightning to document and validate a notification message. It adds 'CLOSED' as a permitted value for the channel state field in the 'channel_state_changed' notification, along with a note that this value was introduced in version 25.12. There is no code behavior change, no runtime logic change, and no security fix or vulnerability present in the diff.

This commit only adds and adjusts Python test code for the Core Lightning project. It extends existing tests to verify that a 'channel_state_changed' notification is correctly emitted when a payment channel transitions into the CLOSED state. There are no changes to production code, no bug fixes, and no security-sensitive behavior being altered.

This is a routine API cleanup, not a security fix. The commit changes how Core Lightning tells plugins about channel state changes: instead of sending `"message": null` when there is no message, it will eventually stop including the `message` field at all. For now it still sends `null` unless the user has opted into strict 'no deprecated features' mode. The code also removes a general helper for adding `null` values to JSON and adds private copies in two places that still need it temporarily.

This commit adds a new plugin notification so that plugins are told when a Lightning channel finishes closing and reaches the CLOSED state. It also makes the optional human-readable 'message' field in that notification truly optional in the generated API bindings. This is a routine feature addition, not a security fix or vulnerability.

This commit only adds a new test case to the project's test suite. It does not change any production code. The test checks that the xpay payment feature limits how many simultaneous payment paths it tries to use when one of the channels is unannounced and has a low limit. Because no actual software behavior is changed, this commit by itself does not create or fix a security vulnerability.

This change adjusts how Core Lightning's xpay plugin splits payments. It limits multi-part payments to 6 pieces when the destination is not publicly known, matching a known limit used by Phoenix wallets. If routing fails with that limit, xpay removes it and retries. Previously, xpay could send too many payment pieces through private channels, causing payments to fail at the recipient. This is a compatibility and reliability fix, not a security vulnerability in the traditional sense, but it prevents a real-world payment failure scenario.

This commit adds a test showing a bug in Core Lightning's routing-reservation system. When two separate routing layers use the same fake channel ID, a reservation made through one layer is incorrectly counted against the other layer too. The test is marked as expected to fail, meaning it documents the bug rather than fixing it. This could cause valid payment routes to be rejected because the system thinks capacity is already reserved when it should not be.

This commit adds an optional 'layer' field to the askrene-reserve and askrene-unreserve commands in Core Lightning. The purpose is to let different plugins (like xpay) reserve capacity on fake or aliased channels without their reservations colliding with each other. It is a feature addition that improves correctness of route planning, not a fix for an active security bug.

This fix corrects a bug in Core Lightning's 'xpay' plugin where temporary, made-up channel identifiers used for private payment routes (routehints and blinded paths) were being treated as real, globally-known channels. When two payments ran at the same time, they could reserve the same fake identifier and interfere with each other, potentially causing one payment to fail or be delayed. The fix marks these channels as fake and keeps their reservations private to each payment.

This commit fixes the `askrene` routing plugin in Core Lightning so it respects user limits on how many payment paths (HTLCs) can be used. Previously, when a user set `maxparts` lower than the number of routes the algorithm found, the plugin could fail to find a route or behave poorly. The new code merges excess routes into the largest remaining ones and checks that fees stay within budget. It is a correctness/reliability improvement, not a remote exploit.

This is a simple code cleanup: a developer renamed a few internal helper functions by removing the '_noidx' suffix because the older versions no longer exist. The actual behavior of the code is unchanged. There is no security issue here.

This is a small internal code cleanup in the askrene routing plugin. It removes an unnecessary intermediate index array in the flow-refinement logic, making the code operate directly on the flows array. There is no indication this fixes a security bug or changes externally observable behavior.

This commit fixes a temporary memory leak in the askrene routing plugin of Core Lightning. When the code discarded unused payment routes (called 'flows'), it removed them from a list but forgot to free the memory they occupied. The commit adds a helper function that both removes and frees these discarded flows. The author notes it is a 'temporary leak' and a 'trap' for future developers, not an active security vulnerability.

This commit rewrites a routing helper inside Core Lightning's experimental 'askrene' plugin so it correctly accounts for overlapping payment routes when increasing payment amounts. The old code sorted routes and increased each independently, which could ignore shared channel capacity limits. The new code reserves capacity across all routes, picks the route with the most spare capacity, and stops if it cannot meet the target. There is no direct evidence this is a security fix, but incorrect capacity accounting in payment routing can lead to failed routes, stuck payments, or unintended fee/HTLC behavior.

This commit fixes how the askrene routing plugin handles the maxparts parameter. Previously, setting maxparts to 1 did not force single-path routing, and setting it to 0 was accepted even though it makes no sense. Now, maxparts=1 forces single-path routing, and maxparts=0 is rejected with an error. This is a minor correctness and input-validation improvement, not a critical security fix.

This is a small internal code cleanup in Core Lightning's payment routing plugin (askrene). It removes a precomputed cache of maximum deliverable amounts and instead calculates those values on demand. There is no indication this fixes a security bug or changes externally observable behavior.

This commit removes a small performance cache from the askrene routing plugin. The author found the cache barely sped up tests, so they simplified the code by recalculating channel values on demand instead of storing them. There is no indication this fixes a security bug; it is a routine code cleanup.

This is a small internal code cleanup in Core Lightning's payment routing plugin (askrene). It removes an unnecessary index array and makes a function work directly on the list of payment flows. There is no indication this fixes a security bug or changes externally observable behavior.

This commit fixes a programming mistake in Core Lightning's 'askrene' plugin where an error-handling path tried to free memory that had already been freed. Re-freeing the same memory can crash the process or corrupt memory. The fix replaces the shared 'goto fail' path with direct returns so the double-free cannot happen.

This is an internal code cleanup in the askrene routing plugin. It replaces a string-based sorting trick with a direct pointer comparison when merging duplicate payment routes. The only observable effect is that routes come out in a slightly different order, so one test's expected numbers were updated. There is no indication this fixes or introduces a security vulnerability.

This is a small internal code cleanup in the askrene routing plugin. It changes one function to sort and modify a list of payment flows directly instead of going through a separate index array. The old index array is still created afterward for other code that still needs it. There is no indication this fixes a security bug or changes user-visible behavior.

This is a routine code cleanup in Core Lightning's payment routing plugin (askrene). It removes an unused output parameter called bottleneck_idx from an internal helper function and its callers. There is no change to behavior, no bug fix, and no security relevance visible in the commit.