Core Lightning

This commit fixes a bookkeeping timing issue in Core Lightning. When the bookkeeper plugin is configured to show amounts in a fiat currency, it previously only refreshed currency conversion rates when a user ran a command. Now it actively listens for new on-chain and channel events and refreshes rates immediately, so reports stay up to date without waiting for a manual command. The change is a correctness/quality improvement, not a security vulnerability fix.

This change is a hardening fix in Core Lightning's bookkeeping plugin. It prevents multiple simultaneous 'refresh' operations from racing each other and silently dropping duplicate results. Instead of ignoring cases where data arrives out of order, the code now asserts the expected order and queues follow-up refresh requests onto one shared in-flight operation. The visible risk is reduced reliability/correctness of accounting records rather than direct theft of funds.

This change lets users turn the bookkeeper's currency conversion feature on or off while the program is running, instead of only at startup. It also cleans up old exchange-rate data when the currency setting changes, and adds a safety check so a late answer from a previous currency request doesn't get stored. There is no obvious security bug here; it is a normal feature improvement.

This commit is a routine code cleanup: it introduces a small helper function that builds lists of text strings more conveniently, and updates three existing functions to use it. There is no security-relevant change visible in the diff.

This commit only adds a new unit test for an existing helper function called mkdatastorekey, which builds key arrays for the datastore. It also adds a small generated placeholder stub in another test file so that test continues to compile. There is no change to production code, no bug fix, and no security-related behavior.

This change adds a warning in the bookkeeper plugin when it tries to fetch a currency exchange rate for a payment event that happened more than 60 seconds ago. It is a defensive logging fix to avoid applying a current exchange rate to stale historical events. There is no vulnerability being exploited; it is a correctness and audit-quality improvement.

This change is a performance and storage optimization for Core Lightning's bookkeeping plugin. Instead of saving every single currency exchange rate sample to the datastore, it now saves ranges of time where the rate stayed the same. This reduces disk writes and storage size but does not fix a security vulnerability. There is a small risk that the new lookup logic could return a slightly stale rate if a stored range is extended too far, but the code includes a 60-second tolerance and explicit checks to prevent hiding failed updates.

This commit fixes how the Core Lightning bookkeeper plugin handles fiat currency codes and their decimal places. Previously it assumed every currency used 4 decimal places when storing and displaying exchange rates. Now it uses a proper ISO 4217 table so currencies like USD use 2 decimals, Chilean Unidad de Fomento (CLF) uses 4, and gold (XAU) uses 0. It also validates that the configured currency is a known ISO 4217 code. The main risk is that old stored rates could be misinterpreted after the change, and users might see wrong converted values if they relied on the previous fixed scaling.

This commit is a routine code-generation update that exposes three new currency-conversion RPCs (listcurrencyrates, currencyconvert, currencyrate) through the gRPC and Python/JSON-RPC bindings. It only adds generated request/response types, proto definitions, and server stubs. There is no change to core logic, authentication, authorization, cryptography, or network handling.

This patch fixes a timing bug in the bookkeeper plugin of Core Lightning. Previously, setting a currency option before the plugin was fully initialized could start background refresh tasks too early, potentially using uninitialized data. The fix delays starting those refresh tasks until after initialization is complete. It is a correctness fix rather than an obvious security vulnerability, but premature initialization can sometimes lead to crashes or unstable behavior.

This commit is a routine feature addition to Core Lightning's bookkeeping plugin. It exposes an already-recorded currency conversion rate (currencyrate) in the bkpr-listaccountevents RPC output when a currency setting is configured. There is no indication of a security bug, vulnerability, or fix.

This commit adds an optional bookkeeping feature to Core Lightning that lets users specify a currency (like USD). The bookkeeper plugin then asks another plugin for the exchange rate at the time of each financial event and records it. It is a feature addition, not a fix for a known security bug. The main security-relevant observation is that the new code makes JSON-RPC calls to a 'currencyrate' plugin and stores the returned rate, but it does not validate the currency name or the returned rate beyond checking that the rate is a valid JSON double. A malicious or compromised 'currencyrate' plugin could return extreme or malformed values, but this only affects optional accounting records, not funds or consensus.

This commit only adds a new automated test file for the currency rate feature. It does not change any production code, so it cannot introduce a security vulnerability by itself. The test is currently marked as expected to fail (xfail), meaning it documents a known behavior or bug in the median calculation when currency rates are cached.

This commit is a minor cleanup of a single test file. It replaces a manual sequence of log-search calls with a single helper that waits for multiple expected log messages regardless of order. There is no change to production code, no user-facing behavior change, and no security relevance.

This is a routine code cleanup in the bookkeeper plugin. Two internal helper functions are made visible to other source files so they can be reused in an upcoming report feature. There is no security-relevant change.

This is a test-only change that adds a one-second delay in an automated test to prevent flaky results. It does not change any production code, network behavior, or security logic.

This is a routine build fix for a test program on ARM64 computers. A missing piece (a file called pseudorand.o) was added to the linker command so the test binary compiles successfully. It does not change how the software behaves or fix any security flaw.

This commit imports a newer version of a low-level utility library (CCAN) used by Core Lightning. The main change adds a 'lock' feature to hash tables that lets developers mark a hash table as read-only during iteration. If code tries to add an entry to a locked table, the program will deliberately crash with an assertion failure rather than silently corrupting iteration. It is a defensive programming improvement, not a fix for a known exploitable bug in this commit itself.

This is a small internal code cleanup in Core Lightning. A wallet helper function that scans transactions for outputs belonging to the node is changed from returning a count of found outputs to returning a simple yes/no answer, with an optional list of output numbers. Callers are updated to use the new yes/no style. Nothing in the commit message or diff suggests a security bug is being fixed.

This commit removes an unused internal transaction filter called txfilter. The code that added wallet addresses and public keys to this filter is deleted because nothing was actually using the filter anymore. There is no indication in the commit that this fixes a security bug; it appears to be ordinary code cleanup.

This commit is a straightforward code cleanup: it takes the existing logic that handles the special case where a funding transaction's confirmation depth drops to zero (a blockchain reorganization) and moves it into its own named function. No behavior changes are visible in the diff. The commit message frames this as preparation for future work, not as a security fix.

This is a small internal code cleanup in Core Lightning. A function that builds a channel identifier (short_channel_id) used to look up a transaction's block position itself; now its callers look up that position and pass it in. The commit message frames this as preparation for a future change, not as a security fix. There is no indication of a vulnerability being patched.

This commit is a routine code cleanup: it moves a small helper structure and its hash/equality functions from the wallet module to the more general Bitcoin module so other code can reuse them. It also updates many test files to provide a stub for a hash-seed function and removes an unused header include. There is no security fix or vulnerability here.

This change refactors a helper function that turns Bitcoin scriptPubKeys into human-readable addresses. Previously the function measured the length itself using a memory-tracking helper (tal_bytelen). Now callers pass the length explicitly. This is mostly a code-cleanup to support data that isn't tracked by that helper, such as internal libwally transaction buffers. There is no direct security bug being fixed, but the old pattern could theoretically lead to incorrect length handling if a non-tal buffer were passed in future code.

This commit refactors how Core Lightning tracks the confirmation depth of a channel's funding transaction. Instead of watching a specific transaction ID, it now watches the block height at which the funding transaction was found. The change is described by the author as making the code more explicit and better suited to external blockchain watchers. There is no direct evidence in the commit that this fixes a security vulnerability, but it does touch reorganization handling and could affect how the node reacts when a funding transaction is removed from the blockchain.