rust-lightning

This commit fills in two previously-empty fields in a Lightning channel recovery message. These fields tell each side which funding transaction the other side last confirmed as locked. Setting them correctly helps nodes resume a channel after a disconnect without disagreeing about which funds are active. The change is a follow-up to a prior commit that added the message fields but left them unset.

This commit fixes the order in which two Lightning protocol messages are resent when a channel connection is restored after an outage. The 'commitment_signed' message must now be sent before 'tx_signatures'. Sending them out of order could cause a peer to reject or mishandle the channel re-establishment, potentially disrupting dual-funded channels. It is a protocol correctness fix rather than a clear exploit for theft of funds.

This commit adds support for advertising a new Lightning protocol feature called 'Splicing' in the feature-bit flags that nodes exchange when connecting. It does not implement splicing itself and does not change any security-sensitive logic. It is a routine protocol-compatibility change.

This commit is a code-cleanup refactor in a Bitcoin Lightning Network library. It splits one overloaded channel-state check into three more precise checks so that saving channels to disk, deciding when to broadcast force-close transactions, and emitting 'channel is opening' events no longer rely on a single ambiguous flag. The change appears aimed at preventing subtle bugs in dual-funded channel opening, but the commit itself does not claim to fix a known security vulnerability and no exploit is described.

This change fixes a logic bug in how the Lightning node decides whether to send a 'channel is being force-closed' update to its on-disk channel monitor. Previously, the code used a broad channel-state check that could incorrectly skip sending the update during some interactive funding flows, or send it too early in other cases. The patch replaces that broad check with a precise counter that tracks when the original monitor was first created, ensuring the close update is only generated when a monitor already exists. The practical effect is more reliable recovery of funds during force-closes involving modern interactive channel-opening protocols.

This change fixes a logic bug in how the Lightning node decides whether to accept a 'shutdown' message from a peer. Previously, the code used a broad helper called 'is_pre_funded_state' to skip shutdown handling, but that helper did not correctly cover newer V2-style channels that have negotiated funding but not yet sent the node's own transaction signatures. In those cases, a peer could send shutdown and the node might try to run full shutdown logic (including signing a spending transaction) even though the funding transaction was not actually broadcastable yet. The patch narrows the check to the exact channel states where shutdown should be short-circuited.

This commit only adds new tests and updates an existing test helper. It does not change production code behavior. The tests verify that dummy hops can be inserted into blinded paths and that padded versus compact path formats behave as expected. There is no security fix or vulnerability patch here.

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.