Core Lightning

This commit adds a new internal module for handling the secret key file used by Core Lightning's hardware security module (HSM). It introduces support for reading the existing plain and encrypted formats, plus new formats based on BIP39 word lists (mnemonics) with optional passphrases. The code uses modern password hashing (Argon2) and authenticated encryption (libsodium secretstream). There is no direct evidence in the commit that this fixes a known security vulnerability; it appears to be a feature/refactoring change to support new wallet backup formats.

This commit updates an internal helper library (CCAN's grab_file) so it can read files either as plain binary data or as text with a trailing null character. Most existing callers are switched to the text variant to keep old behavior, while a few callers that handle binary data (like HSM secrets, plugin checksums, and Tor authentication cookies) now use the new binary variant. This is a cleanup/refactoring change that removes the awkward workaround of trimming off an unwanted null byte. There is no direct evidence in the commit that it fixes an active security vulnerability, but correct handling of binary secrets is security-relevant.

This commit removes a command-line option called --use-bip86-derivation from Core Lightning and makes BIP86-style wallet addresses the automatic default whenever the node is set up with a mnemonic-based secret. It also disables a large batch of automated tests that were checking BIP86 and related wallet behavior, with comments saying the tests are being skipped because of derivation mismatch issues. The change itself is a feature/configuration cleanup rather than a clear security fix, but it touches how wallet keys are derived and how funds are tracked, which can affect user funds if the derivation logic is wrong.

This commit removes an outdated comment above a function declaration. The comment said a function gets and checks a derived public key, but the function apparently no longer performs the check part. There is no code change, only a documentation cleanup.

This commit only adds placeholder message types and stubs for a future BIP86 key-derivation feature. The new wire messages return an explicit 'not implemented yet' error and perform no actual key derivation, signing, or secret handling. There is no active security issue in this patch itself.

This commit only adds two new automated tests to the project's test suite. It does not change any production code, so it cannot introduce a security vulnerability or fix one directly. The tests verify that BIP86 (a type of Bitcoin taproot wallet address) behaves correctly when generating many addresses and when used in transaction signing workflows.

This commit adds a new fuzz test and its test data. Fuzz tests are automated tools that throw random or crafted inputs at a piece of code to look for crashes or bugs. The new test exercises the encryption and decryption routines for the node's HSM (Hardware Security Module) secret, but it does not change those routines themselves. There is no indication this commit fixes or introduces a security vulnerability.

This commit simply removes an old set of source files and test data for HSM (Hardware Security Module) encryption. The code being deleted is described by the developer as having been replaced by a newer 'hsm_secret' implementation. There is no indication in the commit that this fixes a security vulnerability; it appears to be routine cleanup of replaced code.

This commit changes how Core Lightning's Hardware Security Module daemon (hsmd) creates and stores the master secret for new nodes. Instead of a raw 32-byte random secret (optionally encrypted with a password-derived key), new nodes now get a 12-word BIP-39 mnemonic phrase as their root secret, with an optional passphrase. The old --encrypted-hsm option is deprecated in favor of --hsm-passphrase. The change is a feature redesign of key storage, not a fix for a known exploitable bug, but it touches critical cryptographic material and removes legacy encrypted-secret handling.

This commit adds support for a new Bitcoin address type called 'bip86' in Core Lightning. It lets users generate and list Taproot addresses derived using the BIP86 standard through the lightning-cli tool. The change is a feature addition, not a fix for a known security bug. There is no evidence in the commit or supplied references that this resolves an active vulnerability.

This commit only changes test code. It makes Core Lightning's test suite avoid asking for taproot (p2tr) Bitcoin addresses when running on the Liquid sidechain, because Liquid does not support that address type yet. There is no change to production wallet or node code, and no security fix.

This commit only adds tests and documentation for a new wallet address type called BIP86. It does not change the actual wallet or address-generation code. There is no security bug visible in this patch.

This commit refactors how Core Lightning's Hardware Security Module (HSM) provides a BIP86 base key. Previously, the main daemon asked the HSM for the key via a separate request after initialization. Now, the HSM includes the key directly in its initialization reply when the secret is mnemonic-based. This is a design cleanup that reduces the number of HSM messages and removes a dedicated key-derivation wire command. There is no direct evidence in the commit that this fixes an active security vulnerability, but it does reduce the attack surface by removing one HSM interface that exposed a sensitive extended key.

This commit refactors the Core Lightning 'hsmtool' utility to use a new unified API for handling the node's master secret file (hsm_secret). It adds support for storing the secret as a 12-word English mnemonic phrase inside the file, and removes support for non-English mnemonic wordlists. The change is a feature/rewrite rather than a clear security fix, but it touches sensitive key-handling code and removes some legacy behavior. There is no vendor statement that this is a security patch, and no independent attribution.

This commit is a small internal cleanup in Core Lightning's wallet code. It removes a separate category ('BIP86') for one kind of Taproot (P2TR) address and treats all P2TR addresses the same way. There is no obvious security bug being fixed; it appears to be a simplification/refactoring change.

This commit is a small, preparatory code change that adds a new internal label for a future type of Bitcoin address (BIP86-style taproot). It does not implement the feature, change how money is handled, or fix any bug. There is no security issue visible in this patch.

This commit only changes test files. It updates test cases to use the new 'p2tr' address type label instead of older labels like 'bech32' or 'bip86', removes skip markers that previously disabled tests, and adjusts expected output counts and comments to match a unified key derivation approach. There is no change to production wallet or Lightning code, so it does not introduce or fix a security vulnerability on its own.

This commit fixes a build failure on older GCC compilers by adding a missing header file. It does not change runtime behavior or fix any security vulnerability.

This commit simply removes an unused helper function that created random padding for Bitcoin-style data scripts. There is no security fix or vulnerability here—just cleanup of dead code that happened to pull in randomness routines.

This commit only changes two internal test files to use a monotonic clock instead of the current wall-clock time when measuring how long test operations take. It does not change any production code, cryptographic algorithms, or network behavior. There is no security issue here.

This commit removes an unused internal timestamp field (`start_time`) from a data structure used when fetching filtered Bitcoin blocks. It is a straightforward code cleanup with no functional or security change.

This commit adds a test that reproduces a crash in Core Lightning when a user performs a channel splice before the channel has been publicly announced. The crash is an assertion failure in the code that handles funding transaction confirmations. The test is marked as expected to fail for now, meaning the bug exists but is not yet fixed.

This commit only adds documentation examples for two existing RPC commands, listchainmoves and listchannelmoves. It does not change any runtime code, security logic, or behavior of the Core Lightning node. There is no security issue here.

This commit fixes a minor developer-only bug where a special diagnostic flag (--dev-save-plugin-io) could reuse filenames across internal restarts, causing file creation to fail. It adds a startup timestamp to filenames so they stay unique. This flag is not used in production and the failure mode is a noisy error, not a security vulnerability.

This is a small internal cleanup in Core Lightning's memory-tracking helpers. It makes the 'notleak' marker safe to use earlier during program startup, before the full memory-leak detection system is ready. There is no direct security vulnerability being fixed; it is a robustness improvement that prevents potential false-positive leak reports or minor memory accounting issues during initialization.