rust-lightning

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.

This commit completes a feature that lets a Lightning node ask its peer to resend 'announcement_signatures' messages during channel reestablishment. These signatures are needed to publicly announce a channel on the network. The change simply adds the logic to honor that request, matching a protocol rule. It is a follow-up implementation patch, not a fix for an active vulnerability.

This commit changes how Lightning nodes request missing announcement signatures after a channel reconnects. It adds a flag to the FundingLocked message so a node can explicitly ask its peer to resend announcement_signatures when needed, rather than relying on the older splice_locked retransmission path. This is a protocol-correctness improvement for splicing; it does not appear to be a direct exploit fix.

This commit updates how the Lightning Dev Kit (LDK) node handles reconnection messages for channels that are in the middle of creating a new funding transaction (a 'splicing' or interactive funding flow). It replaces a simple transaction ID field with a richer structure that also carries flags telling the peer which messages to re-send. The change is a protocol-conformance update for a still-evolving Lightning specification; it does not appear to be a fix for an active security vulnerability, but it prevents possible state mismatches during reconnections.

This patch fixes a Lightning channel bug that could produce an invalid channel announcement after a splice is finalized. When a channel is spliced (its on-chain funds are moved to a new transaction), both sides must exchange fresh announcement signatures before re-announcing the channel to the network. The bug caused the old counterparty signature to be kept briefly after the splice was promoted, so if the node tried to build and send a channel_announcement before the new signature arrived, it would use a stale signature and create an invalid message. The fix simply clears the old signature when the splice is promoted, forcing the node to wait for the new one. There is no direct theft-of-funds path, but it could cause gossip inconsistencies or a peer to send invalid protocol messages.

This commit fixes a protocol-handling bug in LDK's Lightning splicing feature. When two peers reconnect after a splice, the Lightning spec says a 'splice_locked' message can be implied by the other peer's current funding state. LDK previously did not recognize this implied signal, which could leave a splice stuck or cause the channel to behave incorrectly after reconnection. The change detects the implicit splice_locked and processes it normally.

This commit tightens a validation check during Lightning channel reconnection. It removes a special case that allowed a peer to send a zero commitment counter without also providing next_funding data. The change makes the code reject that zero-counter case outright, which is described as safe because the counter should never be zero at this stage. The commit also deletes an incorrect comment that cited a non-existent specification requirement.

This commit fixes a timing issue in the Lightning Dev Kit where a node could send transaction signatures to its peer before its own local safety record (the ChannelMonitor) had been saved. Sending signatures too early could, in edge cases, leave the node in a vulnerable or inconsistent state if something crashed or went wrong before the save completed. The fix simply waits to send signatures until the monitor update is finished.

This patch fixes the order in which Lightning messages are resent when a connection comes back after being dropped. In some channel states, the node was sending 'channel_ready' before the initial signatures it depends on, or after them when it shouldn't. The fix adds a new ordering flag so the correct sequence is used depending on whether the channel is still finalizing its funding transaction or is already operational. A wrong order could confuse a peer and prevent the channel from resuming correctly, potentially causing a denial of service or funds to be stuck.

This commit changes how LDK builds private 'blinded' communication paths so that the creation process can no longer fail in normal use. Previously, a bad random number could cause path creation to return an error. Now the code will panic (crash the program) instead if that happens, matching how LDK already handles broken randomness elsewhere. The change is described by the developers as a cleanup to simplify upcoming async-payments work, not as a fix for an active security bug.

This commit is a straightforward code cleanup with no security impact. It removes repeated construction of the same data structure in one function and replaces it with a single shared variable. The behavior of the program is unchanged.

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's channel manager. It removes repeated code that builds a data structure called HTLCPreviousHopData by replacing those copies with a single helper method. There is no change to user-facing behavior, network protocol handling, or security logic.

This commit adds a new startup-only API method that lets LDK nodes load already-saved channel monitors without rewriting them to disk. It is a performance and reliability improvement, not a security fix, and does not change how normal channel watching works.

This commit tightens the rules for Lightning channel splicing (a way to add or remove funds from an existing channel). It makes sure that after a splice, each side still has enough money left in the channel to meet the required 'channel reserve'—a safety buffer meant to discourage cheating. Before this change, the code did not fully enforce that reserve check when a splice removed funds, which could have let one party drain too much money and leave the channel in a risky state. The patch also cleans up overflow checks and fee handling.

This commit adds a small helper function to include transaction fees when calculating Lightning channel balances. It also makes an existing internal function's code style match the new helper. There is no obvious security bug being fixed; it appears to be a routine code cleanup and convenience addition.

This commit changes an internal function called `for_splice` so it no longer returns an error. Previously, the function could fail and callers used `?` to propagate that failure. Now it always succeeds. The change is small and appears to be a code-cleanup step in the unfinished splicing feature, but the commit message gives no explanation of why the function was made infallible or what error conditions were removed. Without more context, it is unclear whether this removes a safety check that protected against invalid splice parameters.

This commit is a pure code reorganization: it moves the validation logic for a 'splice_ack' message into a new helper function called validate_splice_ack, then makes the existing splice_ack handler call that helper. No behavior changes, no new checks, no security fixes, and no new vulnerabilities are introduced.

This change is a defensive code-quality refactor in a Lightning channel splicing feature. It moves input validation earlier so the function only mutates internal state after all checks pass. The commit message frames this as a hardening measure, but the diff itself does not fix a known exploitable bug or change observable behavior under normal operation.

This commit adds a check in the Lightning Dev Kit's channel code to reject splice attempts where the party initiating the splice contributes zero new funds. Previously, such a zero-contribution splice could be accepted, which may have allowed a peer to trigger invalid or unintended splice state transitions. The fix disconnects the peer with a warning when this happens.