rust-lightning

This commit is a routine internal cleanup in the Lightning channel code. It removes redundant checks for splice funding transactions now that the data structure already stores the negotiated candidates directly. There is no indication this fixes a security bug or changes security-critical behavior.

This commit is a simple internal rename of a struct field from `pending_funding` to `negotiated_candidates` in the Lightning channel code. It does not change any behavior, logic, or security properties. The change is purely cosmetic to make the code easier to understand before a later refactor.

This is a code-cleanup refactor in a Bitcoin Lightning Network library. It moves a list of not-yet-confirmed funding transactions (pending_funding) from the general channel object into a splice-specific structure (PendingSplice), because that list is only meaningful during a splice. The change is mostly internal reorganization, but it also slightly reorders cleanup steps when a splice is finalized and adds helper methods to access the moved data. There is no direct evidence in the commit that this fixes a known security bug, but refactors around funding-state management can affect correctness of channel funds handling.

This commit removes the saving and loading of a field called pending_funding from a channel's on-disk state. After the change, the field is simply initialized as an empty list when a channel is loaded. The commit message says this data is moving to a different structure (PendingSplice) and will be persisted there later. There is no direct evidence this is a security fix; it appears to be a data-model refactor.

This commit adds a new placeholder field called hold_htlc to the Lightning update_add_htlc message structure. The field is never actually set to a value anywhere in the code; it is always initialized to None. It prepares the codebase for a future feature that lets an often-offline sender ask a forwarding node to hold an HTLC until the recipient comes back online. Because the flag is never enabled, this change by itself does not create a practical security vulnerability.

This commit adds a new Lightning protocol feature flag called HtlcHold to the rust-lightning code, but does not actually turn it on or use it yet. It is preparatory code for a future capability that lets an often-offline sender's payment be held by a counterparty until the recipient comes back online. There is no active security flaw here—just a new feature bit being registered so nodes can later advertise support.

This commit adds an experimental, test-only configuration flag for a new Lightning protocol feature called 'HTLC hold.' When the flag is disabled (the default), the node rejects incoming HTLCs that ask it to hold payments. This is a defensive correctness change to make sure a node does not accidentally promise a service it has not advertised, rather than a fix for an active security bug.

This commit fixes a programming mistake introduced during code cleanup: a function call that tells the channel-handling part of the software about network channel updates had been accidentally deleted. Without it, the channel manager could miss important routing fee and policy updates from peers, potentially causing payment failures or stale routing decisions. The fix simply re-adds the missing call so both the routing and channel handlers receive the update.

This commit is a minor cleanup inside a single test file. It removes unused `let _res =` variable bindings from a Rust unit test for Lightning channel splicing. The functions being called return the unit value `()`, so storing that result in a variable is unnecessary. There is no change to production code, no security fix, and no behavior change.

This commit is a minor code cleanup. It replaces `format!("...")` with `"...".to_owned()` in a few error messages related to splicing in a Lightning network implementation. There is no functional change and no security impact.

This commit removes the 'splicing' feature flag from the rust-lightning project, making splicing-related code always compile instead of being conditionally included. It is a build-system and code-cleanup change, not a security fix. There is no evidence in the commit of a vulnerability being patched.

This change fixes a logic bug in how LDK decides whether a user must sign a splicing transaction. Previously, LDK only checked if the local side had inputs to sign. A 'splice out' adds a local output (money going back to the user) but no local input, so LDK would skip the signing callback and the shared splice input would never get signed. That could leave a splice transaction stuck or incomplete. The patch now also counts local outputs, so splice-outs correctly trigger the signing step.

This commit moves a safety check so that incoming splice requests from a peer are verified for 'quiescence' earlier in the validation process. Quiescence means the channel is in a quiet, stable state before starting a splice. Previously, the check was performed later in an internal code path, leaving a TODO note suggesting it should also be enforced on incoming splice_init messages. The change removes that TODO and adds the check inside the validation function used for incoming splice requests. This is a defensive hardening fix: without it, a peer might be able to initiate a splice while the channel is not quiescent, potentially causing protocol confusion or errors.

