rust-lightning

This change improves privacy in Lightning onion messages by adding fake 'dummy hops' to blinded paths by default, making it harder for outside observers to guess how far the real recipient is from the sender. It is a defensive privacy hardening patch, not a fix for an active exploit.

This change makes LDK tell users when alternative splice funding transactions are no longer needed, so they can safely reuse the bitcoin inputs. Previously, after a splice locked in, leftover RBF versions of the splice transaction might not have been reported as discardable, which could leave inputs stuck or accidentally double-spent by the user elsewhere. There is no direct exploit here; it is a correctness and usability fix in a splicing feature still behind a compile-time flag.

This commit fixes a missing signature in the Lightning splicing feature. When a user and their peer splice a channel (replace the old funding transaction with a new one), the old funding output is spent as a shared input in the new transaction. Previously, when the holder produced their tx_signatures message, they left the shared_input_signature field as None, even though the protocol requires them to sign that shared input. The commit adds that signature, renames the signer method to make its purpose clearer, and removes the Result return type because the operation is synchronous. It also adds state checks so funding signatures are only accepted when the channel is actually expecting them, and turns a debug-only assertion about signing failures into a logged warning.

This commit adds support for correctly signing a special kind of Bitcoin transaction input used in Lightning channel 'splicing,' where both parties continue to share an existing funding output while adding or removing funds. Before this change, the code did not know how to build a valid witness (the cryptographic proof that unlocks the shared input) for that shared input. The patch tracks the shared input's position, the order in which the two parties' signatures must appear, and the script that unlocks the funds, then assembles the final transaction witness when both signatures are available. It also adds a small safety check that the transaction ID the caller signed matches the unsigned transaction, to detect malleation.

This commit is purely a code-formatting cleanup. It removes a `#[rustfmt::skip]` directive and lets rustfmt reformat the `validate_update_fee` function. No logic, behavior, or security checks were changed.

This commit is purely a code formatting cleanup. It removes a `#[rustfmt::skip]` annotation and lets rustfmt reformat the `can_accept_incoming_htlc` function in a single file. No logic, behavior, or security checks were changed.

This commit is purely a formatting cleanup. It removes a `#[rustfmt::skip]` directive and lets rustfmt reformat the `can_send_update_fee` function in the Lightning channel code. No logic, behavior, or security checks were changed.

This commit is purely a code formatting cleanup. It removes a `#[rustfmt::skip]` annotation and lets rustfmt reformat the `get_next_commitment_htlcs` function in the Lightning channel code. No logic, behavior, or security properties of the code were changed.

This commit is purely a code formatting cleanup. It removes a `#[rustfmt::skip]` annotation and lets rustfmt reformat the `validate_update_add_htlc` function in the Lightning channel code. No logic, behavior, or security checks were changed.

This commit is purely a formatting cleanup. It removes a `#[rustfmt::skip]` annotation and lets rustfmt reformat a single function. The code logic is unchanged; only whitespace, line breaks, and two local `use` imports were added to make the function easier to read.

This commit is purely a code cleanup: it removes formatting suppression markers (`#[rustfmt::skip]`) from one file and lets the Rust formatter reformat the code. The actual logic, calculations, and behavior of the transaction builder do not change.

This commit adds a new privacy feature to rust-lightning's blinded message paths. It lets callers insert up to 10 fake 'dummy hops' before the real destination, making it harder for outside observers to guess how far apart sender and receiver are or to identify the final recipient. The change is additive: the old constructor still exists and now delegates to the new one with zero dummy hops. There is no obvious security bug in the patch itself.

This commit adds a privacy feature, not a security fix. It introduces a 'DummyTlv' mechanism that lets senders insert fake, empty hops at the end of a blinded onion route. The goal is to make it harder for an outside observer to guess where the real recipient is in the path, similar to adding decoy stops before your real destination. The change is defensive in nature and does not appear to patch an active vulnerability.

This commit adds code to handle 'dummy' hops in onion-routed Lightning messages. Previously, the code had a placeholder TODO noting that dummy hops were not fully supported. The change lets the messenger recognize a Dummy payload, verify its authentication, build the next onion packet, and continue peeling the onion. It also refactors repeated packet-building code into a helper. There is no direct evidence in the commit or supplied references that this fixes an active security vulnerability; it appears to be a feature completion that removes an unhandled edge case.

