Core Lightning

This commit only adds and rewords comments in the source code to make it easier to find places where the project would like to require a newer SQLite version in the future. It does not change any actual behavior, fix any bug, or alter any security-related logic.

This commit is a routine fix for the macOS CI build workflow. It adds Python 3.10 setup, installs OpenSSL via Homebrew, and sets environment variables so that the grpcio-tools Python package can be built successfully on macOS runners. There is no indication this change affects shipped software security or introduces a vulnerability.

This commit is a routine build-system refactor for Core Lightning's Python packages. It switches the package manager from Poetry to uv and the build backend to hatchling, updating pyproject.toml files and lock files accordingly. There is no change to the actual Lightning node code, no bug fix, and no security patch.

This commit is a routine build-tooling change: it swaps the Python package manager from Poetry to uv in Makefiles, updates how package versions are read, and wraps Python commands with `uv run`. There is no change to Core Lightning's runtime code, network protocol handling, wallet logic, or cryptography, so it does not introduce or fix a security vulnerability.

This commit only updates documentation files to replace instructions mentioning the Poetry Python tool with instructions for a newer tool called 'uv'. No program code, configuration files, or security logic was changed. It is a routine developer-experience/documentation maintenance change with no security relevance.

This is a routine maintenance change in a test helper file. It swaps one HTML-escaping function for an equivalent one to stay compatible with future Flask releases. There is no security issue here.

This is a routine build-system maintenance change. It adds the libffi library to the list of packages installed in a FreeBSD CI workflow so that the Python coincurve package can compile successfully. There is no security-relevant change to the software itself.

This is a routine build-script change. It adds one command to install the Poetry Python packaging tool via the uv package manager, so that the project's 'reckless' component can continue to work during a migration from Poetry to uv. There is no security-relevant change visible in the diff.

This commit is a routine maintenance change to the project's release pipeline. It swaps the Python packaging tool from Poetry to uv (a newer, faster Python package manager) and updates the matching documentation. There is no change to Core Lightning's actual node software, wallet logic, or network protocol, and no security bug is fixed or introduced in the diff.

This commit is a routine build-tooling change: it swaps the Python dependency manager used by the project's automated CI workflows from Poetry to uv. It does not modify Core Lightning's actual node code, wallet logic, network protocol handling, or any user-facing behavior. There is no security-relevant change visible in the diff.

This commit fixes a build problem by pinning a Python cryptography helper library (coincurve) to an older version. It is a build/dependency workaround, not a fix for a security vulnerability in Core Lightning itself. The change prevents installation failures caused by a packaging bug in coincurve 21.0.0, but it does not patch any runtime security flaw.

This commit is a routine code cleanup: it removes unnecessary 'global' declarations and adds a Python type annotation. There is no change to how the software behaves or to any security-sensitive logic.

This commit adds a basic pytest configuration file and an empty package marker file to the tests directory. It is purely a development/testing setup change with no security relevance.

This commit adds small marker files (__init__.py) to several Python packages so they can share the same 'pyln' namespace in a virtual environment. It is a packaging/development fix, not a security patch. There is no indication it fixes a vulnerability or changes how the software protects funds or data.

This commit adds extra safety checks to Core Lightning's 'askrene' routing plugin. After computing payment routes, it now verifies that every hop's amount respects each channel's advertised minimum and maximum HTLC limits. If a route violates those limits, it is rejected with a broken/log message. This is a defensive hardening change rather than a fix for a known active exploit.

This change fixes a routing bug in Core Lightning's experimental 'askrene' plugin. Previously, when the plugin planned a payment route, it could repeatedly try to use channels whose minimum payment size (htlc_min) was bigger than the amount being sent, wasting computation and potentially producing bad routes. The patch makes the plugin remember and temporarily disable those channels during the same routing query, so it doesn't hit the same constraint twice.

This commit removes a large block of unused code from the askrene routing plugin in Core Lightning. The deleted functions handled fee calculations, capacity limits, and HTLC constraints during payment route refinement, but they were no longer being called anywhere. There is no indication in the commit message or diff that this fixes a security bug; it appears to be routine code cleanup.

This commit rewrites the payment routing solver in Core Lightning's experimental 'askrene' plugin. It changes how routes are computed, how fees and delays are checked, and how channel capacity reservations are handled. The stated goal is to make more payments succeed in simulation. There is no claim this fixes a security vulnerability, and the changes are in an experimental plugin rather than core payment logic. The main risk is that a bug in the new solver could produce invalid or uneconomic routes, but the commit itself does not introduce an obvious exploitable weakness.

This commit adds a small optimization to Core Lightning's payment routing plugin (askrene). After computing payment routes, if the deliverable amount is slightly short of the requested amount, the code now nudges each route's amount upward by up to 2% (without exceeding each route's maximum). The goal is to avoid an extra expensive computation and to handle edge cases where a channel's minimum HTLC size is larger than the leftover shortfall. There is no indication in the commit that this fixes a security vulnerability.

This commit adds new internal helper functions to the askrene routing plugin in Core Lightning. The code is designed to refine payment routes after they are computed, trimming them so they respect per-hop HTLC maximums, liquidity limits, and exact fees. There is no indication in the commit that this fixes a security vulnerability; it reads as a normal feature or accuracy improvement to the routing algorithm.

This change improves the Lightning payment routing plugin 'askrene' by removing proposed payment routes that would violate each channel's minimum HTLC (payment) amount. Previously, the refinement step only checked maximum deliverable amounts and zero-amount flows, but could leave in routes where the delivered amount is below a channel's htlc_min. This patch adds a minimum-deliverable calculation and filters out such invalid flows. It is a correctness/hardening fix rather than a clear exploit, but invalid routes could cause payment failures or unexpected node behavior.

This commit is a routine internal code reorganization in Core Lightning's routing plugin (askrene). It exposes some helper functions and adds new utilities for merging duplicate payment routes and checking route constraints. There is no indication of a security fix or vulnerability being patched.

This commit only rewords a documentation sentence to make clearer the order in which three certificate pieces should be combined. No code, configuration, or security behavior changed.

This commit corrects a C header file constant called CHANNEL_STATE_MAX so that it points to the last entry in the channel-state list. Previously it pointed to an older, no-longer-last state. This kind of off-by-one bookkeeping bug can cause array overruns or missing state handling in code that uses the constant to size loops or tables, but the diff itself only changes one macro and does not show any actual crash or exploit path.

This commit adds a new automated test to the Core Lightning project. The test checks that a project-wide constant called CHANNEL_STATE_MAX correctly reflects the highest numbered channel state. If a developer adds a new channel state but forgets to update the constant, the test will fail in continuous integration. It is a defensive code-quality change, not a fix for an active security issue.