Core Lightning

This commit removes an old, renamed label from the list of features shown for Lightning peers and channels. The old label 'option_anchors_zero_fee_htlc_tx' is replaced by the current spec name 'option_anchors'. It is a routine cleanup of a deprecated JSON-RPC field, not a security fix.

This commit removes an old, unused function called sign_local_htlc_tx from the wallet's Hardware Security Module (HSM) interface. The function was previously used by the on-chain transaction handler (onchaind) but is no longer called anywhere. The change is a cleanup that also updates a comment about another function used by watchtowers. There is no security fix here.

This commit removes leftover code that tried to read a configuration option called 'max-locktime-blocks' from three payment-related plugins. That option was already removed from the core software, so the code was doing nothing useful. The commit also hardcodes the fallback maximum payment delay to 2016 blocks, which was already the previous default. There is no direct security fix here; it is mostly cleanup of dead code.

This commit removes the old 'decodepay' JSON-RPC command from Core Lightning. It was already marked as deprecated and users are directed to use the newer 'decode' command instead. There is no security bug being fixed here; it is a routine cleanup of an obsolete API.

This is a routine maintenance update to a GitHub automation script that publishes Core Lightning's RPC documentation to a documentation platform. The script's API call now uses the parameter name 'position' instead of 'order' because the documentation platform changed its API. It also updates the target branch from '1' to 'stable' and improves log messages. There is no security relevance.

This commit only updates documentation build files. It adds a new manual page entry for an existing command (`signmessagewithkey`) and re-sorts some other entries alphabetically. There are no code changes and no security implications.

This is a routine improvement to a GitHub automation script that synchronizes documentation to a third-party service (ReadMe). It adds basic safety checks—verifying an API key is present, confirming files exist before opening them, and switching from document 'title' to 'slug' for matching. There is no indication this fixes a security vulnerability in the Core Lightning software itself; it simply makes a docs-publishing script fail more gracefully and avoid some accidental mismatches or crashes.

This commit only reformats documentation files and JSON schemas so they display correctly in a new documentation system (MDX). It changes email addresses from angle-bracket style to mailto links, wraps code snippets in backticks, and converts plain URLs to Markdown links. No program code, logic, or security behavior is changed.

This commit updates a GitHub automation script that synchronizes documentation pages with the ReadMe documentation platform. It changes the documentation category slug from 'JSON-RPC API Reference' to 'JSON-RPC' and removes URL-encoding of that slug. It also adds an error message when the ReadMe API request fails. There is no security-relevant change here.

This commit adds a testing-only environment variable that, when enabled, tells Python's logging system not to raise exceptions if something goes wrong while formatting or emitting log messages. It only affects the project's internal Python test harness and has no bearing on real Lightning node operation, funds, network security, or production code.

This commit only changes how the project's automated testing and build scripts set an environment variable (TEST_LOG_IGNORE_ERRORS=1). It tells the test logging library not to treat certain log-related issues as fatal during test runs. There is no change to the Core Lightning node software, wallet handling, network protocol, cryptography, or any code that runs in production. It is purely a testing-infrastructure convenience fix.

This commit adds a new data type called 'string_map' to the code generator used for converting between Core Lightning's JSON-RPC interface and its gRPC/Rust interfaces. It is a feature addition for the message generator and testing schema validator, not a security fix or vulnerability patch.

This commit adds a new feature to Core Lightning's REST plugin that lets plugin developers register custom web API paths. It is a feature addition rather than a fix for a known vulnerability. The change expands the attack surface of the REST API by allowing dynamic path registration, but it also includes optional rune-based access controls. There is no direct evidence in the commit of a security bug, though any dynamic routing feature introduces risks if paths are registered carelessly or if input validation is flawed.

This commit simply adds 'Fedora' to the list of Linux distributions whose release binaries are checked against published checksums during the release verification script. It is a build-process expansion, not a code change, and introduces no security vulnerability.

