rust-lightning

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

This commit only adds diagnostic log messages to the existing offers/payment flow. It does not change any security checks, validation rules, or behavior. The code still rejects oversized recipient IDs, expired invoices, and failed path creation exactly as before; it now just records why those rejections happened. There is no indication this fixes a vulnerability or introduces one.

This commit changes the Rust type requirements for the logger used by the ChannelManager so that the logger must implement the Clone trait. This is a compile-time API change, not a fix for an exploitable runtime bug. It may break downstream code that passes a logger that cannot be cloned, but it does not introduce or patch a security vulnerability on its own.

This tiny code change fixes how rust-lightning calculates which local commitment transaction number to report during Lightning channel re-establishment. The old code used an upcoming ('next') transaction number and subtracted an extra 1, which could produce an off-by-one value. If that value is wrong, a peer could be told we are on a different commitment number than we actually are, potentially causing a force-close or state mismatch during channel recovery. The fix uses the current transaction number directly.