Core Lightning

This is a test-only change that stops CI test failures caused by slow valgrind runs. It does not change the actual Core Lightning node software that users run, so it has no direct security impact on real systems.

This is a small bug-fix in a downgrade helper tool. Previously, the tool only deleted an incompatible gossip data file when the database actually needed changes. Now it deletes that file even if the database is already compatible, preventing a scenario where downgrading leaves behind a gossip file that the older version cannot read. It is a correctness fix, not an exploitable security vulnerability.

This change only updates a test file so that downgrade tests create nodes using an older-format secret key file. It does not change any production code, network protocol, or wallet behavior, and there is no security issue in the commit itself.

This commit only updates test files and test helpers to match a new default wallet-seed format. It does not change production code, does not fix a vulnerability, and has no direct security impact on running Core Lightning nodes.

This commit only changes test code. It makes the wallet unit tests run twice: once using the older BIP32 key derivation setup and once using the newer BIP86 setup. No production code is modified, so it cannot directly affect real users or introduce a runtime security flaw.

This is a routine post-release maintenance commit for Core Lightning. It updates version numbers in the build files and test infrastructure after a new release, adjusts downgrade tests to reflect that downgrading past the new release no longer fails on a recently-added database feature, and removes some temporary test workarounds for APIs that are no longer considered deprecated. There is no direct security fix here; it is housekeeping that keeps the CI and downgrade tooling aligned with the current release cycle.

This commit fixes a bug where the `signmessagewithkey` RPC command did not work for newer BIP86-style wallets. Previously, the wallet RPC only searched through older BIP32-derived addresses, and the HSM signing code always used BIP32 key derivation. The fix makes both the wallet lookup and the HSM signing aware of BIP86 derivation, so users can sign messages with keys from BIP86 wallets. This is a functionality bug, not a clear security vulnerability, but it could have caused user confusion or application failures.

This commit fixes the 'recover' command in Core Lightning so it correctly detects whether a wallet has already generated Bitcoin addresses. Previously, the check only looked at one counter used by older wallets, but a newer type of wallet (BIP86) uses a separate counter. As a result, a BIP86 wallet that had already issued addresses could wrongly be allowed to run recovery, which could overwrite or confuse wallet state. The fix adds the missing check.

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 fix corrects how Core Lightning derives wallet addresses used in penalty transactions when a newer BIP39-style secret is in use. Previously, the code always used the older BIP32 derivation even when the wallet was configured for BIP86 (taproot) addresses. That mismatch could cause penalty transaction outputs to be sent to addresses the wallet does not recognize or cannot spend, potentially making recovered funds inaccessible after a channel breach.

This change only adjusts two test cases so they no longer save plugin input/output logs before deliberately crashing a test node. It fixes flaky test failures where reading a partially-written JSON file produced a decode error. It does not change any production code or affect real users.

This is a one-line change to a test file. It widens the expected log message pattern in a flaky test so that either 'fundpsbt' or 'signpsbt' slow operations are accepted, rather than only 'fundpsbt'. It does not change production code, user behavior, or security boundaries.

This commit fixes a test-only logging issue. A developer warning flag (dev_warn_on_overgrind) was not logging when an anchor transaction signature was shorter than expected, causing a pytest test to fail its feerate assertion. The fix adds a log message so the test can detect the short signature and skip the strict feerate check. There is no production security vulnerability here.

This is a test-only change. A developer made a test more tolerant of slow performance when the code is run under a debugging/performance-analysis tool called valgrind. It does not change the actual wallet or signing code, so it has no security impact on users.

This commit fixes a test-only diagnostic check in Core Lightning's hardware signing daemon (HSM). The code warns developers if a Bitcoin signature is unusually short (a sign of 'overgrinding' during signature creation), but it only checked the first input of an anchor-spending transaction. Anchor transactions can have multiple inputs, so the check missed short signatures on the other inputs. This is a testing/quality fix, not a vulnerability that attackers can exploit.

This commit is a documentation-only change. It updates the project's documentation files and JSON schemas so that author email addresses, web links, and tables are written in a format compatible with MDX (a modern documentation rendering format). There are no changes to the actual Core Lightning software code, so it cannot affect node security, funds, or network behavior.

This commit simply deletes a helper script named 'tools/lightning-downgrade'. No code changes to the actual Lightning node software are present, and no security issue is described or visible in the diff.

This commit simply adds two generated tool names to .gitignore files so that Git does not accidentally track compiled binaries. It does not change any executable code, configuration defaults, or security behavior.

This commit is a pure code refactoring: it moves the large database migration table and related functions from wallet/db.c into a new pair of files, wallet/migrations.c and wallet/migrations.h. The goal stated in the commit message is to make the migration list easier to share with a future downgrade tool. No behavior of the migrations themselves is changed, no SQL statements are modified, and no security fixes or vulnerabilities are introduced.

This commit adds infrastructure to Core Lightning's database code so that future versions can, in some cases, roll back (downgrade) a database to the previous software version. It is a feature addition, not a fix for an active security bug. The new code includes safety checks to refuse downgrade when data would be lost, such as when a newly added 'withheld' column has actually been used. There is no direct evidence in the commit that this resolves a known vulnerability or that an attacker can exploit it.

This commit is a straightforward code reorganization: it moves existing data-serialization helper functions for the askrene plugin into a new shared file (datastore_wire.c/h) so another tool (lightning-downgrade) can reuse them. No security bug is introduced or fixed; the logic is essentially unchanged.

This commit is a straightforward code reorganization: it moves existing datastore (key-value storage) database access functions out of wallet.c into a new pair of files, datastore.c and datastore.h, so a separate downgrade tool can reuse them. No behavior changes, no new features, and no security fixes are visible in the diff.

This commit adds a new offline command-line tool, lightning-downgrade, that lets a user roll back a Core Lightning node's database from the upcoming v25.12 release to the previous v25.09 release. It is meant as a recovery aid if an upgrade goes wrong. The tool only works when the lightning node is stopped, checks for a running process, and reverses database migrations one by one using built-in revert SQL and functions. It also deletes an incompatible gossip store file after downgrading. There is no direct evidence in the commit that this fixes an active security bug; it is a new operational utility.