This commit is a build-hardening change, not a security fix for a vulnerability. It makes Fedora release builds reproducible by pinning timestamps, locking the Rust compiler version, disabling a binary identifier that can vary between builds, and avoiding stale Docker cache. There is no indication it patches an exploitable flaw.

This change adds a Docker command-line flag that forces builder images to be rebuilt from scratch instead of reusing cached layers. It is a build-hygiene fix to avoid stale cached images after dependency updates. There is no security vulnerability here.

This commit only updates the user documentation for installing Core Lightning on Fedora. It changes the recommended Fedora version from 27 to 39 and adds a few required build dependencies and tools (Rust, lowdown, PostgreSQL development files, etc.). There is no code change and no security issue in the commit itself.

This commit updates a Fedora-based Docker builder image used for compiling Core Lightning. It moves from an old Fedora release (35) to a current one (40), adds missing build tools such as the protobuf compiler, and switches to a modern Rust toolchain via rustup so the build can understand newer Cargo lockfiles. There is no security flaw being fixed here; it is routine build-environment maintenance.

This change fixes a bug where Core Lightning's wallet scanner only watched for Taproot-style transactions for BIP86-derived keys, but missed ordinary SegWit v0 (P2WPKH) transactions. Because BIP86 keys can produce both address types, funds sent to a P2WPKH address derived from the same key would not be detected or credited. This is a correctness/loss-of-funds bug rather than an active theft vulnerability.

This commit fixes a bug where Core Lightning nodes created with a modern mnemonic (version 25.12 or newer) could not correctly sign transactions that spend from non-Taproot on-chain addresses. The address generation code was updated to use a new key derivation method for all address types, but the signing code still only used that method for Taproot addresses. As a result, the private key used to sign did not match the public key in the address, causing transaction broadcast failures with an OP_EQUALVERIFY script error. The fix makes the signing code use the new derivation for all address types when the node uses the modern mnemonic format.

This change fixes how Core Lightning derives the public key used for 'change' outputs when rebroadcasting on-chain HTLC (Hashed Time-Locked Contract) transactions that pay to a Taproot (P2TR) address. Previously, the code always used the older BIP32 derivation even when the wallet was configured for the newer BIP86 Taproot-specific derivation. Using the wrong derivation path could produce a change output that the wallet does not recognize or cannot spend later, potentially locking up funds. The patch checks whether BIP86 is available and uses it for P2TR change outputs, falling back to BIP32 otherwise.

This small change updates how Core Lightning creates the 'change' output when spending an anchor output in a Lightning channel. It now uses a newer, Taproot-specific key derivation method (BIP86) when available, instead of the older BIP32 method. The change itself is a correctness/hardening improvement for Taproot key handling, not a fix for an active exploit or a clearly disclosed vulnerability.

This change fixes a wallet bug in Core Lightning. When closing a payment channel with a peer that only supports older Bitcoin address formats, the software was deriving the refund address using the wrong key path for modern BIP86 wallets. After a restart, the wallet might not recognize those funds because it looks for keys at the BIP86 path. The patch makes the fallback address use the same derivation method as modern Taproot addresses, so the wallet can always find the funds.

This is a small developer-only change to a wallet debugging command. It makes the internal `dev_listaddrs` tool also work with newer BIP86-style wallets (mnemonic/seed-based), instead of only older BIP32-style wallets. There is no direct evidence this fixes an exploitable security bug; it appears to be a compatibility/API improvement for tests.

This change fixes how Core Lightning derives Bitcoin/Elements addresses when creating change outputs or PSBT outputs from a wallet seed phrase (mnemonic). Previously, on Elements sidechains, the code derived the public key one way and then built a SegWit address from it directly. Now it uses a dedicated helper that follows the same derivation path used elsewhere (including the future Taproot path). The practical risk is that change outputs could have been sent to addresses the wallet did not fully recognize or could not later spend from, which can lock up funds.