Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.
Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
This commit changes how the Lightning networking code handles oversized encrypted messages. Previously, certain conditions would cause the program to crash with a panic. Now the code returns errors instead, which is a defensive improvement…
panic-to-error conversion for oversized message encryption/decryptiondenial-of-service hardening against oversized peer messagesdebug_assert retained to preserve test coverage of invariant violations
This commit simply updates the 'repository' web links in 15 package metadata files from GitHub to a self-hosted Forgejo instance. It does not change any program code, build logic, dependencies, or security behavior. There is no security is…
This commit fixes a bug in the Lightning Dev Kit where, after a disconnection, a node could fail to retransmit a 'splice_locked' message to a peer that was still waiting for transaction signatures. Without this retransmission, the two peer…
Protocol state desynchronization between channel peers after reconnectionMissing retransmission of splice_locked for 0-conf splice channelsPotential channel unusability or stuck splice negotiation
This commit fixes a small accounting bug in how the Lightning wallet estimates the size (and therefore transaction fee) of a special Bitcoin transaction that sweeps funds back to the user after a channel closes. The old code always assumed…
debug assertion failure possible in development/testing buildstransaction weight/fee estimate overestimation up to 3 WUconstant replaced with per-descriptor length computation
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 …
Documentation-only changeRemoves outdated panic warningAdds retry/unblock guidance for signer errors
This commit changes the project's internal code-review workflow. It stops automatically assigning a human reviewer when a pull request is opened; instead, contributors must manually click a button to request a reviewer after first addressi…
This commit fixes a bug in LDK's Lightning channel reconnection logic after a splice (a way to resize a channel's on-chain funds). If one peer had already received the splice signatures but the other had not, and then they disconnected and…
Protocol-state inconsistency on reconnection after splice signature exchangePotential channel stall/force-close due to quiescence not being exited before commitment updateFuzzer-discovered edge case in Lightning splicing retransmission
This commit adds a new option for Lightning invoice creators to explicitly tell payers not to use multi-path payments (MPP) when paying an invoice. It does not change any enforcement rules; it only changes what feature bits are advertised …
New API surface for feature advertisement controlExplicit documentation that the method does not enforce single-HTLC receipt, shifting enforcement responsibility to callersNo removal or weakening of existing validation logic
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 t…
This commit adjusts the project's continuous integration (CI) test script to pin an older version of a build-time helper crate called `jobserver` when using older Rust compilers. It is a build compatibility fix, not a security patch, and d…
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_adap…
Dependency version bump (esplora-client 0.12 -> 0.13)HTTP backend switch (reqwest -> bitreq) in a transitive dependencyRemoval of MSRV pins for idna_adapter and hyper-rustls
This commit only adds new test code. It exercises how a newer version of LDK exchanges saved channel data with the older LDK 0.2 release when a channel has a pending splice. There is no change to production logic, no bug fix, and no securi…
This commit removes the 'Option' wrapper from several HTLC amount fields, making them required instead of optional. It is a cleanup/refactoring change that simplifies the code by assuming the amount is always known. The commit message fram…
Removal of Option wrapper for financial amount fieldsSerialization format change from optional to required TLV fieldsLoss of backward compatibility with older serialized monitor/channel state
This commit is a code cleanup inside the project's test suite. It replaces a helper function with several hard-to-read positional arguments (like bare `false` and `None`) with a 'builder' pattern that names each option. This makes the test…
This commit is a feature addition, not a vulnerability fix. It extends rust-lightning's BOLT 12 payment support so that when a wallet pays a BOLT 12 invoice, the paid invoice is saved through retries and restarts and is later exposed in th…
New BOLT 12 payer proof feature: persists paid invoice across retries/restarts and exposes it in Event::PaymentSentPayer signing key re-derived from invoice payer metadata rather than storing extra key materialAdds end-to-end test for proof creation, verification, and bech32 round-trip
This commit is a code cleanup (refactor) in the Lightning Dev Kit library. It moves existing payer key-derivation logic into shared helper functions so that future 'payer proof' features can reuse the same code. The change does not appear …
Refactor only: moves existing key derivation/verification logic into helpers without changing algorithmsAdds new public API `Bolt12Invoice::derive_payer_signing_keys` for payer proof key recoveryNo mention of vulnerability, bug, CVE, security fix, or exploit in commit title/message
This commit changes a CI workflow for the rust-lightning project. It stops trying to push new fuzz test inputs directly to a corpus repository from automated test runs, and instead uploads them as a temporary artifact that a separate sched…
This is a routine update to the project's automated reviewer-assignment workflow. It prevents the bot from accidentally adding a second random reviewer when one is already assigned, and adds a manual trigger so maintainers can request an a…
This is a one-line fix to a Forgejo workflow that assigns reviewers. The workflow requests a temporary identity token from the CI system so it can call another service. The change adds an explicit audience parameter to that token request, …
OIDC token audience now explicitly scopedCI workflow authentication hardeningNo change to application code or cryptographic logic
This commit adds partial support in the Lightning Dev Kit node software for receiving and temporarily holding multi-part trampoline payments, then deliberately rejects them once all parts arrive because full outbound forwarding is not yet …
New trampoline forward handling path accumulates MPP parts before rejectingDebug assertion guards first-HTLC failure in MPP mergeTODO comment flags possible MPP inconsistency in next_node_id across trampoline parts
Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
AI review queuedImplement Holder HTLC claim chunking for 0FC channelsby Leo Nash · 4e4a4945 · Oct 28, 2025 · 12 filesMessage 85 · StrongModerate 58Details
Commit message · Leo Nash
Implement Holder HTLC claim chunking for 0FC channels
Otherwise, we could hit the max 10_000vB size limit on V3 transactions (BIP 431 rule 4).
Also introduce a `max_tx_weight` parameter to `select_confirmed_utxos`. This constraint makes sure anchor and HTLC transactions in 0FC channels satisfy the `TRUC_MAX_WEIGHT` and the `TRUC_CHILD_MAX_WEIGHT` maximums.
Expand the coin-selection algorithm provided for any `T: WalletSource` to satisfy this new constraint.
85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Moderate 58/100
This commit fixes a design limitation in Lightning Dev Kit's handling of zero-fee commitment (0FC) channels. In those channels, on-chain transactions must follow Bitcoin's version-3 (TRUC) rules, which impose strict size limits: a parent commitment transaction can be at most 10,000 vB, and its child anchor/HTLC transactions can be at most 1,000 vB. Previously, LDK could try to claim too many HTLCs in a single transaction or select too many wallet inputs for an anchor transaction, producing a transaction that the network would reject. The patch splits large HTLC claims into multiple smaller transactions and teaches the coin-selection algorithm to respect a maximum transaction weight. It also updates the public API for wallet coin selection to accept a new max_tx_weight parameter. This is a correctness/robustness improvement rather than a remote-exploitable vulnerability.
Security candidatePin `proptest` again to fix CIby Elias Rohrer · 9753e6d1 · Oct 28, 2025 · 1 fileMessage 60 · AdequateInformational 15Details
Commit message · Elias Rohrer
Pin `proptest` again to fix CI
.. `proptest` 1.9.0 was just released, now requiring rustc 1.82.
60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
access control
AI analysis · Informational 15/100
This commit adjusts a CI test script to pin an older version of a Rust testing library called proptest, because the newly released version requires a newer Rust compiler than the project supports. It is a build/test infrastructure change with no security relevance.
AI review queuedBump `electrsd` to 0.36.1by Elias Rohrer · 98c83df9 · Oct 28, 2025 · 2 filesMessage 60 · AdequateInformational 15Details
Commit message · Elias Rohrer
Bump `electrsd` to 0.36.1
We bump our `electrsd` dependency to the latest version, allowing us to remove the `home` pin.
60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing or wallet pathsecond-pass: broader security terminologysecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit updates a test-only dependency version and removes a workaround pin for another dependency. It does not change production code, user-facing behavior, or any security-sensitive logic. There is no indication this is a security fix.
AI review queuedDoc and comment fixes from #4167by Matt Corallo · ab218712 · Oct 27, 2025 · 2 filesMessage 76 · AdequateInformational 15Details
Commit message · Matt Corallo
Doc and comment fixes from #4167
This fixes incorrect docs and comments introduced by e95ebf8b9a3d43108176e21c8b4c6bd82f3aaabf and 491b6949fec743e34c74c3a472cf0a2cb83d7ab3
76/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit only fixes documentation comments and a typo in a test-only assertion message. It does not change any executable code, cryptographic logic, or network behavior. There is no security issue here.
AI review queuedAssure BroadcasterInterface packages of len > 1 are child-with-parentsby Leo Nash · 7c9b21fc · Oct 27, 2025 · 3 filesMessage 73 · AdequateLow 33Details
Commit message · Leo Nash
Assure BroadcasterInterface packages of len > 1 are child-with-parents
Implementations MUST NOT assume any topological order on the transactions.
While Bitcoin Core v29+ `submitpackage` RPC allows packages of length 1 to be submitted via `submitpackage`, it still requires any package submitted there to be a `child-with-parents` package.
So we remove the possibility that a batch of transactions passed to a `BroadcasterInterface` implementation contains unrelated transactions, or multiple children.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 33/100
This commit tightens the rules for how Lightning Dev Kit hands groups of Bitcoin transactions to external broadcasting code. Previously, a broadcaster might have received several unrelated transactions or multiple 'child' transactions in one batch, and the documentation only said they 'may or may not' depend on each other. The change guarantees that any batch with more than one transaction is exactly one child transaction plus the parent transactions it depends on. It also updates LDK's own test broadcaster to verify this shape and fixes a test so its fake anchor transaction actually spends the commitment transaction, matching the new guarantee. The main risk is that real broadcaster implementations which relied on the old, looser behavior could have submitted invalid packages to Bitcoin Core's submitpackage RPC, causing broadcasts to fail rather than enabling theft of funds directly.
Security candidateFix `generated_by_local` arg to build commmitment during splicingby Matt Corallo · 0f4e6c22 · Oct 27, 2025 · 1 fileMessage 85 · StrongInformational 18Details
Commit message · Matt Corallo
Fix `generated_by_local` arg to build commmitment during splicing
`build_commitment_transaction`'s fifth argument is supposed to be whether we're the one generating the commitment (i.e. because we're signing rather than validating the commitment). During splicing, this doesn't matter because there should be no async HTLC addition/removal happening so the commitment generated wil be the same in either case, but its still good to pass the correct bool.
85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing boundary
AI analysis · Informational 18/100
A single boolean argument in a function call was corrected during a process called 'splicing' (a way to resize a Lightning channel). The argument tells the code whether the local side is the one creating the commitment transaction. The commit message says this doesn't actually change the resulting transaction during splicing, because no pending payment updates are happening, but it is still correct to pass the right value. There is no clear security vulnerability here.
Security candidateProperly handle funding key rotation during splicesby Matt Corallo · e95ebf8b · Oct 27, 2025 · 7 filesMessage 90 · StrongModerate 60Details
Commit message · Matt Corallo
Properly handle funding key rotation during splices
When splicing, we're required by protocol to retain all the existing keys material except the funding key which we're allowed to rotate. In the original implementation we acknowledged that but figured we'd stick with a single `pubkey` method in the `ChannelSigner` anyway cause adding a specific method for it is annoying.
Sadly, this was ultimately broken - in `FundingScope::for_splice`, we called the signer's `new_pubkeys` method (renamed from `pubkeys` after splicing initially landed), replacing all of the public keys the `Channel` would use rather than just the funding key. This can result in commitment signature mismatches if the signer changes any keys aside from the funding one.
`InMemorySigner` did not do so, however, so we didn't notice the bug. Luckily-ish, in 189b8ac4a7674bbf623f903dcd144c9d1a24a128 we started generating a fresh `remote_key` when splicing (at least when upgrading from 0.1 to 0.2 or when setting `KeysManager` to use v1 `remote_key` derivation). This breaks splicing cause we can't communicate the new `remote_key` to the counterparty during the splicing handshake.
Ultimately this bug is because the API we had didn't communicate to the signer that we weren't allowed to change anything except the funding key, and allowed returning a `ChannelPublicKeys` which would break the channel.
Here we fix this by renaming `new_pubkeys` `pubkeys` again (partially reverting 9d291e01f98417c2f6b2d4321bbf806464c424a6 but keeping the changed requirements that `pubkeys` only be called once) and adding a new `ChannelSigner:new_funding_pubkey` method specifically for splicing.
We also update `channel.rs` to correctly fetch the new funding pubkey before sending `splice_init`, storing it in the `PendingFunding` untl we build a `FundingScope`.
90/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarysigning or wallet path
AI analysis · Moderate 60/100
This commit fixes a bug in how the Lightning Dev Kit (LDK) handles key rotation when splicing a channel. Splicing is a way to resize a Lightning channel on-chain. The protocol only allows changing the 'funding key' during a splice, but LDK was accidentally asking the signer for a whole new set of keys. This could cause signature mismatches and break splicing. The fix adds a dedicated method to rotate only the funding key and keeps all other keys unchanged.
AI review queuedEnforce that `ChanelSigner::pubkeys` is only called onceby Matt Corallo · 491b6949 · Oct 27, 2025 · 1 fileMessage 83 · StrongInformational 17Details
Commit message · Matt Corallo
Enforce that `ChanelSigner::pubkeys` is only called once
In the previous commit we partially reverted 9d291e01f98417c2f6b2d4321bbf806464c424a6 renaming `ChannelSigner::new_pubkeys` to `pubkeys` again, but we still don't want to go back to requiring that `pubkeys` return the same contents on each call. Thus, here, we add test logic to check that `pubkeys` isn't called more than once.
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 17/100
This commit only changes a test helper used during development. It adds an internal guard so that a mock signer in the test suite panics if its public keys are fetched more than once. It does not change production code, network behavior, or wallet security. There is no indication this fixes a real vulnerability.
Security candidateFix panic when deserializing `Duration`by Matt Corallo · 7b9bde12 · Oct 24, 2025 · 1 fileMessage 73 · AdequateHigh 79Details
Commit message · Matt Corallo
Fix panic when deserializing `Duration`
`Duration::new` adds any nanoseconds in excess of a second to the second part. This can overflow, however, panicking. In 0.2 we introduced a few further cases where we store `Duration`s, specifically some when handling network messages.
Sadly, that introduced a remotely-triggerable crash where someone can send us, for example, a malicious blinded path context which can cause us to panic.
Found by the `onion_message` fuzzer
73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
memory safetyfuzzing or regression evidence
AI analysis · High 79/100
This commit fixes a bug where a specially crafted network message could cause the Lightning Dev Kit software to crash. The crash happens while reading a time duration from the message. The fix rejects obviously invalid duration values before they can trigger the crash. The bug was discovered by an automated fuzz tester, not a reported real-world attack.
AI review queuedDrop unused fields from `lightning-transaction-sync` test utilsby Elias Rohrer · 1d11f2d4 · Oct 22, 2025 · 1 fileMessage 60 · AdequateInformational 15Details
Commit message · Elias Rohrer
Drop unused fields from `lightning-transaction-sync` test utils
60/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit removes unused data fields from test-only helper code in the rust-lightning project. It does not change any production code, network behavior, or cryptographic logic. There is no security relevance.
AI review queuedAdd `rust-version` to all crates' `Cargo.toml`sby Elias Rohrer · 165a6b3a · Oct 22, 2025 · 14 filesMessage 45 · ThinInformational 15Details
Commit message · Elias Rohrer
Add `rust-version` to all crates' `Cargo.toml`s
45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit only adds a minimum supported Rust compiler version (1.75) to the package metadata for every crate in the project. It does not change any executable code, fix a bug, or alter runtime behavior. It is a build/tooling metadata change with no direct security relevance.
AI review queuedBump MSRV to rustc 1.75.0by Elias Rohrer · 87c554dd · Oct 22, 2025 · 22 filesMessage 68 · AdequateInformational 20Details
Commit message · Elias Rohrer
Bump MSRV to rustc 1.75.0
We generally align our MSRV with Debian's stable channel. Debian 13 'Trixie' was just released, shipping rustc 1.85. However, as 1.85.0 is only about ~7months old at this point, we opt to bump to the more conservative 1.75.0, which approaches two years of age.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: unusually broad changesecond-pass: security-sensitive path
AI analysis · Informational 20/100
This commit raises the Minimum Supported Rust Version (MSRV) from 1.63.0 to 1.75.0 for the rust-lightning project. It updates CI configuration, documentation, linting rules, and dependency pinning scripts. It also replaces older Rust idioms with newer, cleaner equivalents (such as using div_ceil and is_some_and methods) that require the newer compiler version. There is no security fix or vulnerability being patched here.
AI review queuedCapture stfu send in reconnection testsby Wilmer Paulino · 3c4e70c1 · Oct 14, 2025 · 2 filesMessage 78 · AdequateInformational 15Details
Commit message · Wilmer Paulino
Capture stfu send in reconnection tests
We'll use this in the next commit to test that we'll send a stfu message for a splice we intend to initiate upon reconnecting.
78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit only changes test code. It updates a test helper macro and related reconnection tests to capture and optionally handle 'stfu' messages sent when Lightning channels reconnect. There is no change to production code, so it does not introduce or fix a security vulnerability on its own.
Send 0conf splice_locked upon tx_signatures exchange
Splices negotiated with 0 confirmations require that we immediately lock it after exchanging `tx_signatures`.
65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundary
AI analysis · Low 42/100
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.
AI review queuedReplace docs.rs build `doc_auto_cfg` feature with `doc_cfg`by Matt Corallo · 6aea5865 · Oct 13, 2025 · 10 filesMessage 85 · StrongInformational 15Details
Commit message · Matt Corallo
Replace docs.rs build `doc_auto_cfg` feature with `doc_cfg`
These have been merged, causing our docs.rs builds to fail. Sadly, we saw our docs.rs build fail for the 0.1.6 upload because of this.
85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
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.
Security candidateEmit SpliceFailed upon disconnect while quiescentby Jeffrey Czyz · d10d0002 · Oct 10, 2025 · 3 filesMessage 68 · AdequateLow 32Details
Commit message · Jeffrey Czyz
Emit SpliceFailed upon disconnect while quiescent
Since quiescence is terminated upon disconnection, any outstanding splice negotiation should result in emitting a SpliceFailed event as long as we haven't reached FundingNegotiation::AwaitingSignatures. This may occur if we explicitly disconnect the peer (e.g., when failing to process splice_ack) or if the connection is lost.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundary
AI analysis · Low 32/100
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.
Similarly to when a peer is disconnected, when a node is reloaded any splice that hasn't reaching FundingNegotiation::AwaitingSignatures will be reset. This should produce a SpliceFailed event. However, since other FundingNegotiation variants are not persisted, the data to produced the SpliceFailed event upon reload is lost. Therefore, opportunistically persist a SpliceFailed event for these cases such that it is available upon reload.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundary
AI analysis · Low 32/100
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.
AI review queuedAdd a method to fetch all possible remote-closure `script_pubkey`sby Matt Corallo · e2e0d8a0 · Oct 10, 2025 · 1 fileMessage 73 · AdequateInformational 19Details
Commit message · Matt Corallo
Add a method to fetch all possible remote-closure `script_pubkey`s
In the previous commit we (finally) allowed users to opt into a static `remote_key` derivation scheme, enabling them to scan the chain for funds on counterparty commitment transactions without any state at all.
This is only possible, however, of course, if they have the full list of scripts to scan the chain for, which we expose here.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 19/100
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.
AI review queuedCorrect name of `get_counterparty_payment_script` methodby Matt Corallo · 9dbec804 · Oct 10, 2025 · 3 filesMessage 73 · AdequateInformational 15Details
Commit message · Matt Corallo
Correct name of `get_counterparty_payment_script` method
`get_counterparty_payment_script` fetches the countersigner's (i.e. non-broadcaster) payment script, but that could be ours or or counterparty's. Thus, it should read `get_countersigner_payment_script`, which we fix here.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
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.
Once a splice has been successfully initiated, but prior to signing any negotiated funding transaction, it may fail. Add an event used to indicate this and which UTXOs can be reused.
51/100 · ThinMessage clarity
✓ Subject identifies a change✓ Provides detailed explanatory context
Why it was queued
signing boundary
AI analysis · Informational 17/100
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.
Security candidateAllow `KeysManager` to opt-into the new `remote_key` derivationby Matt Corallo · 189b8ac4 · Oct 9, 2025 · 20 filesMessage 90 · StrongLow 31Details
Commit message · Matt Corallo
Allow `KeysManager` to opt-into the new `remote_key` derivation
The `remote_key` derived by default in `KeysManager` depends on the chanel's `channel_keys_id`, which generally has sufficient entropy that without it the `remote_key` cannot be re-derived. In disaster case where there is no remaining state except the `KeysManager`'s `seed`, this results in lost funds, even if the counterparty force-closes the channel.
Luckily, because of the `static_remote_key` feature, there's no need for this. If the `remote_key` we derive is one of a countable set, we can simply scan the chain for outputs to our `remote_key`s.
Here we finally allow users to opt into the new derivation scheme, using the new derivation scheme for `remote_key`s for new and spliced channels if a new `KeysManager::new` argument is set to `true`.
90/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
Why it was queued
entropy or randomnesssigning or wallet path
AI analysis · Low 31/100
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.
Security candidateAdd support for deriving and signing a new static remote keyby Matt Corallo · 7ff74d5c · Oct 9, 2025 · 6 filesMessage 90 · StrongLow 33Details
Commit message · Matt Corallo
Add support for deriving and signing a new static remote key
The `remote_key` derived by default in `KeysManager` depends on the chanel's `channel_keys_id`, which generally has sufficient entropy that without it the `remote_key` cannot be re-derived. In disaster case where there is no remaining state except the `KeysManager`'s `seed`, this results in lost funds, even if the counterparty force-closes the channel.
Luckily, because of the `static_remote_key` feature, there's no need for this. If the `remote_key` we derive is one of a countable set, we can simply scan the chain for outputs to our `remote_key`s.
Here we set up such new derivation, adding logic to derive one of 1000 possible `remote_key`s (which translates to 2000 potential `script_pubkey`s on chain). We also update the spending code to check which of the two derivation formats where used and sign with the correct key.
90/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
Why it was queued
entropy or randomnesssigning boundarysigning or wallet path
AI analysis · Low 33/100
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.
Security candidateConvert `ChannelSigner::pubkeys` to only fetch *new* pubkeysby Matt Corallo · 9d291e01 · Oct 9, 2025 · 9 filesMessage 90 · StrongInformational 24Details
Commit message · Matt Corallo
Convert `ChannelSigner::pubkeys` to only fetch *new* pubkeys
The `remote_key` derived by default in `KeysManager` depends on the chanel's `channel_keys_id`, which generally has sufficient entropy that without it the `remote_key` cannot be re-derived. In disaster case where there is no remaining state except the `KeysManager`'s `seed`, this results in lost funds, even if the counterparty force-closes the channel.
Luckily, because of the `static_remote_key` feature, there's no need for this. If the `remote_key` we derive is one of a countable set, we can simply scan the chain for outputs to our `remote_key`s.
In the next commit, we'll start using different `remote_key`s based on a config knob the user sets, but with the current `ChannelSigner::pubkeys` API this would be invalid - we can't return a different set of keys for a re-derived `ChannelSigner`. Luckily, this isn't actually how LDK uses `ChannelSigner::pubkeys`, it actually only calls it when it wants a new set of pubkeys, either for a new channel or a splice.
Thus, here, we rename `ChannelSigner::pubkeys` to `ChannelSigner::new_pubkeys` and update documentation to match.
90/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
Why it was queued
entropy or randomnesssigning or wallet path
AI analysis · Informational 24/100
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.
AI review queuedTest channel reestablish during splice lifecycleby Wilmer Paulino · 5594f9b6 · Oct 8, 2025 · 3 filesMessage 70 · AdequateInformational 15Details
Commit message · Wilmer Paulino
Test channel reestablish during splice lifecycle
This test captures all the new spec requirements introduced for a splice to the channel reestablish flow.
70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
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.
Capture announcement signatures resend in reconnection tests
We'll use this in the next commit to test the resend logic for `announcement_signatures` when reestablishing a channel that had a pending splice become locked.
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing boundarysigning or wallet pathboot or update path
AI analysis · Informational 15/100
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.
