Core Lightning

This fix corrects a startup bug in Core Lightning where, after rolling back recent blocks to re-read them, the node could forget to keep watching certain spent transaction outputs. The main visible symptom was stale network gossip, but it could also cause the node to miss on-chain transactions if it restarted at the wrong time. The patch makes the node refresh its watch list after block rollbacks.

This commit only adds a new automated test to the project's test suite. It does not change any production code, so it cannot directly introduce or fix a security vulnerability in running software. The test is currently marked as expected to fail (xfail), meaning it documents behavior that is not yet working correctly—specifically, how the wallet tracks whether a coin is spent across a blockchain reorganization and a node restart. It may be a regression test for a future bug fix, but by itself it poses no security risk.

This commit adds a one-time background scan that re-examines old blocks to find UTXOs (unspent transaction outputs) the wallet may have missed earlier. It is a data-recovery / consistency fix, not an obvious exploit patch. The commit message does not call it a security fix, and there are no supplied references linking it to an attack. The change could matter for security because missed UTXOs can affect channel balances and on-chain funds, but the diff itself is defensive housekeeping.

This commit is a simple housekeeping rename. The Core Lightning project previously built a tool called `hsmtool`, then copied it to `lightning-hsmtool` during installation. This change removes the extra copy step and makes the installed name `lightning-hsmtool` the canonical name everywhere: source file, build system, documentation, and tests. No security vulnerability is introduced or fixed.

This is a routine fix to the project's automated release build script on GitHub. It removes an unnecessary step that installed a documentation tool and ran a configuration script on the build host. The change only affects how release binaries are produced internally and does not change any code that users run.

This commit is a routine release-candidate version bump and changelog update for Core Lightning v25.12rc1. It only changes version strings in packaging files and adds a changelog entry; it does not modify any executable code. The changelog itself lists many unrelated fixes and features from prior pull requests, but this commit is purely administrative release preparation.

This patch fixes a race condition in Core Lightning's plugin hook system. If a plugin was added or removed while a hook (like the one that decides whether to accept a payment) was actively being called, the internal list of plugins could be modified mid-iteration. That could cause a plugin to be called twice or skipped entirely, potentially leading to incorrect payment handling or other unexpected behavior. The fix defers updates to the hook list until all current callers are finished.

This commit adds a new plugin feature called 'filters' that lets plugin authors tell Core Lightning to only call their plugin's hook under certain conditions. For example, a plugin can now say 'only call me for pay commands' on the rpc_command hook. The change is a feature addition, not a bug fix, and there is no direct evidence in the commit that it addresses a security vulnerability.

This change makes Core Lightning re-broadcast funding transactions when the node restarts. Previously, only closing transactions were re-sent on startup. If a funding transaction was lost by the Bitcoin network (for example, due to a restart or mempool eviction), a new channel could be stuck waiting indefinitely. The fix improves reliability of opening channels, and the included test that was previously expected to fail now passes.

This commit only adds a new pytest test case. It does not change any production code. The test simulates a crash scenario during a Lightning channel opening to make sure the software handles it correctly in the future. It is marked as expected to fail (xfail), meaning it documents a known problem rather than fixing it.

This commit adds a new plugin notification so that plugins are told when a Lightning channel finishes closing and reaches the CLOSED state. It also makes the optional human-readable 'message' field in that notification truly optional in the generated API bindings. This is a routine feature addition, not a security fix or vulnerability.

This commit is a straightforward code cleanup: it introduces two new helper functions, amount_msat_deduct and amount_msat_deduct_sat, which are shorthand for 'subtract this amount from itself' (like a -= b). It then replaces many existing calls of the longer form amount_msat_sub(&x, x, y) with the shorter amount_msat_deduct(&x, y). There is no change in behavior, no bug fix, and no security relevance in the diff itself.

This commit only adds new test input files to a fuzz-testing seed corpus. It does not change any production code, configuration, or runtime behavior. The added files are used only during automated fuzz testing to exercise more code paths. There is no direct security impact on users running Core Lightning.

This commit only adds test data files (a fuzzing seed corpus) for a new fuzz test called fuzz-wireaddr. It does not change any production code, so it cannot introduce a runtime security vulnerability on its own. The corpus contains many malformed and unusual network address strings used to exercise the parser during automated testing.

This commit only adds a set of test input files (a seed corpus) for a fuzz-testing harness named fuzz-init_received. Fuzz testing feeds random or semi-random data to a program to find crashes or bugs, but the commit itself does not change any production code, fix any vulnerability, or introduce any new functionality. It is purely a testing-data addition.

This commit is a routine housekeeping change for a Rust-based software project. It moves version numbers for internal components into one central configuration file (the workspace root) and updates each component to reference that shared definition. There is no change to program logic, no bug fix, and no security patch visible in the diff.

This commit swaps most uses of the real-time clock function `time_now()` for a new internal helper called `clock_time()`. The change is infrastructure, not a fix for a known attack. It makes the node’s view of time easier to override for testing and reproducibility, and it reduces the risk that a backward clock jump confuses timers, logs, or payment expiry checks. Tracing is deliberately left on real time. There is no direct security bug being patched here, but the change touches many time-sensitive parts of a payment system, so it has broad defensive value.

This commit changes how Core Lightning generates 'pseudo-random' numbers when running in deterministic mode (used mainly for reproducible testing). It gives each separate piece of code that asks for a random number its own private counter, so the order in which different callers happen to ask no longer changes the random values they receive. The change is aimed at making tests more stable and easier to reproduce, not at fixing a security vulnerability in live operation.

This commit adds a database cleanup routine that marks old pending payments as failed if no corresponding payment route (HTLC) actually exists. Previously, payments could be stuck showing as 'pending' forever in commands like listpays/listsendpays, even though nothing was really happening. The fix only corrects stale bookkeeping state; it does not create a way for an attacker to steal funds or force payments to fail.

This commit only adds a new test case (and a small SQLite database snapshot used by the test). It does not change any production code. The test is currently marked as expected to fail (xfail), meaning it documents a known bug where Core Lightning may incorrectly report some payments as 'pending' when they actually have no active HTLCs. Because no fix is included, this commit by itself does not improve or worsen security.

This is a routine maintenance update to the project's Nix build configuration. It switches to a newer rolling-release package source, swaps a heavy PostgreSQL dependency for a smaller one, and adds a CI check to validate the Nix flake. There is no indication this fixes or introduces a security vulnerability in the Core Lightning software itself.

This commit only updates documentation metadata in the Core Lightning developers guide. It changes front-matter formatting (title, slug, excerpt, privacy settings) across 20 markdown files but does not modify any code, configuration, or security-relevant behavior. There is no security issue here.

This change is a straightforward instrumentation patch: Core Lightning's connection daemon (connectd) now records when a peer connection started and reports how long it lasted when the peer disconnects. The data is passed to the main lightningd process and included in internal peer-disconnect/reconnect messages. There is no evidence in the commit of a security bug being fixed or introduced; it appears to be a metrics/logging improvement.

This commit is a routine internal improvement, not a security fix. It makes the connection daemon (connectd) report back why a connection was attempted and how long it took, alongside existing success/failure messages. This is observability and diagnostic data being added to inter-daemon messages; it does not change who can connect, what they can do, or how funds are protected.

This commit adds a new administrative JSON-RPC command called `delnetworkevent` that lets a node operator delete a single diagnostic network event from the local database by its index. It is intended for housekeeping (for example, the autoclean plugin) and does not affect live channels or funds. There is no indication in the commit that this fixes a security bug; it appears to be a routine feature addition.