Core Lightning

This commit updates the currency-rate plugin in Core Lightning. It adds a new optional 'source' argument to the `currencyrate` command so users can pick a specific price source, rounds displayed rates to three decimal places, and adds argument-count checks to several commands to reject extra parameters. These are minor functional and hardening changes; there is no clear security vulnerability being fixed.

This commit adds a new optional 'source' argument to the currencyrate RPC command in Core Lightning. It lets users pick a specific exchange-rate source instead of getting the median across all sources. The change is purely a feature addition to the API and generated bindings; there is no indication of a security bug or fix.

This commit only changes test code for the currencyrate plugin. It adds new tests for rounding behavior, selecting a specific rate source, and rejecting unknown sources or too many RPC arguments. There is no change to production code and no security issue in the diff itself.

This commit only adds a README file for the currencyrate plugin. It contains documentation describing how to configure price sources and warning users that stopping the plugin can interrupt invoice creation. There are no code changes and no security fix or vulnerability introduced.

This commit simply deletes an old test that was written to document a known bug. The bug itself was already fixed in an earlier commit, and another test now serves as the regression test. No code behavior changes, and no new security issue is introduced here.

This commit refactors how the xpay plugin tracks the intended delivery amount for a Lightning payment. Previously, the code assumed payment->amount always meant the amount the recipient should receive. The change introduces helper functions so the code can distinguish between the total desired delivery amount and the amount currently tied up in active routing attempts. This is a defensive cleanup that may prevent bugs where fees or partial payments are mis-accounted, but the commit itself does not describe a specific vulnerability or exploit.

This commit adds a brand-new RPC command called sendamount to Core Lightning's xpay plugin. It lets a user make a payment by specifying how much they want to spend, rather than how much the recipient should receive. The change is purely additive: it exposes the new command through the JSON-RPC, gRPC, Python client, and documentation, and adds tests. There is no indication in the commit that it fixes a bug or addresses a security issue.

This commit fixes a small memory-management bug in the xpay plugin of Core Lightning. If the plugin's main payment function exits early (for example, because it receives an invalid invoice), it could fail to properly release a temporary copy of the invoice string, causing a minor memory leak. The fix makes an explicit copy of the string at the start so it can be safely cleaned up later. There is no direct evidence this is a security vulnerability, and the commit message does not describe it as one.

This is a simple internal code cleanup: a variable named `full_amount` is renamed to `mpp_amount` throughout the xpay plugin, with comments updated to explain that the value is used for Multi-Path Payment (MPP) coordination in the final hop of a Lightning payment. No behavior changes, no bug fixes, and no security relevance are visible in the diff.

This is a code-cleanup change in Core Lightning's experimental xpay plugin. The developer renamed a field and added helper functions so the code no longer confuses 'amount to deliver to the recipient' with 'amount we send into the network including fees'. The commit itself does not claim to fix a security bug, but it removes several places where the wrong meaning of 'amount' was being used, which could previously have led to incorrect fee calculations or payment accounting.

This commit adds a new optional flag called 'includefees' to the xpay plugin in Core Lightning. When enabled, it tells the routing system that the sender wants the payment amount to include any routing fees, rather than having fees deducted from the recipient's amount. This is a feature addition, not a bug fix or security patch. There is no indication in the commit that it addresses a security vulnerability.

This change adds a new validation check in Core Lightning's xpay plugin for a specific way of paying BOLT12 offers (sendamount with the includefees flag). It ensures such payments can only be used with offers that allow any amount, are one-time, and are in the same currency. The change appears to be a hardening/validation improvement rather than a fix for an active vulnerability.

This commit adds a helper function in Core Lightning's xpay plugin to correctly determine the multi-path payment (MPP) amount used in the final hop of a payment route. For normal xpay payments, this amount is already known, but for 'sendamount' payments where fees are included in the amount, the actual delivered amount must be used instead. The change ensures the correct value is passed when building both regular and blinded payment routes, likely fixing a bug where the wrong MPP amount could be set.

