Core Lightning

This commit is a routine cleanup of API documentation and test code. It removes an experimental 'bip86' address type option from the newaddr command and updates tests to use taproot (p2tr) addresses instead of older bech32 addresses. There is no security vulnerability here.

This commit adds a new feature to the Core Lightning 'exposesecret' plugin. It allows users who have set up their node with a BIP39 mnemonic (a human-readable seed phrase) to retrieve that mnemonic through the plugin's API. The change also includes some internal cleanup for how mnemonic secrets are handled and converted into cryptographic seeds. There is no indication in the commit that this fixes a security vulnerability; it is a feature addition.

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 fixes a bug in Core Lightning's HSM (Hardware Security Module daemon) where the wrong private key could be derived when spending a taproot (P2TR) UTXO. Previously, the code always used the older BIP32-style derivation for taproot UTXOs. After the change, it checks whether the UTXO was actually created using the newer BIP86 derivation path (used with mnemonic-based wallets) and, if so, derives the correct key. If the wrong key is used, the node would be unable to sign a transaction spending that UTXO, effectively locking the funds until the bug is fixed. There is no direct evidence in the commit or supplied references that this was a security vulnerability exploitable by an attacker; it appears to be a correctness/functional bug.

This is a preparatory code change for Core Lightning's HSM (the component that holds private keys). It changes an internal function so it can accept either a 32-byte or 64-byte root secret, keeping the existing 32-byte behavior intact. The commit itself does not change how keys are actually derived or fix any known vulnerability; it is plumbing for a future feature (BIP86 wallet addresses).

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 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 is a code refactor in Core Lightning's wallet secret handling. It changes how the HSM (Hardware Security Module-like) secret is stored internally so it can hold either the traditional 32-byte secret or a full 64-byte seed derived from a BIP39 mnemonic. It keeps the old 32-byte field for backward compatibility and adds helper functions to read the secret. There is no security fix or vulnerability being patched here.

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 only updates the user manual documentation for the Core Lightning node software. It renames the documented configuration option from 'encrypted-hsm' to 'hsm-passphrase' and explains how passphrases now work with both old-style encrypted secrets and new BIP39 mnemonic-based seeds. No program code was changed, so this cannot introduce or fix a security vulnerability by itself.

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 changes how Core Lightning's main daemon (lightningd) sends an HSM passphrase to the separate HSM daemon (hsmd). Previously, lightningd derived an encryption key from the passphrase locally and sent that derived key to hsmd. Now it sends the raw passphrase inside a new optional protocol field (a TLV extension), and lets hsmd derive the key itself. The change is framed as preparation for BIP-39 mnemonic support. It is a protocol and internal API change, not a clear-cut security fix, but it does alter where the passphrase is handled and how it travels between processes.

This commit adds support for deriving Bitcoin BIP86-style keys inside Core Lightning's Hardware Security Module (HSM) daemon. It introduces two new wire messages that let authorized clients ask the HSM to derive a BIP86 base key and to check whether a public key matches the HSM's own derivation. The commit also adds a new permission bit controlling access to these messages. There is no direct evidence in the commit that this fixes an active vulnerability; it reads as feature work to support a new wallet/key derivation path, with a sanity-check helper to catch accidental derivation mismatches.

This commit refactors how Core Lightning generates wallet addresses. Instead of keeping two separate address types (legacy BIP32 and mnemonic-based BIP86), it now picks the derivation method based on the wallet's HSM secret type. The change removes the special 'bip86' address type from RPCs and unifies address generation. It also fixes a memory leak by freeing a temporary TLV structure. There is no direct evidence in the commit of a security vulnerability being patched, but the change touches key-derivation logic and could affect fund recoverability if implemented incorrectly.

This commit adds a small metadata field to the internal HSM (Hardware Security Module) initialization message so that lightningd can tell whether the wallet seed was created from a mnemonic phrase or from an older legacy secret. It is a protocol plumbing change, not a fix for a known vulnerability, and does not by itself change how secrets are generated, stored, or protected.

This commit adds experimental support for deriving Bitcoin public keys using the BIP86 standard inside Core Lightning. It stores a new base key locally in the main daemon and adds a command-line option to turn the feature on. The change also removes a dedicated HSM permission flag for BIP86 derivation, folding it into existing capability checks. There is no clear security bug in the diff, but the commit message says much of the code may not survive review, so it looks like unfinished work-in-progress.

This commit fixes a wallet-recovery bug in Core Lightning. When a user restored a wallet that used BIP86 (a modern Bitcoin address type), the node failed to scan the blockchain for those addresses, so previously received funds would appear missing until the user manually generated an address. The patch makes the rescan process look for both BIP32 and BIP86 addresses.

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