This commit is a simple rename of a function from get_inbound_payment_key to get_expanded_key, plus updated documentation. It does not change any behavior, logic, or security properties of the code. The change reflects that the same cryptographic key material is now used for more purposes than just inbound payments, such as BOLT 12 Offers and spontaneous payments.

This patch fixes a bug in how error types are used during Bitcoin Lightning channel 'splicing' operations. Splicing lets users add or remove funds from an open channel. Two internal helper functions were returning a 'ChannelError' type, which tells the caller to take specific actions such as warning or closing the channel. But the callers actually convert the result into a normal API error and do not follow those instructions. As a result, a splice that should simply fail with a clear message could instead be misinterpreted as a reason to close the channel or send a protocol warning. The fix changes the helpers to return plain text error strings instead, so the correct failure behavior happens.

This commit fixes a simple but significant logic bug in the code that handles signed funding transactions for Lightning channels. The original code accidentally kept only empty witnesses (filtering for witness.is_empty()) instead of keeping the actual non-empty signatures (filtering for !witness.is_empty()). As a result, when a peer sent valid signatures to finalize a channel, the local node would receive an empty list and likely fail to complete the channel setup or produce an invalid transaction. This could disrupt channel opens and, in the worst case, be used to stall or deny service to a node, but it does not directly steal funds because the signatures themselves are still validated elsewhere.

This commit changes how a Bitcoin Lightning channel signer calculates the value of the old funding output when signing a splice transaction. Instead of accepting the value as a caller-provided argument, it now derives the value from the channel's own stored parameters and adds a check that the transaction input actually matches the expected funding outpoint. This removes an opportunity for a caller to pass a wrong or manipulated input value, which could otherwise cause the signer to produce an invalid or subtly harmful signature.

This commit removes a debug-only assertion that could crash an LDK node in normal, non-buggy situations. The assertion wrongly assumed a certain event could never be queued twice, but it actually can be if a user doesn't immediately handle the event and a channel reconnect happens. The fix makes the code silently skip re-adding the duplicate event instead of panicking. In release builds this would not crash because it was a debug_assert, but in debug/test builds or custom builds with debug assertions enabled it could cause a denial of service (node shutdown).

This change fixes a timing issue in the Lightning Dev Kit where a funding transaction could be signed too early. Previously, the code that decides whether to sign a funding transaction could run both when a channel reconnects and when a pending monitor update finishes. The fix ensures signing only happens after the monitor update has actually completed, preventing a possible invalid or premature signature attempt if a channel reestablish happened while a monitor update was still pending.

This commit fixes a logic bug in the Lightning Dev Kit's channel manager. During startup, when the software replays the state of pending payments, it now assumes a channel is closed unless it finds live peer state proving otherwise. Previously it assumed the channel was open unless proven closed. The change prevents a situation where payments tied to a channel with no peer state would be treated as still active and never re-failed or re-claimed, potentially leaving funds stuck.

This commit fixes a bug in rust-lightning where a Lightning node could permanently lose track of failed payments after a crash. If the node crashed at exactly the wrong moment, it might never report that a payment had failed, leaving funds in limbo and potentially causing the user or downstream nodes to wait forever. The fix makes the node re-check on startup whether any HTLCs (payment contracts) were already resolved as failed on-chain, and if so, properly fail them again in its internal state.

This commit is purely a code cleanup: it removes a `#[rustfmt::skip]` annotation and reformats a helper function, converting a macro into an equivalent closure. There is no functional change to how the software processes payments or channel data.

This patch fixes a startup bug in the Lightning Dev Kit's channel manager. When the software restarts, it scans past payment data to rebuild its list of pending payments and to finalize any that already have a result. Previously, these two steps were mixed together in one loop, which could cause a multi-path payment to be partially rebuilt and then finalized before all paths were seen. This could produce duplicate or contradictory events, such as reporting the same payment as both failed and sent. The fix separates the work into two loops: first rebuild all pending payments, then finalize them. There is no direct security exploit here, but the inconsistent state could confuse downstream software or users.

This commit fixes a bug in rust-lightning where a Lightning node could permanently lose a payment secret (preimage) if the node crashed at an unlucky moment after a channel was force-closed. Losing the preimage means the node cannot claim funds it is owed, effectively losing money. The fix makes the on-chain monitoring component remember preimages it learns from the blockchain, the same way it already remembers preimages learned during normal channel operation, so a restart can recover them even if an in-memory notification was lost.