rust-lightning

This commit rewrites how a Lightning wallet talks to Esplora block-explorer servers so that many status checks happen in parallel instead of one at a time. It is a performance/refactoring change. There is no direct evidence in the commit that it fixes a security vulnerability, but it does add a small amount of new error-handling logic and changes timing/ordering assumptions that could affect correctness if the server returns inconsistent data.

This change stops the Electrum-based transaction sync client from downloading the very transaction that created an output it is watching. Previously, the client could request that transaction from Electrum, even though a transaction can never spend its own output. This wasted bandwidth and could leak slightly more information to the Electrum server than necessary. The patch adds a simple skip and a test that verifies no such download happens.

This change improves how the Lightning Dev Kit's Electrum and Esplora transaction-sync clients track watched Bitcoin transactions. Previously, the code ignored the script pubkey (the 'address' associated with a transaction) supplied when registering a transaction, and instead picked an arbitrary output from the transaction when querying Electrum servers. The patch now records and prefers the script pubkey(s) the caller actually registered, falling back to an arbitrary non-OP_RETURN output only when needed. This makes the wallet more robust against Electrum servers that may not index certain script types (like OP_RETURN), and against callers that register a transaction with an incorrect script pubkey. It is a hardening fix rather than a clear-cut vulnerability patch, because the commit message and diff do not describe a specific exploitable bug.

This commit changes how LDK stores pending event notifications. It adds serialization support for several event types that previously were not fully saved to disk, and introduces a helper method so the code can decide which events are worth keeping across restarts. The commit is a defensive correctness improvement: it makes event persistence more consistent and prevents stale or meaningless events from being replayed after a node restarts. It does not appear to fix an active exploit, but it removes a class of bugs where an event could be silently lost or mishandled around restarts.

This commit changes the Rust toolchain used in the continuous integration (CI) fuzzing job from a fixed older version (1.75) to the latest stable release. It is purely a build/test infrastructure change to fix a dependency compatibility issue with the honggfuzz fuzzing tool. It does not change any shipped code, user-facing behavior, or security-sensitive logic.

This commit moves the checks that validate a counterparty's signatures on the holder's commitment and HTLC transactions out of the general channel code and into the signer module (InMemorySigner). Previously, these signature checks were done directly inside the channel state machine. Now, the signer itself is responsible for verifying those signatures. This is a security-relevant refactor: it makes the signer the authoritative place for validating signatures, which is important for users running LDK with external or hardware signers. The commit also adds tests that corrupt signatures to ensure invalid signatures are rejected. There is no direct evidence in the commit message or diff that this fixes a known exploitable vulnerability, but it strengthens the architecture so that custom signers cannot accidentally skip these checks.

This commit adds a new public helper method, Offer::matches_invoice_signed_by (later renamed matches_invoice_signing_pubkey), that lets callers check whether an invoice signing key belongs to the recipient named by a BOLT 12 offer. It also refactors an existing internal validation function to reuse the same logic. There is no direct bug fix or security patch in the diff; it is an API addition with tests and a changelog entry.

This commit is a feature enhancement for LDK's internal serialization macros. It allows developers to mark old protocol fields as 'retired' (reserved but no longer used) in more places, so those type numbers cannot be accidentally reused. The change itself is not a security bug fix; it is infrastructure that makes it easier to safely reserve obsolete TLV type numbers. There is no direct exploit here, but it helps prevent future protocol-versioning mistakes.

This commit is a performance improvement, not a security fix. It speeds up how rust-lightning asks an Esplora server about transaction and block status by running many requests at once instead of one at a time. The change also removes a duplicate check and deduplicates repeated block-status lookups. There is no indication in the commit that it fixes a vulnerability or that the old code was unsafe.

This commit adds a brand-new, optional crate called lightning-payer-proof to the rust-lightning workspace. It provides a public library (and separate UniFFI bindings) for verifying BOLT 12 'payer proofs' — cryptographic receipts that a Lightning payment was made. The change is purely additive: it introduces new code, test vectors, CI build entries, and workspace membership. There is no patch to existing logic and nothing in the commit message or diff indicates a security bug was fixed.

This change tightens how Lightning payment limits are calculated when transaction fees are high. Previously, the code could allow a non-dust HTLC (a payment large enough to normally appear on-chain) to be offered even when the combined dust-exposure risk pushed the channel past its safety limit. The patch lowers the allowed outbound amount by one millisatoshi in that edge case so the HTLC is treated as dust and rejected, preventing a situation where a miner-fee spike could make an HTLC uneconomical to claim on-chain. The practical effect is a small, defensive correction to fee-based channel safety logic.