This commit adds a new management command (askrene-remove-channel-update) that lets users delete a previously-added channel override from an AskRene routing 'layer'. It is a routine feature addition: it removes one entry from an in-memory map inside the askrene plugin and does not touch funds, cryptographic operations, or network peers. There is no direct evidence in the commit that this fixes a security bug or introduces a vulnerability, but any new RPC surface slightly enlarges the attack surface and could hide logic bugs in input handling.

This commit is a straightforward feature addition, not a security fix. It adds an optional `offer_id` field to the `invoice_creation` event notification that plugins can subscribe to. This lets plugins know which BOLT 12 offer triggered a newly created invoice, avoiding the need to repeatedly query the node for invoice details. There is no vulnerability being patched here.

This commit fixes a bug in Core Lightning's wallet code where, if a prepared Bitcoin transaction failed during signing or broadcast, the coins that had been set aside ('reserved') for that transaction were not released back to the wallet. The fix makes sure those reservations are cleaned up automatically on failure, so funds are not stuck and become usable again. The change also adds tests that simulate a broadcast failure and verify the funds are no longer reserved afterward.

This commit fixes a single-character typo in a test's expected error message pattern. The word 'Unkown' is corrected to 'Unknown' in a regex used by an automated test. There is no change to production code, no security fix, and no user-facing behavior change.

This commit fixes a bug in Core Lightning's splicing feature where the fee rate used for splice transactions was accidentally based on the much higher 'unilateral close' fee rate instead of the intended 'opening' fee rate plus a small offset. The result was that normal splice-in and splice-out operations could be rejected or aborted because the calculated fee looked too high. The fix introduces a dedicated splice fee rate and updates the safety checks and tests accordingly. It is a correctness/availability issue rather than a remote exploit, but it could cause users to pay excessive fees or fail to use splicing.

This commit is a routine internal refactor of a new plugin called bwatch. It adds typed hash tables so the plugin can quickly look up different kinds of blockchain 'watches' (things it monitors on the Bitcoin blockchain). There is no user-facing change, no bug fix, and no security-sensitive behavior introduced.

This commit adds a save-and-reload feature for the bwatch plugin so that after a restart it remembers which Bitcoin transactions, outputs, and channel IDs it was monitoring. It stores these in the node's internal datastore and reads them back on startup. There is no obvious security bug in the change, but it is a new persistence mechanism that could affect reliability and, if misused, could let a stale or incorrect watch live longer than intended.

This commit adds two internal notification functions inside Core Lightning's new block-watching plugin. They are not yet connected to anything; the commit message says they will be wired up later. There is no user-facing change and no security fix or vulnerability present in the diff.

This commit adds the actual scanning logic to a new 'bwatch' plugin that watches the Bitcoin blockchain. Before this change, the plugin fetched blocks but never inspected the transactions inside them. Now, after each block is downloaded, it walks through every transaction and checks whether any output matches a watched Bitcoin address (scriptpubkey) or whether any input spends a watched previous transaction output (outpoint). When a match is found, it sends a notification back to the main lightningd process. This is a normal feature-completion commit for a block-watcher plugin; it does not by itself look like a security fix or vulnerability.

This commit refactors a Core Lightning plugin so that block scanning can be limited to a single user-provided watch instead of checking every active watch. It is a preparatory change for adding a 'rescan' feature and does not, by itself, change any externally reachable behavior. There is no indication it fixes a security bug or introduces a vulnerability.

This commit adds two new internal plugin commands, addscriptpubkeywatch and delscriptpubkeywatch, to the bwatch plugin in Core Lightning. They let lightningd ask bwatch to start or stop monitoring a Bitcoin output script (scriptpubkey) for a specific owner. The change is a straightforward feature addition with no obvious security bug in the diff itself.

This commit adds two new internal plugin commands, addoutpointwatch and deloutpointwatch, to the bwatch plugin in Core Lightning. They let the lightning node start or stop watching a specific transaction output (a txid plus output number) on behalf of a named owner. There is no indication in the commit that this is a security fix or that it addresses any vulnerability; it reads as ordinary feature work.