Core Lightning

This commit adds a new internal building block that lets Core Lightning watch for blockchain reorganizations and track how many blocks have been added on top of a specific block height. It is purely a new infrastructure feature; there is no bug fix, no reported vulnerability, and no user-facing change described.

This change prevents Core Lightning from registering the same blockchain watch twice. Duplicate watches could cause the same callback to fire multiple times, which during splicing (a way to resize a Lightning channel) after a restart could confuse internal bookkeeping. The patch makes the watch functions return false when an identical watch already exists and removes an unused memory-handling marker from the unwatch function.

This commit is a straightforward code cleanup: it takes the existing logic that handles the special case where a funding transaction's confirmation depth drops to zero (a blockchain reorganization) and moves it into its own named function. No behavior changes are visible in the diff. The commit message frames this as preparation for future work, not as a security fix.

This commit removes an unused internal transaction filter called txfilter. The code that added wallet addresses and public keys to this filter is deleted because nothing was actually using the filter anymore. There is no indication in the commit that this fixes a security bug; it appears to be ordinary code cleanup.

This is a small internal code cleanup in Core Lightning. A wallet helper function that scans transactions for outputs belonging to the node is changed from returning a count of found outputs to returning a simple yes/no answer, with an optional list of output numbers. Callers are updated to use the new yes/no style. Nothing in the commit message or diff suggests a security bug is being fixed.

This commit adds a new internal mechanism for Core Lightning to watch for Bitcoin transactions that pay to specific addresses (scriptpubkeys). It is a feature/refactoring change intended to support future funding and splicing workflows. There is no direct evidence in the commit that it fixes an active security bug, but it changes how the node detects incoming funds and includes a small logging improvement to help diagnose mismatched transactions.

This is a small internal code cleanup in Core Lightning. A function that builds a channel identifier (short_channel_id) used to look up a transaction's block position itself; now its callers look up that position and pass it in. The commit message frames this as preparation for a future change, not as a security fix. There is no indication of a vulnerability being patched.

This commit is a routine code cleanup: it moves a small helper structure and its hash/equality functions from the wallet module to the more general Bitcoin module so other code can reuse them. It also updates many test files to provide a stub for a hash-seed function and removes an unused header include. There is no security fix or vulnerability here.

This change refactors a helper function that turns Bitcoin scriptPubKeys into human-readable addresses. Previously the function measured the length itself using a memory-tracking helper (tal_bytelen). Now callers pass the length explicitly. This is mostly a code-cleanup to support data that isn't tracked by that helper, such as internal libwally transaction buffers. There is no direct security bug being fixed, but the old pattern could theoretically lead to incorrect length handling if a non-tal buffer were passed in future code.

This commit refactors how Core Lightning tracks the confirmation depth of a channel's funding transaction. Instead of watching a specific transaction ID, it now watches the block height at which the funding transaction was found. The change is described by the author as making the code more explicit and better suited to external blockchain watchers. There is no direct evidence in the commit that this fixes a security vulnerability, but it does touch reorganization handling and could affect how the node reacts when a funding transaction is removed from the blockchain.

This change refactors how Core Lightning watches for dual-funded channel opening transactions. Instead of watching for a specific transaction ID, it now watches for any transaction that spends to a specific 2-of-2 multisig script (the funding script). This is a robustness improvement that helps handle cases where the funding transaction might be replaced or malleated before confirmation, but the commit message frames it as a design change rather than a security fix.

This change rewrites how Core Lightning watches for splice-inflight funding transactions. Previously it watched for a specific transaction ID. Now it watches for any transaction that creates an output matching the expected 2-of-2 multisig script (scriptpubkey) and then tracks how deeply that block is buried. The intent appears to be robustness—so a splice still works even if the funding transaction ID changes before confirmation—but the change also removes some defensive error handling and replaces it with an abort() and a new reorg callback. There is no explicit security claim in the commit, and no external advisory is supplied.

This is a small internal cleanup change in Core Lightning. It stores a channel identifier (short_channel_id) in memory as soon as a splicing transaction is mined, instead of looking it up from the database every time it is needed. It also removes an unused database helper function. There is no obvious security vulnerability here; it is primarily a code-quality and efficiency improvement.

This commit fixes a type mismatch in a Core Lightning function that watches for splice transactions reaching enough confirmations. The function was accidentally being passed a channel object instead of an inflight object, so the watcher never worked correctly and was effectively dead code. The fix removes the broken watcher entirely. There is no direct evidence this is exploitable for theft or denial of service, but it does clean up a real bug in how splice transactions are monitored.

This change adds safety locks around hash table loops in Core Lightning so the code cannot accidentally insert new entries while it is still walking through the same table. It also removes some old 'rerun' work-arounds that were meant to cope with entries being skipped during deletion. The patch is a hardening fix: it makes the daemon more robust against internal corruption or crashes caused by modifying a hash table while iterating over it, but it does not by itself add or remove any user-facing feature.

This change adds an explicit cleanup step that tells the node to stop monitoring the funding transaction once a channel is finally closed. The commit message says this is not strictly needed today because an existing destructor already handles it, but it will matter in a future refactor. There is no direct evidence this fixes an exploitable security bug.

This change alters how Core Lightning first detects a channel's funding transaction on the Bitcoin blockchain. Previously it looked for an exact transaction ID; now it watches for any transaction that pays to the channel's expected 2-of-2 multisig script. The commit message frames this as a refactor of the three existing cases handled by the funding-depth callback, not as a security fix. There is no direct evidence in the diff of a vulnerability being patched, but the change could reduce sensitivity to transaction malleability or to cases where the funding transaction ID is not yet known.

This commit only adds documentation and a JSON schema for an existing 'spliceout' command. No code behavior changes, no bug fixes, and no security-related changes are present.

This commit adds a new user-facing command called 'spliceout' that makes it simpler to remove funds from a Lightning channel via splicing. It is a feature addition built on top of an existing splicing framework and does not appear to fix any security issue.

This commit only adds a new Python client helper and automated tests for an existing 'splice out' Lightning feature. There is no change to the daemon's security-critical code, no bug fix, and no indication of a vulnerability.

This commit only adds documentation for an existing RPC command called splicein. It does not change any executable code, cryptographic logic, network handling, or wallet behavior. There is no security issue here.

This commit only adds a new test for an existing feature and a small Python helper to call that feature. There is no change to the actual Core Lightning server code that handles money or network messages, so it does not create or fix a security issue.

This commit adds a new user-facing command called 'splicein' to Core Lightning. It is a convenience wrapper around the existing experimental 'dev-splice' feature, letting users splice additional funds into an existing Lightning channel with a simpler command. The change is purely additive and does not appear to fix any security issue.

This commit is a routine code refactor in Core Lightning's splicing plugin. It adds a new 'PENDING' state label for tracking wallet funding situations, moves a debug-logging helper function earlier in the source file, and improves the debug log output. There is no indication of a security fix or vulnerability.

This commit changes how Core Lightning sets transaction fees for 'splice' operations, which are a way to resize a Lightning channel while it is still open. Previously, splicing used the same fee rate as opening a new channel. The patch introduces a separate 'splice' fee rate and, for the party that opened the channel, adds a small configurable buffer to reduce disagreements with the peer. The change is a refinement of fee policy rather than a clear-cut security fix; it could reduce the chance of a splice transaction getting stuck or rejected, but it does not by itself fix a known exploitable bug.