rust-lightning

This commit changes four internal consistency checks in the code that manages Lightning channel funding transactions. Previously these checks only fired during debug/test builds; now they are hard assertions that will crash the node in release builds if violated. The change reflects a belief that these particular inconsistent states could lead to losing money, so it is safer to halt than to continue.

This commit adds a code comment explaining why a consistency check in the Lightning channel monitoring logic uses a debug-only assertion instead of a runtime panic. The change itself is only a comment; it does not alter program behavior. It documents a rare reorganization scenario where the monitor might not yet have seen an alternative funding transaction that got locked in. There is no direct security fix here, but it clarifies an existing defensive coding choice.

This change alters how Lightning anchor channel commitment transactions are broadcast. Previously, if a commitment transaction already paid enough in fees, the software would silently broadcast it without telling the user. Now it always emits a 'bump' event so the user (or a delegated service like an LSP) can see what is happening and decide whether to broadcast. The change is described as a safety improvement: broadcasting a commitment without reserves can make HTLCs unclaimable, so users should be notified and given control.

This commit adds verification of Bitcoin transaction signatures that a user (the 'holder') provides when building a Lightning channel funding transaction. Before this change, the code trusted the holder's supplied witness data more blindly. The new checks ensure the holder's inputs are standard types (P2WPKH, P2WSH, or P2TR), that signatures use the safe SIGHASH_ALL mode, and that P2WPKH and simple Taproot signatures are actually valid. The commit message explicitly warns that without SIGHASH_ALL, 'your funds can be held hostage'—meaning a malicious or buggy counterparty could potentially prevent the transaction from being confirmed or lock up funds.

This commit adds a new event that asks the wallet/user to sign inputs they contributed to a jointly-built Lightning channel funding transaction. It also changes when LDK sends its own signatures so that signatures are only provided after the channel monitor has been safely persisted. The change is a feature addition with safety improvements, not a fix for an active bug or known exploit.

This commit adds the previous transaction output (the 'prev_output', which includes the scriptPubKey and amount) to an internal data structure called NegotiatedTxInput used during interactive transaction construction in Lightning. The commit message says a future change will use this extra data to verify that certain Bitcoin spends are valid and that signatures use the SIGHASH_ALL mode, which helps prevent funds from being frozen or held hostage by a malicious peer. By itself, this patch only stores more data; it does not yet implement the actual security checks.

This commit fixes a parsing bug in rust-lightning's handling of BOLT 12 payment offers. Previously, the library incorrectly accepted offers that began with whitespace characters when the offer string was split across multiple lines using '+' continuation characters. This violated the BOLT 12 specification and could cause rust-lightning to accept malformed offers that other Lightning implementations would reject. The fix adds explicit validation to reject any offer string that starts with whitespace.

This commit adds a single compiler annotation to suppress an unused-code warning for a test-only helper struct. It does not change any runtime behavior, cryptographic logic, or network handling. There is no security relevance.

This commit removes unnecessary uses of the `concat!` macro in test code. The `concat!` macro was being called with only a single string literal, which has no effect. The change is purely cosmetic and only affects unit tests in a serialization utility module. There is no security relevance.

This commit only changes test code. It replaces a few instances of cloning a test value to make a single-element slice with a helper that borrows the value instead. This avoids an unnecessary clone in unit tests and has no effect on the production library or real Lightning node behavior.

This commit only adds Rust compiler annotations to silence false 'unused import' warnings for traits that are actually used inside macros. It does not change any program logic, behavior, or security boundary.

This commit is a code-cleanup change only. It updates Rust lifetime syntax in type signatures to satisfy a new Clippy lint. There is no functional change, no bug fix, and no security impact.

This commit simply updates three dependency version numbers in a package configuration file (Cargo.toml). It bumps electrum-client from 0.23.1 to 0.24.0, electrsd from 0.34.0 to 0.35.0, and corepc-node from 0.7.0 to 0.8.0. There is no code change and no claim in the commit that this fixes a security issue.

This commit changes the project's GitHub Actions build configuration for Windows only. It tells the Rust compiler to use an alternative linker (rust-lld) instead of the default Windows link.exe, because the Windows CI builds were failing to link. There is no change to application code, no user-facing behavior change, and no security relevance in the diff itself.

This commit fixes a reliability issue in the Lightning Dev Kit where a 'payment received' event could be lost if the program restarted at the wrong moment. Previously, the code already protected the 'payment sent' event with a mechanism that blocks certain channel updates until the event is safely handled. This change extends the same protection to the 'payment claimed' (payment received) event, so users' payment records remain accurate even after crashes or restarts. It is a defensive correctness fix rather than a remote exploit.

This commit is a small internal code cleanup. It makes a date/time wrapper type copyable by value instead of requiring an explicit clone, and removes a few now-unnecessary `.clone()` calls. There is no security-relevant change and no user-facing behavior difference.

This commit adds extra identifying information (the counterparty's public node ID) to payment claim events in the Lightning Dev Kit. It is a defensive API improvement, not a fix for an active exploit. The change helps downstream applications reliably identify which channel partner sent a payment, especially in edge cases where channel IDs could overlap. No security vulnerability is directly patched here.

This commit is a code cleanup in the Lightning Dev Kit (LDK). It changes how internal channel tracking identifies channels, moving from using a Bitcoin transaction outpoint (a specific on-chain funding reference) to using a stable channel ID. The commit message frames this as a step toward supporting newer channel types and simplifying the code. There is no direct evidence in the commit or message that this fixes a security vulnerability.

This commit tightens internal data types in the Lightning Dev Kit so that a counterparty node identifier is always required when claiming forwarded payments. It does not add a new security vulnerability; rather, it makes an existing 0.1 upgrade requirement stricter and turns a previously silent edge case into an explicit panic with a downgrade instruction. The change is defensive and reduces the chance of accidental misrouting of HTLC claims.

This change fixes a bug in how the Lightning node decides which commitment transaction to broadcast when a channel has gone through splicing or dual-funded RBF (i.e., the funding transaction was replaced). Previously, the node might broadcast a holder commitment tied to the wrong, no-longer-confirmed funding transaction, which could fail to claim funds or leave them exposed. The patch makes the monitor track which funding transaction is actually confirmed and uses that funding scope when generating the broadcast and related claims. It also cleans up stale claim requests when the active funding changes due to a reorg or replacement.

This commit adds tracking in the Lightning node's channel monitor so that when a renegotiated funding transaction (from a channel splice or a dual-funded RBF) gets confirmed on-chain, the node knows which funding transaction is the real one. Without this, the node might broadcast the wrong commitment transaction during a force-close, potentially losing funds or getting into an inconsistent state. It is a defensive correctness fix, not an obvious remote exploit.

This commit fixes a bug in the Lightning Dev Kit where certain pending forwarded payments could get stuck and not be returned to the sender if a channel closed at exactly the wrong moment. Normally, stuck payments are automatically failed back, but a specific edge case involving a delayed channel-monitor update caused the software to lose track of them. The fix detects these stranded payments during channel closure and immediately fails them back so funds are not left in limbo.