This commit fixes a bug in how the Lightning Dev Kit estimates the transaction weight (and thus the required transaction fee) when splicing a channel. Previously, the code estimated the weight of the shared splice input using a generic function based on the previous funding output type, which could produce an incorrect value. The fix explicitly builds the weight from the base input fields, an empty script signature, and the expected multisig witness. If the estimate was too low, the resulting transaction could have paid an insufficient fee and failed to confirm or propagate; if too high, funds could be overpaid as fees. The included test changes show the corrected fee math changes the expected change output amount.

This change updates how the Lightning node cleans up old payment source information when a new commitment transaction is received. Previously, only the active funding scope was pruned; now pending funding scopes are also pruned. The commit message frames this as a cleanup to avoid tracking unnecessary data. There is no direct evidence in the commit that this fixes an exploitable vulnerability, but incomplete cleanup could theoretically lead to stale state or incorrect event generation in multi-funding-scope channels.

This commit is a defensive refactor of how Lightning transaction negotiations are aborted. It makes sure that when either side cancels an interactive funding/splicing negotiation, the internal constructor object is consumed (taken away) so it cannot be reused. It also centralizes the handling of the final 'tx_complete' message so the channel manager calls the channel object only once. The change appears to close a state-handling gap where a failed negotiation might leave stale state behind, but the commit itself does not describe a specific vulnerability or assign a CVE.

This commit fixes an internal bookkeeping issue in a Bitcoin Lightning Network library. After a channel is resized via 'splicing,' the on-chain emergency transaction handler was not being told about the new channel's size and parameters. If a user later ran older software that relied on that handler, it could operate with stale information, potentially creating invalid or uneconomic rescue transactions. There is no direct evidence this is remotely exploitable by an attacker.

This patch fixes a bug where the Lightning node could re-process the same alternative funding transaction more than once. Reprocessing could trigger an internal assertion (a safety check that crashes the program), potentially causing the node to panic and stop running. The fix adds a check to skip the transaction if it was already recorded as confirmed.

This commit changes how certain Bitcoin transactions are versioned inside a specific type of Lightning channel (zero-fee-commitment, or 0FC, channels). For those channels, HTLC-related transactions now use transaction version 3 instead of version 2. Transaction version 3 is a newer standard that helps with network-wide fee management (transaction pinning resistance). The change only affects the transaction version number used when building and signing these transactions; it does not by itself move or expose funds.

This commit fixes how a Lightning node validates signatures from its channel peer for a newer type of channel (0FC, or 'zero-fee commitments'). Previously, the code expected the older SIGHASH_ALL signature type for these channels, which would cause the node to reject valid peer signatures or fail to build valid transactions. The fix makes the code use SIGHASH_SINGLE|SIGHASH_ANYONECANPAY for 0FC channels, matching the protocol design. A mismatch here could prevent correct operation or, in the worst case, be exploited to make a node accept an invalid transaction state, though the commit itself is small and defensive.

This commit is purely a code-formatting cleanup. It removes two `#[rustfmt::skip]` attributes and lets Rust's automatic formatter reformat two functions. No logic, behavior, or security checks were changed.

This commit is a simple rename of a method from `feerate_per_kw()` to `negotiated_feerate_per_kw()` across the codebase, plus an update to its documentation. The goal is to make it clearer that the returned value is the fee rate agreed with the peer, not necessarily the actual fee rate used on-chain. There are no logic changes and no security fix.

This commit changes how Bitcoin transaction fees are handled for a new type of Lightning channel. Instead of each party having their own small 'anchor' output to bump the transaction fee later, the commit creates one shared anchor output. It also switches these zero-fee commitment transactions to use a non-standard version 3. This is part of an ongoing protocol update and does not by itself look like a security bug fix; it is more like feature construction.

This commit adds a single line of code that enables serialization (the ability to convert data into a format that can be stored or transmitted) for a list of BlindedMessagePath objects. It is a routine, additive change with no visible security implications. There is no indication this fixes or introduces a vulnerability.

This commit only changes comments in a test utility file. It clarifies what a test is checking and why it does not perform a certain assertion. No code behavior was changed, so there is no security impact.