Core Lightning

This commit only updates documentation. It adds the '--frozen' flag to 'uv sync' commands in the installation guide so that the build tool does not update the dependency lock file automatically. This prevents the working directory from becoming 'dirty' during a build, which could otherwise cause the compiled Core Lightning version string to incorrectly show as modified. There is no code change and no security vulnerability is introduced or fixed.

This commit removes empty Python package marker files called __init__.py from several related Python library packages. It is a routine modernization to use Python 3.3+'s built-in namespace package support instead of the older pkgutil workaround. There is no security-relevant change here.

This commit is a routine cleanup of Python project configuration files. It removes duplicate workspace dependency definitions that were already set at the workspace level. There is no security relevance: no code behavior changes, no bug fixes, and no vulnerability patches.

This commit fixes a bug in Core Lightning where a plugin could advertise certain protocol features when it first starts up, then later disable itself during initialization, but leave those feature bits still advertised by the node. The fix stores the feature bits a plugin claims and removes them if the plugin later disables itself. A leftover feature bit could mislead other nodes about what this node supports, potentially causing connection or protocol issues, though it is not a direct theft-of-funds bug.

This commit is a simple build-system revert that puts one file (common/hsm_encryption.o) back into the fuzzing test Makefile. It undoes a prior change that had removed that file from the fuzzer's build list. There is no direct code change shown, and nothing in the commit message or diff indicates a security vulnerability or fix. It is most likely a routine build correction.

This commit changes a testing helper so that calls to Bitcoin Core during automated tests wait longer before giving up. It is purely a test-infrastructure reliability tweak and does not affect production code, user funds, or network security.

This commit adds a new automated test for a database cleanup routine called migrate_remove_chain_moves_duplicates. The test builds a small in-memory database, inserts many example records (some deliberately duplicated), runs the cleanup function, and checks that only the duplicates are removed. It does not change the actual cleanup code or any production behavior; it only adds test coverage.

This commit adds a database cleanup routine that removes accidentally duplicated accounting records created by a previous bug. It is a data-integrity fix, not a security patch that stops an active attack. The underlying bug allowed the same on-chain money movement to be recorded twice—once under a live channel reference and once under a non-channel account reference—so users' coin-movement reports could be wrong until the duplicates are removed.

This commit only adds a new automated test file. It checks that a wallet function called wallet_save_chain_mvt correctly ignores exact duplicate records while still storing records that differ in transaction ID, output point, or movement type. There is no change to production code, no bug fix, and no security patch.

This commit fixes a bug in Core Lightning's accounting/bookkeeping system where the same on-chain money movement could be recorded twice in the database after a migration. The bug happens because the code looked for duplicates using one account identifier, but after a migration or replay it could store the same event under a different identifier. The fix makes duplicate detection check both possible identifiers. It is a data-integrity bug, not a security vulnerability that an attacker can exploit.

This commit only adds a new test to the test suite. It checks that old payment records (HTLCs) are not deleted from the database immediately when a channel closes, but are instead cleaned up later when the node restarts. There is no code change that fixes or changes any behavior.

This change moves a database cleanup job from the moment a channel closes to the next time the node starts up. Previously, deleting tens of thousands of old payment records when a channel closed could freeze the node for hundreds of milliseconds. Now the records are counted and reported immediately, but actually deleted later during startup. It is a performance and availability improvement, not a security fix.

This is a small, forward-looking cleanup change in Core Lightning's wallet code. It adjusts a database query so that the `listhtlcs` command will not return HTLCs (payment forwarding contracts) belonging to channels that have already been closed. The commit explicitly says this situation cannot happen yet because HTLCs are currently deleted when a channel closes, but the code is being prepared for an upcoming change where closed-channel HTLCs may be kept around.

This commit only changes test code. It makes pytest skip certain tests when the software is built without Rust support, so those tests no longer fail in non-Rust builds. There is no change to the actual Lightning node or wallet code, and no security issue is introduced or fixed.

This commit removes one object file (hsm_encryption.o) from a fuzz-testing Makefile. It is a build/test maintenance change with no visible security relevance to the actual Core Lightning software.

This commit adds a missing 'uv' tool installation step to an internal GitHub workflow that synchronizes RPC documentation to a readme server. It is a routine build/CI fix with no apparent security relevance.

This commit fixes a simple off-by-one bug in the bookkeeper plugin. When restarting, the plugin reloads saved 'rebalance' records from its database. The code was reading the wrong part of the database key, so it could not split the two stored numbers apart and would log a 'weird' error and skip the record. The fix changes one number so it reads the correct key segment. A previously-failing test is now enabled. There is no direct security exploit here; the main risk is that accounting records could be missing or inconsistent after a restart.

This commit adds a new test that demonstrates a bug in Core Lightning's bookkeeping plugin: after a node restart, 'rebalance' fee records are lost and the plugin logs a 'BROKEN' warning about an unparsable datastore entry. The test is marked as expected-to-fail (xfail) so it documents the bug without breaking CI. It is a test-only change, not a fix, and there is no security exploit here.

This commit removes two old command-line flags, --experimental-quiesce and --experimental-offers, from the Core Lightning node software. These features became standard behavior in version 24.11, so the flags were only kept around temporarily to avoid breaking old configurations. There is no security issue here; it is ordinary cleanup of deprecated options.

This commit removes an old JSON-RPC field named `blinding` from the `decode` command output. It was already renamed to `first_path_key` in a previous version and has now been fully removed after a deprecation period. This is a routine cleanup, not a security fix.

This commit removes an old, duplicate field name from a plugin hook used when receiving onion-routed messages. The field 'blinding' is being dropped in favor of the newer name 'first_path_key'. It is a planned API cleanup, not a security fix, and does not change how messages are processed or validated.

This commit only reformats a documentation table so the columns line up nicely. No code, no behavior, and no security-related changes are present.

This commit updates Core Lightning's implementation of BOLT12 recurring payments to match a newer draft of the specification. It renumbers data fields, splits a setting into compulsory and optional versions, moves a proportional-amount setting into a different field, and adds a new invoice-request cancellation field. The changelog explicitly notes this is an experimental/draft feature change that breaks backward compatibility with old recurring offers. There is no direct evidence in the commit of a security vulnerability.

This commit removes an experimental BOLT12 feature called `start_any_period` from Core Lightning's offer recurrence system. It is a protocol/API cleanup change, not a security patch. The functionality is replaced by the existing `absolute_expiry` mechanism for restricting when offers can be used. There is no direct evidence in the commit of a vulnerability being fixed.

This commit adds a spelling check to the project's tooling. It prevents developers from misspelling the word 'recurrence' as 'recurrance' in the codebase. There is no security relevance.