rust-lightning

This commit is a simple rename of an internal function from get_counterparty_payment_script to get_countersigner_payment_script, plus an update to its documentation. The old name was misleading because the function actually returns the payment script for the non-broadcaster in a commitment transaction, which can be either party. No behavior of the code changes, and there is no security fix or vulnerability here.

This commit adds a new public helper method that lets users of the Lightning Dev Kit wallet generate a list of Bitcoin addresses (script_pubkeys) where their funds could end up if a channel counterparty force-closes a channel. It is a recovery/scanning feature, not a bug fix or vulnerability. The change also adds a test-only assertion to make sure the generated list actually contains the expected address when signing a counterparty payment.

This commit only adds a new automated test and a CI formatting check. It does not change any production code, fix a bug, or alter behavior. The test verifies that an older Lightning channel using a legacy key derivation can still be properly spent after upgrading to newer LDK code. There is no security issue in this commit itself.

This change fixes a bookkeeping gap in the Lightning Dev Kit: when a channel is shut down while a splice (a special Bitcoin transaction that changes a channel's funding) is still pending, the library now emits a 'SpliceFailed' event. That event tells the wallet/user which coins they contributed to the splice so they can spend them again. Before this fix, those contributed inputs could be silently forgotten, potentially locking up funds until the user manually figured out what happened. It is a reliability/availability fix for user funds, not a remote-exploitable vulnerability.

This commit fixes a missing notification in the Lightning Dev Kit. When a splice operation (a way to resize a Lightning channel) is cancelled by the other party via a tx_abort message, LDK now emits a SpliceFailed event so the user knows what happened and can reclaim any funds they contributed. Previously, the abort was handled silently, which could leave users unaware that their contributed inputs/outputs were no longer tied to a pending splice.

This change improves how the Lightning Dev Kit (LDK) node tells its user when a splice funding negotiation fails during interactive transaction construction. Previously, failures were mostly silent at the application level, meaning users might not know they could reclaim UTXOs they had contributed. Now the node emits a new SpliceFailed event containing the contributed inputs and outputs so wallets can act. It also changes how some protocol errors are handled: unexpected interactive-tx messages now trigger a warning/disconnect instead of being treated as an internal abort. This is a reliability/usability fix rather than a critical remote-exploitable vulnerability.

This commit adds a new notification event called SpliceFailed to the Lightning Dev Kit library. It tells users when a channel splice (a way to resize a Lightning channel) failed before any funding transaction was signed, and lists which bitcoin inputs and outputs can be reused. There is no direct security fix here; it is a user-facing bookkeeping improvement.

This commit adds a new notification event, SplicePending, that tells users when a splice funding transaction has been negotiated and broadcast. It is a feature/visibility improvement rather than a fix for an active security bug. The change helps wallet developers avoid accidentally re-spending splice inputs, but it does not by itself close a vulnerability.

This commit adds a new notification event called SplicePending to the Lightning Dev Kit library. It simply tells users when a splice (a way to resize a Lightning channel) has been negotiated and its funding transaction has been broadcast. There is no security fix or vulnerability here—this is a routine feature addition.

This commit is a preparatory refactor in LDK's key-handling code. It renames a trait method from `pubkeys` to `new_pubkeys` and changes the default signer so it no longer caches a fixed set of holder public keys. The stated goal is to allow future code to return different keys for newly created channels or splices while still being able to sign for any keys ever returned. The commit message explicitly frames this as avoiding a potential fund-loss scenario in disaster recovery, but the actual diff is an API and internal-state change, not a complete fix. It does not by itself introduce or fully patch a vulnerability.

This commit adds an opt-in feature to LDK's key manager that changes how on-chain backup addresses are derived when a channel is force-closed by the other party. The new derivation makes these addresses come from a small, predictable set, so a user who loses all channel state but still has their seed can scan the blockchain and recover funds. Without this, the old derivation required per-channel secrets that might be lost, making funds unrecoverable in a disaster scenario. It is a safety/recovery improvement, not a fix for an active exploit.

This commit changes how a Lightning wallet (LDK) derives one of the keys that receives funds when the other party force-closes a channel. Previously, that key depended on per-channel state, so if a user lost all state except their main seed, they could not recover funds sent to that key. The new derivation uses a small, countable set of keys derived directly from the seed, making recovery possible by scanning the blockchain. The commit also updates the spending code to recognize and sign with either the old or new key format. It is a recovery/usability improvement rather than a fix for an active exploit.

This commit adds a new configuration option called `reject_inbound_splices` to the Lightning Dev Kit (LDK). When enabled (which is the default), a node will refuse incoming requests from other nodes to splice (resize) an existing channel. The commit also changes LDK to publicly advertise support for splicing and quiescence features, rather than only in tests. The stated purpose is to avoid breaking backwards compatibility with older LDK versions while a splice is in progress. It is a defensive, opt-in/out configuration change rather than a fix for an active vulnerability.

This commit changes how an old Bitcoin Lightning wallet library (LDK) loads very old channel backup files called ChannelMonitors. Previously, if a backup was too old, the program would crash on startup. Now, if the backup is old but appears to contain no remaining funds, the program silently skips loading it instead of crashing. This is intended as a safety valve for users with ancient backups, but it also means old backups that might still matter could be ignored if the 'no funds' check is wrong.

This commit only adds a new automated test to the rust-lightning project. It does not change any production code. The test verifies that when a malformed trampoline-style payment onion is received, the node correctly rejects it and fails the payment backward. There is no security fix or vulnerability being introduced here.

This commit only adds a new test case to existing test code. It makes an existing test run twice—once for a successful payment claim and once for a failed payment—so the software's behavior in both situations is checked automatically. No production code was changed, so it cannot directly affect real users or introduce a security vulnerability.

This commit only changes a test file. It simplifies an existing unit test for trampoline payments by replacing a complex, manually-built failing onion with a simpler helper that makes the recipient reject the payment. No production code is modified, so there is no security impact on real users.

This commit fixes a bug in the Lightning Dev Kit where failure messages for trampoline-routed payments were encrypted with the wrong secret. As a result, the original sender could not read error messages when a payment failed inside a trampoline route. The fix makes the code use the trampoline-specific shared secret for encrypting those failure messages, falling back to the phantom secret only when no trampoline secret is available.

This commit only adds new test code for the Lightning channel re-establishment flow during a splice. It does not change production logic, so it introduces no direct security vulnerability. The tests verify that nodes correctly retransmit messages after a disconnect while splicing a channel.

This commit only changes test code in the Lightning Dev Kit Rust repository. It extends the test helper that simulates two Lightning nodes reconnecting after a disconnection so it can now capture and optionally re-send 'announcement_signatures' messages. The change prepares tests for a future commit that will verify re-sending of these messages after a channel splice becomes locked. No production code is modified, so it cannot directly affect real users or introduce a runtime security vulnerability.

This commit fixes a bug in how the Lightning Dev Kit handles interrupted splice negotiations. Previously, if a splice negotiation reached the 'AwaitingSignatures' stage and the connection dropped, the node would incorrectly reset its splice state on reconnection. That prevented the channel from ever resuming the pending splice negotiation via the standard channel_reestablish flow. The fix stops the reset in that specific stage and simplifies the related state-cleanup logic. It is a protocol-correctness fix rather than a direct theft-of-funds vulnerability, but it could cause channels to become stuck or force unnecessary closures.

This commit fixes a protocol-level bug in the Lightning Dev Kit where a node could incorrectly re-send a 'channel_ready' message after reconnecting to a peer during a splice operation. Splicing only happens after both sides have already exchanged 'channel_ready', so retransmitting it again is unnecessary and could confuse the peer or violate protocol expectations. The fix adds checks to skip that retransmission when a splice is in progress or has been started.

This patch fixes a timing issue in Lightning Dev Kit's channel manager. When opening or splicing a dual-funded Lightning channel, LDK could send its transaction signatures too early—before it had received the counterparty's commitment_signed message. Sending signatures prematurely could lead to signing a funding transaction before the necessary security state (the persisted monitor update) is in place, potentially creating a situation where funds are at risk if something goes wrong later. The fix adds a check to wait for the counterparty's commitment_signed before producing the holder's tx_signatures.

This change makes a Lightning channel funding API more forgiving. Previously, if a user already signed a funding transaction and then accidentally called the signing function again—perhaps because the app showed the same request twice after a peer reconnection—the library would return an error. Now it silently returns early instead. This is a robustness fix that prevents harmless duplicate calls from being treated as failures, which could confuse or break wallet software.

This commit fixes a bug in the Lightning Dev Kit's on-chain channel monitor. When the user learned a secret payment proof (preimage) and told the monitor about it, the code was accidentally trying to claim every outstanding payment, including ones that had already been claimed. That produced invalid Bitcoin transactions and could let the other side take money via a timeout if the invalid claim failed. The fix narrows the monitor's behavior so it only tries to claim the specific payment whose proof was just learned.