Core Lightning

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.

This commit adds internal helper functions for a new 'splice script' feature in Core Lightning. It reorganizes how wallet inputs, outputs, and fees are calculated when splicing a channel. There is no indication in the commit or title that this fixes a security bug; it reads as ordinary feature/refactoring code.

This small code change relaxes a validation rule in the splicing feature of Core Lightning. Previously, the software rejected any splice action that included an `out_ppm` (output parts-per-million fee rate) on the final step. Now it allows `out_ppm` to remain set if the action is the on-chain wallet. The commit says this is to help manage state around dynamic wallets. There is no direct evidence in the commit or supplied references that this fixes a security vulnerability; it appears to be a functional or state-management adjustment.

This commit is a preparatory code change for a future feature. It adds a new field called needed_funds and moves wallet withdrawal amounts into that field, zeroing out the original values so they can be recalculated later. There is no indication in the commit itself that this fixes a security bug or vulnerability.

This is a small bug-fix in Core Lightning's splicing plugin. The code previously always tried to write a debug log array into a JSON response, even when no debug log existed. The patch adds a check so the log array is only emitted when a debug log is actually present. The commit message frames this as a fix for a logging inconsistency when using 'wetlog' without 'debug log'. There is no direct evidence in the commit or diff of a security vulnerability.

This commit fixes a small but meaningful bug in Core Lightning's splicing feature. When two parties jointly resize a Lightning channel via a 'splice,' the plugin was accidentally fetching the wrong fee rate (the one meant for opening ordinary channels, not for splicing). Using the wrong fee rate could make the splice transaction pay too much or too little in network fees, potentially causing the splice to fail, get stuck, or be economically unfavorable. The change simply tells the code to read the dedicated 'splice' fee rate instead of the 'opening' fee rate.

This change relaxes how a special 'quiet mode' request (called STFU, used during channel splicing in the Lightning protocol) is handled. Previously, if the node couldn't enter quiet mode immediately due to pending updates, it would return an error to the caller. Now it remembers the request and enters quiet mode later once those pending updates finish. This is a behavior/policy change, not a clear security fix, but it removes an error path that could potentially be abused to disrupt or probe splicing operations.

This commit only adds new automated tests for an experimental feature called 'splicing,' which lets users resize Lightning payment channels while they are open. It does not change any production code, so it cannot by itself introduce a security vulnerability or fix one. The tests are even marked as expected to fail (xfail) while the feature is being developed.

This commit adds a new helper function that prints millibitcoin amounts as satoshis with a decimal point (for example, 10111 millisatoshis is shown as '10.111sat'). It is purely a logging and display improvement for splicing-related diagnostics. There is no change to how money is handled, validated, or moved.

This commit simply adds a new 'splice' feerate field to the existing feerates RPC response. It exposes information that was already computed internally so users and API consumers can see what fee rate the node recommends for splicing operations. There is no indication of a security vulnerability.

This commit fixes a rare parsing bug in Core Lightning's splice script feature. When a user typed a channel identifier that happened to start with the same characters as a node public key (02 or 03), the software would first try to interpret it as a node ID and reject it before ever checking whether it was actually a valid channel ID. The fix simply reorders those checks so channel ID lookup happens first. The practical effect is mostly that a few unusual channel IDs can now be used correctly in splice commands; it is not a typical security vulnerability.

This commit fixes how the Core Lightning splicing tool interprets a wallet wildcard ('*'). Previously, the '*' value was stored as a special maximum number (UINT32_MAX) and could behave differently than intended. The change forces '*' to mean 'contribute 100% of the funds needed' rather than potentially being misread as a literal huge percentage. This prevents a splice request from accidentally trying to allocate an impossibly large share of funds, which could cause the splice to fail or behave unexpectedly.

This change fixes a minor operational bug in Core Lightning's gossip handling. Previously, when a stale channel announcement arrived after a channel was spliced (a process that spends the original funding output), the software treated it as a warning and reset the peer connection. The patch downgrades this to a simple log/trace message and ignores the stale announcement, which matches the Lightning specification. This is a stability improvement, not a security vulnerability fix.

This commit adds a small helper function that checks whether a signed satoshi value can safely be added to (or subtracted from) a millisatoshi amount without going below zero. It is purely a convenience wrapper around an existing safe arithmetic function and does not change any behavior or fix any bug on its own.

This change adds an early sanity check during a Bitcoin Lightning channel 'splice' operation. It makes the software reject a splice immediately if one party tries to remove more funds than they actually have in the channel, instead of failing later with a confusing error. It is primarily a user-experience and robustness improvement; the underlying limit was already enforced elsewhere.

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 fixes two small memory leaks that occur only when a Bitcoin channel-splicing operation fails. The leaks happen in error-handling paths, not during normal successful operation. There is no indication this can be exploited to attack the node or steal funds; it is a cleanup fix for resource management.

This commit fixes a memory-handling bug in Core Lightning's 'splice' feature when stopping multiple payment channels at the same time. Previously, several related commands shared the same list of channel IDs and results. If that list was resized in memory, the other commands could end up pointing to freed/invalid memory, which can cause crashes or unpredictable behavior. The fix puts those shared lists into a single explicit shared object so every command sees the updated, valid pointer.

This commit removes artificial limits in Core Lightning's experimental splicing feature. It now allows splicing multiple channels at once, using wallet funds dynamically, and calculating fees automatically. These are feature unlocks, not a fix for a known security bug. The change is large in scope and removes safety guards, so it increases the attack surface of a complex feature, but there is no direct evidence it introduces an exploitable vulnerability.

This commit fixes how the Core Lightning 'splice' feature estimates the size (and therefore the fee) of a Bitcoin transaction that combines channel funds with on-chain wallet funds. Previously the estimate could miss a wallet input/output or use the wrong witness-size constant, which could lead to constructing a transaction with an incorrect fee. A bad fee estimate can cause the transaction to be rejected by the network or leave funds stuck.

This commit rewrites the fee and wallet-funding arithmetic for Core Lightning's experimental 'splice script' feature. It introduces a multi-pass solver so that wallet inputs, percentage-based contributions, and on-chain fees can be reconciled when users splice funds into or out of a Lightning channel. The change is large and touches delicate monetary calculations, but it is framed by the author as a feature implementation, not a security fix. There is no disclosed vulnerability or incident tied to this commit.

This commit only changes test files. It updates splicing-related tests to use dynamic fee estimation instead of hardcoded fee rates, removes the `force_feerate=True` flag from splice script tests, fixes a typo in a comment, and splits one large test into smaller named tests. There is no change to production code, so it does not introduce or fix a security vulnerability in the software users run.

This change updates how a Bitcoin Lightning node cancels in-progress channel funding changes ('splices'). When several splices are pending at once, the node now tells its peer exactly which splice is being cancelled, instead of always assuming it is the most recent one. The commit message says this prevents the wrong splice candidate from being aborted when multiple are pending.

This commit only adds and improves log messages in Core Lightning's splicing code. It does not change any security logic, network behavior, or cryptographic checks. The changes help developers diagnose problems by printing more detailed error and debug messages.

This commit updates the Rust bitcoin library used by Core Lightning's Rust crates from version 0.31 to 0.32.2 and bumps the versions of several related crates. It is a routine dependency upgrade for compatibility with other Rust Lightning libraries. The commit message does not describe any security bug or vulnerability being fixed, and the diff shows only version and dependency changes, not code fixes.