Core Lightning

This commit only adds a new fuzz test file. It does not change any production code, fix a bug, or patch a vulnerability. Fuzz tests feed random or crafted inputs to a function to help find future bugs, but adding the test itself is a defensive quality-assurance change, not a security fix.

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 adds a new GitHub Actions workflow that automates the creation of pull requests to bump the version numbers of Rust crates in the Core Lightning project. It is a routine development and release automation change with no direct security relevance.

This commit adds a hidden developer-only command-line flag called --dev-ignore-ibd to Core Lightning's Bitcoin backend plugin. When enabled, it tells the plugin to lie to the main lightning daemon and claim that Bitcoin is not in 'initial block download' mode, even if it actually is. This is intended only for developer testing scenarios (for example, when using canned/fake blocks) and is not exposed as a normal user option. There is no indication in the commit that this is a security fix or that it addresses a reported vulnerability.

This change makes a Lightning node return a single, predictable incoming channel when running in deterministic mode (used for reproducible testing and invoice route hints). Previously, multiple candidate channels could be returned in a non-deterministic order, which could cause the same invoice to produce different route hints across runs. The patch selects the highest-capacity channel as the one and only candidate. This is primarily a reliability/consistency fix; it does not appear to be a direct security vulnerability, but non-deterministic route hints could theoretically leak extra topology information or cause payment routing inconsistencies.

This commit swaps wall-clock timestamps for monotonic timestamps when measuring durations and timeouts in several parts of Core Lightning. Monotonic time only moves forward at a steady rate and is not affected by system clock changes or developer time overrides. The change makes timeout logic more reliable and prevents accidental misbehavior during testing, but it is a hardening/refactoring patch rather than a fix for an active, exploitable vulnerability.

This commit adds a testing-only feature called 'canned blocks' to the Core Lightning Python test framework. It lets developers replay pre-recorded Bitcoin blocks during tests instead of generating new ones, and fixes an off-by-one bug when saving blocks. There is no change to production code or to how real users' funds or nodes are secured.

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 adds a developer-only feature that lets Core Lightning's internal clock be overridden via an environment variable (CLN_DEV_SET_TIME). It is intended for reproducible testing, not normal operation. The change itself is not a vulnerability, but it creates a new mechanism that could be misused if an attacker can set environment variables before launching the node.

This commit removes a developer-only testing option that let operators override the clock used by the gossip subsystem. It is a cleanup/refactoring change, not a security fix. The removed option was only available in developer builds and was being replaced by a more general time-override mechanism (CLN_DEV_SET_TIME).

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 developer-only feature that lets Core Lightning use predictable fake random numbers instead of real cryptographic randomness when a special environment variable is set. It is intended only for testing and reproducible debugging, not for production use. The code is gated behind developer mode and is not itself a vulnerability, but any accidental use in production would severely weaken security that depends on randomness.

This change only affects Core Lightning when a special developer-only environment variable (CLN_DEV_ENTROPY_SEED) is set. It makes the order in which the wallet picks coins deterministic instead of random, which helps developers reproduce tests. In normal operation the wallet still picks coins randomly, so this commit does not introduce a security vulnerability for regular users.

This change is a straightforward internal cleanup: it replaces direct calls to the cryptographic library's random-byte function (randombytes_buf from libsodium) with a project-specific wrapper called randbytes(). The wrapper currently does the same thing, but having it in one place makes it easier to swap in a deterministic (predictable) random source for testing in the future. There is no direct security bug introduced by this commit itself, and no evidence it weakens real-world randomness.

This commit fixes a developer-only edge case. When running Core Lightning with a special developer mode flag (CLN_DEV_ENTROPY_SEED) that forces the same randomness seed for testing, multiple channel-opening sub-processes could accidentally pick the same internal IDs. That could cause a PSBT (transaction-building data structure) collision when combining contributions. The fix tweaks the seed slightly for each new sub-process so IDs differ, then restores the original seed afterward. It is not a normal user security bug and does not expose funds or keys.

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 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 changes an experimental splicing feature's internal message numbering from 0 to 1 so it matches the official Lightning spec and becomes optional. It is a compatibility/standards-alignment fix, not a direct security patch. Both channel peers must upgrade together or they may fail to understand each other's splice-related messages.

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 simply removes a slow, timing-out FreeBSD continuous-integration test job from the project's GitHub Actions. It does not change any production code, wallet logic, network handling, or cryptography. There is no security issue in the change itself.

This commit updates Core Lightning's implementation of the Lightning protocol's 'splicing' feature to match a newer draft specification. It changes the format of the channel_reestablish message used when two nodes reconnect after a disconnection. The changelog calls this a breaking change: both nodes in a channel must upgrade together if splicing is enabled, or they may fail to reconnect or misunderstand each other's state. The changes are primarily protocol-compliance and interoperability fixes rather than a clear security patch, but they affect how nodes agree on which funding transaction is active after a splice.

This commit adds a new automated test for the xpay payment feature. It checks that when a payer's node is behind on the latest blockchain block height, xpay will wait briefly for the node to catch up instead of immediately failing. The test is marked as expected to fail for now, meaning it documents desired behavior that may not yet be fully implemented. There is no code fix or security vulnerability visible in this change.

This update fixes a bug in Core Lightning's experimental 'xpay' payment plugin. Previously, if the final recipient rejected a payment because it thought the current blockchain height was higher than what xpay believed, xpay would immediately give up and report a permanent failure. Now, xpay detects that hint, waits until its own view of the blockchain catches up, and then retries. This prevents unnecessary failed payments when nodes are briefly out of sync on block height.

This commit adds a new RPC command, askrene-bias-node, to Core Lightning's askrene routing plugin. It lets users tell the routing engine to prefer or avoid paths that go through a specific Lightning node. The change is a feature addition: it extends existing layer/bias machinery with a new per-node bias type, updates generated RPC bindings, schemas, documentation, and tests. There is no direct evidence in the commit of a security vulnerability, but any new RPC that influences route selection can affect payment reliability, fees, and potentially be misused by an authenticated caller to degrade routing behavior.