Core Lightning

This commit is a routine version bump and changelog update for Core Lightning release 25.09.3. It only changes version strings in packaging files and adds release notes; it does not modify any executable code, cryptographic logic, network handling, or fix any vulnerability directly. The changelog mentions prior fixes in release 25.09.2, but those changes are not part of this diff.

This commit adds a new plugin hook capability that lets a plugin override the expected invoice amount when a Lightning payment arrives. It is a deliberate feature, not a bug fix, and the commit message and documentation describe it as useful for accepting smaller payments than originally invoiced. There is no direct evidence this change introduces a vulnerability, but any hook that can override financial validation could be misused if a malicious or buggy plugin is installed.

This commit adds a new optional override to the internal invoice payment-checking function. It lets the node accept a payment whose amount differs from what the invoice originally stated. The change is purely internal infrastructure: all existing callers pass NULL, so the override is not yet used. There is no direct security bug visible in the diff, but it changes the assumptions around invoice amounts, which could matter for future callers.

This commit fixes a packaging bug in Core Lightning's official Docker image. A recent Docker refactoring accidentally left out the SQLite database library (libsqlite3-0) from the final runtime image. Without it, the container likely fails to start or cannot use the default SQLite wallet backend. The patch simply adds the missing library back to the list of packages installed in the final Docker stage. There is no evidence in the commit of a security vulnerability, exploit, or malicious change.

This commit updates the project's Docker build file to install two missing software libraries (lowdown and libsodium) and set related environment variables so the container can compile and run correctly. It is a build-fix change, not a patch for an active security vulnerability. There is no evidence in the commit or supplied references that this fixes a known exploit or was disclosed as a security issue.

This commit changes how Docker builds install packages for cross-compilation. It splits one package-installation step into two: first installing a Python development package that works on any CPU architecture, then installing libraries specific to the target CPU architecture. This is a build-system cleanup and does not appear to be a security fix.

This commit changes how the build system finds two software libraries (OpenSSL and SQLite) on Apple Silicon Macs. Previously, the Makefile used fixed paths like /opt/homebrew/opt/openssl@3. Now it asks Homebrew where those libraries actually live. This is a build-portability fix, not a security patch for a vulnerability. It does not change any runtime code that handles money, network messages, or cryptography.

This commit is a routine version bump for an internal Rust crate called cln-grpc-plugin, changing its declared version from 0.4.0 to 0.5.0. It also fixes a minor whitespace issue in a dependency line. There is no functional code change and no indication of a security fix or vulnerability.

This commit only changes test code. It updates how tests request Bitcoin addresses so they explicitly ask for the address type they want (bech32 or taproot/p2tr) instead of relying on a default. There is no change to production wallet or node code, and no security vulnerability is present in the diff.

This change makes the Bitcoin Taproot address format (p2tr) the new default when users call the `newaddr` command, instead of the older bech32 format. The old bech32 default is kept as a deprecated option for one release cycle so existing integrations don't break immediately. This is a routine modernization, not a security fix.

This commit is a performance improvement, not a security fix. It changes the bookkeeper plugin so that when it processes a very large number of channel movements at once, it only writes detailed debug logs for the first and last one instead of every single one. This reduces log flooding and speeds up the first bookkeeper command after an upgrade. There is no indication this change addresses a vulnerability or security flaw.

This change is a performance optimization for the Core Lightning SQL plugin. It delays creating database indexes until after a table's data has been loaded for the first time, rather than creating indexes before loading. This makes initial data imports much faster (for example, one large table now loads in 17 seconds instead of 82 seconds). There is no security issue here.

This commit fixes a bookkeeping bug in Core Lightning's payment handling. When a developer/admin command called `injectpaymentonion` failed to actually send the payment (for example, because the peer's channel daemon wasn't reachable), the software had already marked the payment as 'pending' in its records. The fix moves the registration step to after the actual HTLC (payment packet) is successfully created, so failed attempts no longer show up as stuck pending payments in `listsendpays` or `listpays`.

