Core Lightning

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 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 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 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 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.

This commit fixes a rare programming bug in Core Lightning's 'askrene' routing plugin. If a specific internal function failed due to an overflow, the code would free a memory context and then try to use it again on the error-handling path, which is a use-after-free. The patch changes the function to use a longer-lived memory context so the error path is safe. The failure condition is described as only possible on overflow, making real-world exploitation unlikely.

This commit is a straightforward code cleanup: it introduces two new helper functions, amount_msat_deduct and amount_msat_deduct_sat, which are shorthand for 'subtract this amount from itself' (like a -= b). It then replaces many existing calls of the longer form amount_msat_sub(&x, x, y) with the shorter amount_msat_deduct(&x, y). There is no change in behavior, no bug fix, and no security relevance in the diff itself.

This commit fixes a use-after-free bug: when the bitcoin plugin (bcli) was freed during shutdown, the gossip subsystem could still try to send it a request, reading from freed memory. The patch simply stops new plugin requests once the daemon is shutting down. It is a stability/crash bug rather than an obvious remote exploit, and the commit does not describe it as a security vulnerability.

This commit only adds new test input files to a fuzz-testing seed corpus. It does not change any production code, configuration, or runtime behavior. The added files are used only during automated fuzz testing to exercise more code paths. There is no direct security impact on users running Core Lightning.

This commit only adds a new fuzz test for an existing function and makes a small constant-definition cleanup. It does not change any production code, fix a bug, or alter behavior of the Core Lightning node. There is no security issue here.

This commit fixes a small memory leak inside a fuzz test, which is an automated testing helper program, not part of the live Lightning node software. It does not affect real users, wallets, or network operations.

This commit changes the release build script so that Fedora tarballs use a fixed timestamp when files are packed. This makes the resulting archive byte-for-byte identical every time it is built, which is a reproducible-build improvement. There is no security vulnerability here.

This commit only updates Git ignore lists to exclude automatically generated build artifacts from version control. It does not change any executable code, configuration defaults, or security behavior.

This commit only changes the fuzz testing helper code used by developers. It lets developers pass a -v flag and pick specific test corpus files when running fuzz targets as ordinary unit tests. There is no change to production wallet, networking, or consensus code, and nothing here affects real users or live funds.

This commit only adds test data files (a fuzzing seed corpus) for a new fuzz test called fuzz-wireaddr. It does not change any production code, so it cannot introduce a runtime security vulnerability on its own. The corpus contains many malformed and unusual network address strings used to exercise the parser during automated testing.

This commit adds a new automated fuzz test file for network address parsing and serialization functions. It does not change any production code, fix a bug, or alter behavior. It is purely a test addition intended to improve code coverage and catch future bugs.

This commit fixes a formatting bug in Core Lightning where DNS-type network addresses were printed as plain text strings without using their known length. The old code passed a pointer to DNS address bytes directly to a string formatter, which could read past the intended data if the bytes were not null-terminated, potentially leaking nearby memory or crashing the program. The fix prints only the exact number of bytes that make up the DNS address.