Core Lightning

This commit fixes a crash-recovery bug in Core Lightning's channel-opening plugin. If the node crashed after receiving a funding PSBT but before signing and broadcasting it, the channel could get stuck in an 'awaiting lock-in' state. On startup, the plugin now scans for such stuck channels, signs the PSBT, and re-sends it so the opening process can continue. The change is defensive and improves reliability rather than introducing a security vulnerability.

This commit adds a new read-only field to two JSON-RPC API responses that exposes the funding PSBT (a Bitcoin transaction planning document) for a channel, if one is stored. It is an informational API enhancement and does not change how transactions are signed, validated, or broadcast. There is no indication in the commit that this fixes a security bug.

This change makes the sendpsbt RPC command smarter: if the transaction being sent matches a PSBT that was promised for a new or spliced Lightning channel, the node now saves the final signed version with that channel so it can re-send it after a restart. It also updates the saved channel PSBT during splice signing. This is a reliability improvement for channel funding and splicing, not a fix for an obvious exploit.

This commit fixes a rare programming bug in Core Lightning's 'askrene' routing plugin. If a specific internal function failed due to an overflow, the code would free a memory context and then try to use it again on the error-handling path, which is a use-after-free. The patch changes the function to use a longer-lived memory context so the error path is safe. The failure condition is described as only possible on overflow, making real-world exploitation unlikely.

This commit fixes a developer-only edge case. When running Core Lightning with a special developer mode flag (CLN_DEV_ENTROPY_SEED) that forces the same randomness seed for testing, multiple channel-opening sub-processes could accidentally pick the same internal IDs. That could cause a PSBT (transaction-building data structure) collision when combining contributions. The fix tweaks the seed slightly for each new sub-process so IDs differ, then restores the original seed afterward. It is not a normal user security bug and does not expose funds or keys.

This commit adds a developer-only feature that lets Core Lightning use predictable fake random numbers instead of real cryptographic randomness when a special environment variable is set. It is intended only for testing and reproducible debugging, not for production use. The code is gated behind developer mode and is not itself a vulnerability, but any accidental use in production would severely weaken security that depends on randomness.

This change only affects Core Lightning when a special developer-only environment variable (CLN_DEV_ENTROPY_SEED) is set. It makes the order in which the wallet picks coins deterministic instead of random, which helps developers reproduce tests. In normal operation the wallet still picks coins randomly, so this commit does not introduce a security vulnerability for regular users.

This change is a straightforward internal cleanup: it replaces direct calls to the cryptographic library's random-byte function (randombytes_buf from libsodium) with a project-specific wrapper called randbytes(). The wrapper currently does the same thing, but having it in one place makes it easier to swap in a deterministic (predictable) random source for testing in the future. There is no direct security bug introduced by this commit itself, and no evidence it weakens real-world randomness.

This commit changes an experimental splicing feature's internal message numbering from 0 to 1 so it matches the official Lightning spec and becomes optional. It is a compatibility/standards-alignment fix, not a direct security patch. Both channel peers must upgrade together or they may fail to understand each other's splice-related messages.

This is a minor cleanup change to a fuzz test file. It replaces hard-coded numbers with named constants and swaps a generic memory-free call for a dedicated key-discard function. There is no security vulnerability here.

This change removes a repeated internal sanity check that was making very large Bitcoin transaction templates (PSBTs with hundreds of inputs) extremely slow to process. It is a performance fix, not a security fix. The remaining single check at the end still catches the same class of problems, just less frequently.

This commit adds a test that checks whether Core Lightning's bitcoin backend plugin (bcli) crashes when handling very large transactions. The test is marked as expected to fail for now, meaning the underlying crash bug is known but not yet fixed. It does not itself change production code.

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