This commit only adds a new automated test to the project's test suite. It does not change any production code, so by itself it cannot introduce or fix a live security issue. The test checks that a specific payment function reports a failure correctly when a peer connection drops at a particular moment.

This commit fixes a bug in Core Lightning's bitcoin-cli plugin (bcli) where very large transactions could make the plugin crash with an 'Argument list too long' error. The fix passes large arguments through standard input instead of the command line, which avoids operating system limits on command-line length. It is a reliability fix rather than a security vulnerability that can be exploited by an attacker.

This change removes a repeated internal sanity check that was making very large Bitcoin transaction templates (PSBTs with hundreds of inputs) extremely slow to process. It is a performance fix, not a security fix. The remaining single check at the end still catches the same class of problems, just less frequently.

This commit adds a test that checks whether Core Lightning's bitcoin backend plugin (bcli) crashes when handling very large transactions. The test is marked as expected to fail for now, meaning the underlying crash bug is known but not yet fixed. It does not itself change production code.

This commit fixes a crash in Core Lightning's bookkeeper plugin. Under parallel queries, a bookkeeping record could arrive out of order, triggering an internal 'assertion' that immediately killed the plugin. The fix replaces the fatal assertion with a safe early return when an out-of-order race occurs, and removes the 'expected failure' marker from the related test so it now passes.

This commit only adds a new test case for the bookkeeper plugin. The test runs two list-income queries at the same time and is currently marked as expected to fail (xfail), meaning the underlying crash or assertion failure it checks for has not been fixed yet. The commit itself does not change any production code, so it cannot directly fix a vulnerability.

This commit adds a 10-second safety cutoff to the routing plugin (askrene) that calculates payment paths in the Core Lightning node. Previously, the routing algorithm could keep looping or running for a long time while trying to find a way to send a payment. The change makes it stop and report failure if it exceeds the configured time limit, with a default of 10 seconds. It also exposes a new node option, askrene-timeout, so operators can adjust or disable it. This is a defensive hardening change rather than a fix for a specific remote exploit.

This commit fixes a bug in Core Lightning's `askrene` routing plugin where the program could get stuck in an infinite loop while trying to find payment routes. The loop happened when the route-finder kept finding a path, the path was then reduced because one channel couldn't handle the amount, and the reduced path was discarded because it was the only one found and the user had limited how many route pieces (maxparts) could be used. The fix marks the problematic channel as disabled so the algorithm makes forward progress instead of repeating the same dead-end path forever. It is a denial-of-service/availability issue rather than a loss-of-funds or code-execution vulnerability.

This commit adds a new test case that demonstrates an apparent bug in Core Lightning's routing plugin (cln-askrene). When asked to find payment routes with a limit of two parts (maxparts=2), the plugin can enter an infinite loop instead of cleanly failing. The test is marked as expected to fail for now, meaning the underlying bug is not fixed by this commit—it is only being documented/reproduced.

This commit only adds a new test case to the project's test suite. It does not change any production code. The test is currently marked as expected to fail (xfail), meaning it documents a known bug where the bookkeeper plugin does not preserve certain block-height records after a node restart. By itself, this commit does not fix or introduce any security issue.

This commit fixes a bookkeeping bug in Core Lightning's bookkeeper plugin. On restart, the plugin was reading the wrong part of a stored data key when trying to restore transaction block heights, causing it to log a 'BROKEN' error and set block heights to 0. The fix is a one-line change correcting an array index offset. It is a data-integrity/functional bug, not an exploitable security vulnerability.

This commit removes two leftover git submodule references (libsodium and lowdown) from the repository index. The submodules had already been removed from the project's configuration file, but their entries were still stuck in git's internal records, causing 'recursive clone' operations to fail with an error. The change only fixes a source-code checkout/build problem and does not alter any running code, cryptography, or network behavior.