Core Lightning

This commit adds a new optional flag called `force_paths` to the `createonion` and offer-related APIs in Core Lightning. The flag is stored in the database and returned when listing offers, but the commit does not implement any enforcement logic. It is purely a data-model and API plumbing change with no security-relevant behavior visible in the diff.

This commit adds two missing fields, htlc_minimum_msat and htlc_maximum_msat, to the output of the 'decode' command when it shows blinded payment paths. Previously these values were decoded internally but not printed in JSON or CLI output. It is a display/information fix, not a code-execution vulnerability.

This change improves how Core Lightning selects peers when building private 'blinded' payment paths for invoices. Before, the code could pick a peer whose channel couldn't actually receive the invoice amount, leading to failed or unreliable payments. Now it checks the required amount against each peer's receiving capacity and skips unsuitable peers. It is a robustness fix, not a direct exploit patch, and the commit message does not frame it as a security issue.

This commit adds a flag called `force_paths` to an offer when the user has chosen to use 'fronting nodes' (intermediate nodes that hide the recipient's identity). This tells the system later, when an invoice request arrives, that it must stick to the privacy-preserving blinded paths rather than potentially leaking the real node. The change itself is one line and appears to be a correctness/privacy fix rather than an active vulnerability patch, but it prevents a privacy-relevant misbehavior.

This commit adds a test case that demonstrates a bug in Core Lightning where a blinded payment path can be created with a zero htlc_maximum_msat value. This means the software sometimes generates payment invoices with a maximum payment size of zero, which could prevent payments from working. The test is marked as expected to fail because it only triggers under certain conditions related to gossip store ordering.

This commit only adds a new test case to reproduce a bug where Core Lightning's experimental xpay plugin might incorrectly charge fees when paying a directly connected peer over a BOLT 12 invoice. It is a test-only change and does not modify any production code, so it cannot by itself introduce a security vulnerability. The underlying regression is a fee-calculation/economic issue, not a code-execution or funds-theft flaw.

This change fixes a bug in how Core Lightning creates invoices from offers. Previously, the software always reused the hidden routing paths (blinded paths) from the original offer when making the invoice. That could force payments through nodes that lacked enough capacity, or through paths chosen before the final amount was known. Now it only forces reuse of those paths when the user explicitly configured them as 'fronting nodes.' Otherwise it picks a better path when the invoice is created. Two previously failing tests are re-enabled, suggesting the bug caused real payment failures.

This is a small internal code cleanup in the SQL plugin. It removes an unnecessary pointer stored inside a query-tracking structure and instead reads a counter directly from the table description. There is no visible change in behavior, no user-facing bug fix, and no security-relevant change.

This commit only adds a new automated test to the project's test suite. It checks that the experimental SQL query feature correctly notices when invoices are added, deleted, or expire. There is no change to production code, no bug fix, and no security-relevant behavior in the diff itself.

This commit simply removes two outdated TODO comments from the SQL plugin source code. No code behavior changed, no bugs were fixed, and no security issue is present.

This commit is a simple variable rename in the SQL plugin code. It changes the name `update_stmt` to `insert_stmt` throughout the code because the statement is actually an INSERT, not an UPDATE. No behavior changes, no security implications.

This commit is a straightforward internal bookkeeping change in the SQL plugin of Core Lightning. It adds tracking of the highest 'updated_index' value seen, mirroring existing tracking for 'created_index'. There is no security issue visible in the diff.

This commit changes how an internal SQL plugin keeps track of Lightning node data updates. It switches from a simple 'needs refresh' flag to a more detailed system that separately tracks created, updated, and deleted entries. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a structural improvement to refresh logic.

This commit is a simple internal code cleanup: a variable named `indices_created` is renamed to `populated` because it will be used more broadly as a 'has this table been initialized' flag. No behavior changes, no security fixes, and no bug fixes are visible in the diff.

This commit improves the SQL plugin in Core Lightning so that certain tables (htlcs, forwards, invoices, sendpays, networkevents) are refreshed more efficiently when data changes. Instead of reloading the whole table, it now deletes and re-inserts only changed entries. The change is described as a performance improvement, not a security fix, and there is no evidence in the commit of a vulnerability being patched.

This is a small internal cleanup in Core Lightning's SQL plugin. It adds a prepared 'DELETE' statement for tables that have a created_index column, and makes the existing insert statement constant. The change is meant to enable future efficient single-row deletion instead of deleting and reloading whole tables. There is no direct security bug visible in the diff, and no exploit path is shown.

This change makes a message-padding privacy feature optional rather than always-on, because the always-on version was accidentally breaking connections to LND (another popular Lightning implementation). It is a compatibility/bug-fix commit, not a direct security patch, though it touches a feature that was intended to improve privacy against traffic analysis.

This commit adds a single boolean flag called dev_uniform_padding to an internal message definition file. The flag lets two parts of the Core Lightning software agree whether an experimental traffic-padding feature is turned on. It is a wiring-only change: no actual padding logic is added or changed here, and there is no indication it fixes a security bug.

This is a one-line change to a test file. It adds a developer-only flag to an existing test so the test can verify that network packets are padded to a constant size. There is no change to production code, no user-facing behavior change, and no security fix or vulnerability indicated.

This commit adds a new developer-only command-line flag called --dev-uniform-padding. When enabled, it tells the daemon to pad outgoing peer messages to fixed 1460-byte chunks as a defense against traffic analysis. The change only wires a new boolean option through the daemon; it does not implement the actual padding logic, nor does it fix any existing bug. It is a feature addition, not a security patch.

This commit fixes a typo in a test file and removes a marker that was causing the test to be expected to fail. The change only affects internal testing code, not the actual Core Lightning software that users run. There is no security issue here.

This commit is a routine version bump for the cln-grpc-plugin from 0.5.0 to 0.6.0, plus a minor whitespace fix in a dependency line. It only changes two metadata files (Cargo.lock and Cargo.toml) and contains no functional code changes. There is no security relevance visible in the commit.

This commit is a straightforward code cleanup: it introduces a small helper function called tal_free_if_taken() and replaces many repeated two-line patterns across the codebase with calls to that helper. The behavior of the program is unchanged; no security vulnerability is introduced or fixed.

This commit is a simple code cleanup: it introduces two new helper macros that log a warning or error message only once, and replaces three existing hand-written 'log once' patterns with those helpers. There is no change to program logic, no security fix, and no behavior change beyond making the code easier to read and maintain.

This change adds a traffic speed limit to the part of Core Lightning that handles incoming peer connections. It caps each peer at 1 megabyte of incoming data per second, with the goal of preventing a fast or aggressive peer from overwhelming the node. The commit describes this as a fairness and stress-handling improvement, not as a security fix, and no external security incident is referenced.