rust-lightning

This commit fixes a protocol-handling gap for zero-confirmation channel splices in the Lightning Dev Kit. When two peers agree to a splice that does not require waiting for blockchain confirmations, the node now immediately sends a 'splice_locked' message right after exchanging transaction signatures. Previously, this message was only sent after blocks were mined, which could leave a 0-conf splice stuck and unusable. The change is a correctness fix in the Lightning state machine rather than a patch for a remote exploit.

This change lets a user queue a Bitcoin Lightning 'splice' request even when the other party is offline, so it can proceed once they reconnect. Previously the software rejected splice requests while disconnected. The patch also adds clearer logging when the protocol waits for reconnection. It is a feature change, not a fix for an active exploit.

This commit only adds a log message when an interactive funding transaction is broadcast, and refactors three call sites to use a shared helper function. It does not change any security-critical behavior, transaction validation, or network logic. There is no indication of a vulnerability being fixed.

This change fixes a logic bug in the LSPS2 liquidity service of rust-lightning. Previously, when an intercepted HTLC carried a short channel ID (SCID) that the LSPS2 service did not recognize, the handler silently did nothing. Now it returns a clear error so the caller can route the HTLC to another handler or fail it back. The fix prevents HTLCs from getting stuck or being silently dropped when multiple interceptors are active or when old SCIDs overlap with the fake SCID namespace.

This commit only adds a new automated documentation-build check to the project's continuous integration (CI) pipeline. It does not change any production code, cryptographic logic, network handling, or user-facing behavior. There is no security vulnerability here.

This commit is a routine documentation build fix. It swaps one Rust compiler feature flag used only when building documentation on docs.rs (`doc_auto_cfg`) for another (`doc_cfg`) because the old one was removed/merged in the Rust toolchain. It does not change any runtime code, network behavior, or security logic.

This commit changes the numeric identifier (TLV type) used for an optional extra field in a Lightning protocol message called CommitmentSigned. Previously a temporary placeholder number (1001) was used; now it is changed to the final spec-mandated number (1). This is a protocol-correctness update, not a fix for an active security vulnerability. However, because it alters wire serialization, mismatched versions of the software could fail to understand each other's messages, which could in turn affect channel state consistency.

This commit only updates the documentation comments for a function called splice_channel. It does not change any actual code logic. The new docs explain how splicing works, what events are emitted, and how fees are handled. There is no security issue here.

This commit fixes a bug in the Lightning Dev Kit where a wallet reload could silently drop an in-progress channel splice. Previously, if the program restarted while a splice was in an early negotiation state, the user would never receive a 'SpliceFailed' event, so their funds could appear stuck or the failure could go unnoticed. The fix temporarily saves a failure event during persistence so it can be emitted after the reload, then removes it from storage. It is a reliability/notification fix, not a direct theft or remote-exploitation vulnerability.

This change fixes a bookkeeping bug in the Lightning Dev Kit's splicing feature. When a peer disconnects while a splice is being negotiated (but before signatures are exchanged), the software now emits a SpliceFailed event so the user's wallet knows the splice attempt is dead and can unlock any reserved funds. Previously, the internal splice state was reset on disconnect but no event was emitted, which could leave a wallet waiting indefinitely for a splice that would never complete.

This is a small bug fix in a Bitcoin Lightning Network library. After a successful 'splice' operation (a way to resize a payment channel), the software now correctly saves the updated channel state to disk. Before, it skipped saving. The risk is that if the program crashed or restarted right after a splice, it could lose track of the new channel state and potentially behave incorrectly or lose funds.

This commit is a routine internal code cleanup in the Lightning Dev Kit's Rust implementation. It splits one large Rust macro into two smaller ones, with no change to what the code actually does. There is no security issue visible in the change.

This commit is a code cleanup: it pulls out an existing code pattern into a new macro with a clearer name and adds documentation. It does not change behavior or fix a security issue.

This commit is a pure code cleanup: it pulls one specialized branch of a large Rust macro out into its own named macro and updates the three call sites to use the new name. No behavior, logic, or security properties change.

This commit is a small internal code cleanup in the Lightning Dev Kit's Rust implementation. It pulls out a repeated block of code into a new macro named handle_initial_monitor and updates the existing macro accordingly. There is no change to what the code actually does, no bug fix, and no security-relevant behavior change.

This commit is a straightforward internal code cleanup in the Lightning Dev Kit's Rust implementation. It takes a chunk of logic that was duplicated inside a macro and moves it into a normal Rust function. The behavior is intended to be identical; there is no user-facing change or security fix.

This commit changes which experimental 'feature bit' the Lightning Dev Kit software advertises to peers for an unfinished channel-splicing capability. It stops advertising the older production-like bit and starts advertising a prototype bit that was agreed upon with other Lightning implementations. This is a protocol-compatibility and testing change, not a security fix or vulnerability.

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