Core Lightning

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 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 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.

This commit adds a creation timestamp to the 'channel biases' used by the askrene routing plugin and lets old biases be cleaned up by the existing askrene-age command. It is a feature enhancement, not a security fix. There is no indication it addresses a vulnerability or that the prior lack of timestamps was exploitable.

This commit only updates documentation metadata in the beginner's guide. It changes front-matter formatting (title quoting, excerpt placement, privacy/view settings) and removes some timestamp fields. No code, configuration, or security behavior is changed.

This commit only updates documentation metadata in Core Lightning's contributor guide. It changes front-matter formatting (title quoting, timestamps, privacy settings) across nine markdown files. There are no code, configuration, or behavior changes that could affect security.

This commit updates a GitHub Actions script that publishes Core Lightning's RPC command documentation to the ReadMe documentation platform. It changes API endpoints and authentication format to match ReadMe's newer API version. There is no security-relevant change to the Core Lightning node software, wallet funds, network protocol, or user data.

This commit updates the documentation publishing workflow from version 8 to version 10 of a ReadMe.io tool called 'rdme'. It only changes how project documentation is uploaded to an external docs site and does not touch the Core Lightning software itself, user funds, network code, or any secrets storage. The API key is still stored as a GitHub secret and is still passed to the tool in essentially the same way.

This commit only updates documentation metadata (front-matter formatting, visibility settings, and timestamps) in the Core Lightning node operator guide. No code, configuration, or security behavior is changed.

This commit only updates the formatting and metadata of the 'getting started' documentation files for a new documentation platform version. It does not change any software code, configuration defaults, or security behavior of Core Lightning.

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 commit fixes a bookkeeping bug in the autoclean-once feature. Previously, when you asked to clean up failed payment forwards, the tool counted every forward that wasn't deleted—including successful forwards that were never supposed to be deleted—as 'uncleaned'. Now it only counts records that were actually candidates for cleanup but were too new to be removed. This is a user-interface/reporting fix, not a security vulnerability.

This commit is a documentation and generated-code cleanup. It corrects a comment that incorrectly described which HTLC (payment routing slot) states correspond to outgoing versus incoming payments, and removes a duplicate enum definition in favor of a shared one. There is no change to how the software actually processes payments or secures funds.

This commit fixes a build issue where Core Lightning Docker images were missing their version label. It changes how the VERSION value is passed from GitHub Actions into the Docker build and how the Makefile accepts an externally provided version. There is no security problem here—just a packaging/metadata fix.

This is a one-line change to the project's GitHub release automation. It removes a command that renamed a checksum signature file. The change fixes a release-script failure caused by an earlier commit that already changed the output filename. There is no indication this affects running Lightning nodes, user funds, network security, or introduces any vulnerability.

This commit adds a security check in Core Lightning's LSPS (Lightning Service Provider Specification) plugin so that the client only accepts 'zero confirmation' channels from LSPs it has previously approved for a JIT (just-in-time) channel. Before this change, the plugin blindly allowed any zero-conf channel opening, which could let a malicious or mistaken LSP open a channel the user never requested. The patch stores an approval record when the user approves a JIT channel, then checks that record when an open-channel request arrives, deleting it after use. A new test confirms that unapproved zero-conf channels are rejected.