Core Lightning

This commit adds a new read-only RPC command called listnetworkevents to Core Lightning. It lets users query a log of network events such as peer connects, disconnects, failed connects, and pings. The change is purely additive: it exposes existing internal event data through a new API and does not alter how funds, channels, or network connections are handled. There is no indication this fixes a security bug or introduces a vulnerability.

This commit adds database infrastructure to record network events (peer connects, disconnects, failed connects, and pings) in Core Lightning. It creates a new database table, adds functions to save and retrieve those events, and updates test stubs. There is no security fix or vulnerability present in the diff itself; it is a feature/infrastructure change.

This commit only adds test data files (a seed corpus) for a fuzz-testing harness. It does not change any production code, configuration, or documentation. There is no direct security relevance to running Core Lightning nodes.

This commit only adds test data files (a seed corpus) for a fuzz-testing harness that exercises the onion-message handling code. It does not change any production code, configuration, or runtime behavior, so it cannot introduce a security vulnerability or fix one on its own.

This commit adds a new optional override to the internal invoice payment-checking function. It lets the node accept a payment whose amount differs from what the invoice originally stated. The change is purely internal infrastructure: all existing callers pass NULL, so the override is not yet used. There is no direct security bug visible in the diff, but it changes the assumptions around invoice amounts, which could matter for future callers.

This commit adds a new plugin hook capability that lets a plugin override the expected invoice amount when a Lightning payment arrives. It is a deliberate feature, not a bug fix, and the commit message and documentation describe it as useful for accepting smaller payments than originally invoiced. There is no direct evidence this change introduces a vulnerability, but any hook that can override financial validation could be misused if a malicious or buggy plugin is installed.

This commit fixes a packaging bug in Core Lightning's official Docker image. A recent Docker refactoring accidentally left out the SQLite database library (libsqlite3-0) from the final runtime image. Without it, the container likely fails to start or cannot use the default SQLite wallet backend. The patch simply adds the missing library back to the list of packages installed in the final Docker stage. There is no evidence in the commit of a security vulnerability, exploit, or malicious change.

This change makes the Bitcoin Taproot address format (p2tr) the new default when users call the `newaddr` command, instead of the older bech32 format. The old bech32 default is kept as a deprecated option for one release cycle so existing integrations don't break immediately. This is a routine modernization, not a security fix.

This commit only changes test code. It updates how tests request Bitcoin addresses so they explicitly ask for the address type they want (bech32 or taproot/p2tr) instead of relying on a default. There is no change to production wallet or node code, and no security vulnerability is present in the diff.

This commit fixes a crash in Core Lightning's bookkeeper plugin. Under parallel queries, a bookkeeping record could arrive out of order, triggering an internal 'assertion' that immediately killed the plugin. The fix replaces the fatal assertion with a safe early return when an out-of-order race occurs, and removes the 'expected failure' marker from the related test so it now passes.

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