Core Lightning

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 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 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 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 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 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 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 improves error handling in a Core Lightning plugin's list-protocols feature. It replaces a programming panic (an abrupt crash) with proper error messages when something goes wrong, and adds clearer logging. There is no direct evidence this fixes an exploitable security vulnerability, but it does make the plugin more robust and easier to diagnose.

This is a one-line type correction in a Lightning plugin. The code now reads an unsigned 64-bit integer (u64) instead of a truncated unsigned 64-bit integer (tu64) when fetching the optional 'extra_fee' amount from custom TLV data. The change aligns the implementation with BLIP-25's specification and is best understood as a protocol-compliance fix, not a security patch. There is no direct evidence in the commit or supplied references that this fixes an exploitable vulnerability.

This commit adds experimental support for a new Lightning protocol feature called LSPS2 'just-in-time' (JIT) channels. It lets a user request a payment invoice that, when paid, causes a Lightning Service Provider (LSP) to open a new channel on the fly and forward the payment. The code is marked experimental and contains several TODO/FIXME comments noting that important safety checks are not yet implemented, such as verifying the payment is not a forwarded payment, preventing double payment for the same channel, and checking that the LSP is trusted before accepting a zero-confirmation channel.

This commit adds experimental support for multi-part payments (MPP) in a new Lightning Service Provider (LSP) feature called LSPS2. It is a feature addition with test code, not a security fix. There is no indication in the commit that it patches a vulnerability or that the project treats it as a security-relevant change.

This commit is a minor cleanup of test code only. It replaces a manual three-step process for adding money to a test Lightning node with a single helper call. No production code was changed, and there is no security relevance.

This commit removes a runtime call to unwrap() in a Core Lightning plugin that handles incoming channel requests. Previously, if the JSON payload did not contain an 'openchannel' field, the plugin would panic and crash. The fix introduces a proper typed request structure so the plugin can gracefully handle malformed or unexpected input instead of crashing. It is a defensive hardening change rather than a fix for an active exploit.

This commit changes a single number in the code that creates 'just-in-time' (JIT) channels for Lightning Service Providers (LSPs). The old number enabled 'anchor' channels, which are a newer channel type. The new number disables anchors and falls back to a more basic channel type. The stated reason is that the Elements sidechain does not support anchor channels yet. This is a compatibility/configurability change, not a fix for an active security flaw.

This commit temporarily stops an experimental Lightning Service Provider (LSP) plugin from advertising a specific protocol feature to other nodes. The change is described by the developer as a short-term workaround to make automated tests pass, not as a security fix. It removes the public announcement of a feature bit while leaving the rest of the plugin's code in place, with a note that the underlying startup-order problem should be fixed later.

This commit removes a line that forced a channel reserve to zero in a Lightning plugin's response. A zero reserve could let one side drain a payment channel without keeping the usual safety buffer, potentially making it easier to cheat or destabilize the channel. The change is small and self-described as a development mistake, but the security implications depend on how the plugin is used and whether other protections remain in place.

This change makes a Core Lightning plugin less strict about a peer advertising a specific optional feature flag (the 'LSP feature bit'). Previously, if a peer didn't advertise that bit, the plugin would refuse to talk to it. Now it logs a warning and continues. This is a spec-compliance/usability improvement, not a clear security fix, but it slightly increases the chance of connecting to a peer that doesn't truthfully advertise its capabilities.

This commit adds ordinary helper functions for reading and writing 64-bit unsigned integers inside a type-length-value (TLV) data structure used by a Lightning Network plugin. It is a straightforward feature addition with no visible security bug or fix.

This commit is a small cleanup in a Core Lightning plugin. It moves the logic for reversing a list of feature bits into a shared helper function so callers don't have to remember to reverse the bytes themselves. The change is defensive: it reduces the chance of future mistakes when checking whether a peer supports a particular Lightning feature. There is no direct evidence in the commit of an active security bug being fixed, but the change is security-relevant because incorrect feature-bit checks could cause the plugin to misidentify peer capabilities.

This commit only adds user-facing documentation describing three already-existing experimental configuration options for a Lightning Service Provider (LSP) plugin. There are no code changes, no behavior changes, and no security fixes.