This commit only updates an internal code comment to match the current API names. No code behavior changes, no security relevance.

This commit only edits the project's CHANGELOG text. It corrects earlier release notes: one panic issue actually involved 'onion messages' (not HTLCs), and an older 0.1 release was not actually vulnerable to a reorg-related panic because it lacked the relevant code. No code behavior changes.

This commit adds release notes for rust-lightning version 0.1.12, describing several security fixes. The most serious is an on-chain funds-theft vulnerability for nodes that forward Lightning payments through channels opened by untrusted peers. Other fixes address denial-of-service crashes, including cases involving invalid onion message reply paths, oversized protocol messages, reorgs during on-chain HTLC claims, and peer flooding of channel-open requests. The release notes credit Project Loupe and Kyle W. Santiago for reporting the security issues.

This patch fixes a crash bug in the Lightning Dev Kit's handling of HTLC failure messages. A downstream peer could send a maximally-sized failure message without attribution data. When the node added its own attribution data while relaying the failure, the resulting message became too large to fit within the Lightning Network's wire protocol limit, causing a panic during encryption. The fix drops the attribution data when adding it would exceed the limit, and adds a regression test.

This commit fixes a denial-of-service bug in rust-lightning where a maliciously crafted one-hop blinded reply path could cause the node to panic when it tried to respond. The fix rejects paths with too few hops before advancing them, and adds a regression test to confirm no panic occurs.

This commit fixes a bug where replaying the current blockchain block through a normal listener callback could crash two core Lightning components (ChannelManager and OutputSweeper) with a panic. The fix recognizes a same-block replay as a 'rescan,' processes any extra transaction data it carries, and avoids updating the already-current best block. It is a denial-of-service/crash bug triggered by valid, chain-ordered behavior from upstream block sources, not by malformed data.

This commit fixes a crash bug in the Lightning Dev Kit's on-chain transaction handler. During a deep blockchain reorganization, a previously settled HTLC claim could be 'resurrected' at a block height where it could no longer be combined with a surviving claim. The old code used an assertion that assumed merging would always succeed, so the node would panic and shut down. The fix checks whether merging is possible first; if not, it preserves the resurrected claim so it can be broadcast independently. A regression test reproduces the exact reorg scenario.

This commit only updates documentation comments for a Rust function called get_per_commitment_point. It removes an outdated warning that the method was non-asynchronous and that returning an error could cause a crash, and replaces it with guidance that errors can signal a temporarily unavailable signer and how to retry. No actual code logic was changed, so there is no direct security vulnerability introduced or fixed by this patch itself.

This commit is a small internal code cleanup in the Lightning Dev Kit's Trampoline routing code. It removes a separate 'BlindedTrampolineEntrypoint' payload variant and folds an optional blinding point into the existing 'Forward' variant. The change simplifies the code but does not appear to fix a security bug or change wire behavior in a way that introduces vulnerability. It is a refactor, not a security patch.

This commit is purely a code-formatting cleanup. It removes `#[rustfmt::skip]` annotations and lets rustfmt reformat several functions in the routing/scoring module. No logic, behavior, or security properties of the code are changed.

This commit swaps the ID number used by an automated workflow that randomly assigns code reviewers. The old number pointed to a real person's account, so the workflow's assignments appeared to come from that person. The new number points to a dedicated bot account. There is no security vulnerability here—just a cosmetic/accounting cleanup in project automation.

This commit removes a separate CI build step that tested the project with a special 'taproot' compiler flag. It is a workflow cleanup change, not a code change. There is no indication of a security vulnerability.

This commit updates a dependency used to talk to Esplora blockchain servers from version 0.12 to 0.13, switching the underlying HTTP library from reqwest to bitreq. It also removes two CI workarounds that pinned older versions of idna_adapter and hyper-rustls to keep older Rust compiler (MSRV) builds working. The stated purpose is to fix MSRV builds, not to fix a security vulnerability. There is no direct evidence in the commit or supplied references that this change addresses an exploitable security issue.

This change only affects an internal fuzz-testing harness, not production code. It makes the test harness crash with a clear error message if it encounters a ChannelMonitor event it doesn't know how to handle, instead of silently ignoring it. This helps fuzz tests catch unexpected behavior but does not create a security vulnerability in real Lightning nodes.