Core Lightning

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

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 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 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 fixes a programming bug where Core Lightning could crash because it tried to use a missing piece of data (a NULL pointer) when preparing information about an in-progress channel funding transaction. The fix adds a safety check: if the expected data is missing, it logs a backtrace for debugging and skips that entry instead of crashing. The crash appears to have been triggered during internal testing of a newer feature (splicing), and the patch is defensive rather than a complete fix for why the data might be missing.

This is a code cleanup change that introduces a helper macro to reduce repeated boilerplate when creating hash tables and registering them with the project's memory-leak detection tooling. It does not fix a known security bug, change protocol behavior, or alter access controls. The patch removes many manual memleak-registration calls and replaces them with a single macro that performs allocation, initialization, and registration together.

This patch fixes a crash in Core Lightning that could happen when using the experimental splicing feature on a channel that hasn't been publicly announced yet. The crash was caused by the node still watching the old funding transaction while switching to a new one after a splice. The fix stops watching the old funding transaction before updating to the new one. It is a bug fix for an experimental feature and does not appear to be an exploitable security vulnerability.

This commit fixes a bookkeeping bug in Core Lightning's wallet. When a user broadcast a transaction created with `sendpsbt` that had no change output coming back to the node, the node did not track the transaction's confirmation status. As a result, `listtransactions` would never show the correct `blockheight` for that transaction. The fix makes the node explicitly watch all unconfirmed transactions in its database so their confirmation height gets updated. There is no direct security exploit here; it is a data-correctness and user-experience issue.

This commit only adds a new automated test to the project's test suite. It does not change any production code, so it cannot directly fix or introduce a security vulnerability. The test checks that a wallet transaction created via sendpsbt is correctly tracked from unconfirmed to confirmed status, including after a node restart. It is currently marked as expected to fail (xfail), meaning the underlying behavior may not yet work as intended.

This commit adds '.clangd' to the .gitignore file, which simply tells Git to ignore local configuration files for a C language server used by some developers. It does not change any program code, build process, or security behavior.

This is a trivial formatting fix. When a plugin crashes with a fatal error, the message printed to the terminal was missing a final newline, so multiple error messages could appear squashed together. The change adds that missing newline. It has no security relevance.

This commit adds a new shared helper library for reading and parsing JSON-RPC messages from network sockets. It is purely a code-organization change: it introduces reusable routines and a unit test, but does not change any existing callers or fix any reported bug. There is no indication in the commit message or diff that this is a security patch.

This commit simply moves an existing memory-resizing helper function from two separate source files into a shared utility file so both places can call the same copy. The actual behavior of the code does not change; it is a routine code cleanup (refactoring).

This commit refactors how Core Lightning reads JSON messages from plugins, switching from a custom hand-rolled parser buffer to a shared helper called jsonrpc_io. The change removes a lot of duplicated parsing logic and may fix subtle bugs where the old code could mis-handle partial or large plugin responses. There is no direct evidence in the commit that this fixes a known security vulnerability, but centralizing JSON-RPC input handling is generally a hardening move that reduces the chance of parser-related crashes or misrouting of plugin messages.

This commit removes two unused data fields from the payment-handling code in Core Lightning's plugins. The fields stored a copy of the incoming JSON command buffer and a pointer to its parsed tokens, but nothing in the code actually read them. The commit message notes that keeping the parsed token pointer was especially questionable because the tokens could become invalid after the call. This is a code cleanup with no direct security fix; it eliminates a latent risk of future misuse but does not change any active behavior.

This commit refactors how Core Lightning plugins read JSON-RPC replies when they make synchronous requests to lightningd. It replaces a custom, simpler read-and-parse loop with the same shared JSON-RPC I/O machinery already used for asynchronous requests. The change is described by the author as 'a little overkill, but it's clear'—meaning it is a code-quality/consistency refactor rather than a fix for a known security bug. There is no direct evidence in the commit or supplied references that this resolves an exploitable vulnerability.

This commit is a routine code cleanup. It introduces a shared helper function that copies a JSON buffer and its associated tokens, then replaces two existing hand-rolled copy operations in the JSON-RPC code with that helper. There is no indication of a security fix or behavior change.