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.
Security candidateAccount for grind_signatures in splice funding txby Jeffrey Czyz · 46980261 · Nov 11, 2025 · 6 filesMessage 68 · AdequateLow 32Details
Commit message · Jeffrey Czyz
Account for grind_signatures in splice funding tx
When estimating the splice funding transaction fees, adjust for grind_signatures. Since LDK supplies one of the signatures, only adjust by 1 WU even though spending the shared input requires two signatures.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 32/100
This commit fixes a fee-estimation bug in LDK's experimental splicing code. When the optional `grind_signatures` feature is enabled, signatures are guaranteed to be one byte smaller than the normal maximum. The splice funding-transaction fee estimator was not accounting for that smaller signature, so it could slightly overestimate fees. The patch subtracts one weight unit from the relevant estimates when the feature is on, and updates tests to match. It is a correctness/efficiency fix rather than a critical vulnerability.
Replace calls to `get_revoke_commit_msgs` macro to the identically-named function.
50/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides an explanatory body
Why it was queued
boot or update path
AI analysis · Informational 15/100
This commit is a simple internal cleanup in the project's test code. It removes a helper macro named `get_revoke_commit_msgs!` and replaces every use with an already-existing function of the same name. There is no change to how the software behaves in production, no fix for a bug, and no security-relevant change.
Security candidateUse `commitment_signed_dance_through_cp_raa` instead of macroby elnosh · 021d503d · Nov 10, 2025 · 4 filesMessage 65 · AdequateInformational 15Details
Commit message · elnosh
Use `commitment_signed_dance_through_cp_raa` instead of macro
Replace calls to `commitment_signed_dance` macro to instead call `commitment_signed_dance_through_cp_raa`.
65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
boot or update path
AI analysis · Informational 15/100
This commit is a small internal cleanup in the project's test code. It replaces a few uses of a test helper macro with a direct call to an equivalent helper function. There is no change to the actual Lightning node logic that runs in production, and nothing in the commit suggests a security fix or vulnerability.
Replace last `commitment_signed_dance` calls with `commitment_signed_dance_return_raa`.
50/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides an explanatory body
Why it was queued
boot or update path
AI analysis · Informational 15/100
This commit is a straightforward internal cleanup in the project's test code. It removes a helper macro used only in tests and replaces its remaining uses with an equivalent regular function. There is no change to the actual Lightning protocol logic, network-facing behavior, or production code, so it does not create or fix a security issue.
Security candidateReplace `commitment_signed_dance` for skip_last_step=trueby elnosh · c1097fdb · Nov 10, 2025 · 15 filesMessage 65 · AdequateInformational 13Details
Commit message · elnosh
Replace `commitment_signed_dance` for skip_last_step=true
Replace calls to `commitment_signed_dance` macro when skip_last_step=true to instead call `do_commitment_signed_dance`.
65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
boot or update path
AI analysis · Informational 13/100
This commit is a test-only refactoring change. It replaces uses of a test helper macro (`commitment_signed_dance!`) with direct calls to an equivalent test helper function (`do_commitment_signed_dance`) in many test files. There is no change to production code, no change to behavior, and no security fix or vulnerability introduced.
Security candidateReplace `commitment_signed_dance` for skip_last_step=falseby elnosh · 80965fa6 · Nov 10, 2025 · 18 filesMessage 73 · AdequateInformational 15Details
Commit message · elnosh
Replace `commitment_signed_dance` for skip_last_step=false
Replace calls to `commitment_signed_dance` macro when skip_last_step=false to instead call `do_commitment_signed_dance`.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
boot or update path
AI analysis · Informational 15/100
This commit is a test-only refactoring change. It replaces uses of a macro called `commitment_signed_dance!` with direct calls to a helper function `do_commitment_signed_dance` in many test files. There is no change to production code, no security fix, and no vulnerability introduced.
Security candidateUse 72 WU instead of 73 WU for signature weightby Jeffrey Czyz · eb341de7 · Nov 10, 2025 · 4 filesMessage 73 · AdequateLow 36Details
Commit message · Jeffrey Czyz
Use 72 WU instead of 73 WU for signature weight
When estimating signature weight, 73 WU was used in some places while 72 WU was used in others. Consistently use 72 WU and replace hardcoded values with constants. 73 WU signatures are non-standard and won't be produced by LDK. Additionally, using 73 WU along with grind_signatures adjustment is nonsensical.
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
signing boundarysigning or wallet path
AI analysis · Low 36/100
This commit fixes an internal inconsistency in how LDK estimates Bitcoin transaction fees. Some parts of the code assumed signatures could be 73 weight units (WU) long, while others used 72 WU. Since 73 WU signatures are non-standard and LDK never produces them, the 73 WU assumption caused fee estimates to be slightly too high. The patch standardizes on 72 WU and replaces magic numbers with named constants. The practical effect is slightly lower, more accurate fee estimates for Lightning channel funding and splicing transactions. It is not a direct vulnerability fix, but incorrect fee estimation could in edge cases cause transactions to be over-funded or, more importantly, could contribute to fee-related negotiation failures.
Allow counterparty tx_abort before handling initial commitment signed
Upon processing the counterparty's initial `commitment_signed` for a splice, we queue a monitor update with the new commitment transactions spending the new funding transaction. Once handled, funding transaction signatures can be exchanged and we must start monitoring the chain for a possible commitment transaction broadcast spending the new funding transaction. Aborting the splice negotiation then would therefore be unsafe, hence why we currently force close in such cases. However, there is no reason to force close prior to receiving their initial `commitment_signed`, as this would imply the funding transaction signatures have yet to be exchanged, thus making a commitment broadcast spending said transaction impossible allowing us to abort the splice negotiation safely.
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 · Low 44/100
This change fixes a Lightning channel splicing behavior where one side would unnecessarily force-close the channel if the counterparty tried to abort a splice before both sides had exchanged their first commitment signatures. Previously, any tx_abort during the signature-waiting phase triggered a force close. The patch makes the protocol more forgiving: aborting is allowed until the counterparty has actually sent its initial commitment_signed, because before that point no dangerous on-chain transaction has been committed to. Once commitment_signed is received, aborting remains unsafe and still triggers a force close. The change also cleans up internal state when aborting early and adds tests for the new behavior.
Security candidateImport `ChannelTransactionParameters` from its real pathby Matt Corallo · b07111e3 · Nov 3, 2025 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Matt Corallo
Import `ChannelTransactionParameters` from its real path
Rather than importing `ChannelTransactionParameters` via the `use` in `lightning::sign`, import it via its real path in `lightning::sign::ecdsa`. This makes reading the code (incredibly marginally) simpler, but also makes the bindings generator happy.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Informational 15/100
This commit is a pure code cleanup: it changes where one internal type, ChannelTransactionParameters, is imported from. There is no functional change, no bug fix, and no security relevance visible in the diff or commit message.
Security candidateRequire the high-level sign traits instead of `SignFn` in bindingsby Matt Corallo · 2bf737ce · Nov 3, 2025 · 1 fileMessage 85 · StrongInformational 15Details
Commit message · Matt Corallo
Require the high-level sign traits instead of `SignFn` in bindings
Methods like `StaticInvoice::sign` have their own signing-function traits, so there's no actual need to use `SignFn` directly, its just a useful generic wrapper. Sadly, because it uses `AsRef` bounds, which aren't really practical to map in bindings, we can't really expose it directly in bindings. Because there's an alternative and its tricky to expose, we simply mark it no-export here.
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 15/100
This commit is a documentation-only change in the Rust Lightning library. It adds a comment explaining that a generic signing helper trait called SignFn is intentionally not exposed to language bindings (for users of other programming languages), because each specific signing method already has its own trait and the generic wrapper is awkward to map across languages. No code behavior changed, and there is no security fix or vulnerability here.
Security candidateAdd draft release notes for 0.2by Matt Corallo · a94f9f8a · Oct 30, 2025 · 12 filesMessage 45 · ThinInformational 15Details
Commit message · Matt Corallo
Add draft release notes for 0.2
45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
authentication pathdocumentation-only discount
AI analysis · Informational 15/100
This commit is purely a documentation update: it drafts the release notes for rust-lightning version 0.2 and removes the corresponding pending changelog snippets. No source code, logic, or configuration changes are made, so it cannot introduce or fix a security vulnerability on its own.
Security candidateAdd missing documentation for sigs-ready event to `splice_channel`by Matt Corallo · 00e06a06 · Oct 30, 2025 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Matt Corallo
Add missing documentation for sigs-ready event to `splice_channel`
`ChannelManager::splice_channel` initiates a splice which ultimately generates a series of events. The most important of which, `FundingTransactionReadyForSigning` (which must always be handled, unlike the others), was not documented.
Here we mention the event generation.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundary
AI analysis · Informational 15/100
This commit only adds a missing documentation comment to the splice_channel function. It explains that a FundingTransactionReadyForSigning event will be generated after signatures are exchanged, and that funding_transaction_signed should then be called. There is no code change, bug fix, or security patch.
`clippy` now complains about more instances of useless `vec!`s, so we drop them here.
60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100
This commit is a routine code cleanup. It replaces unnecessary `vec!` macro calls with plain array literals in test code and internal test modules. There is no functional change, no bug fix, and no security relevance.
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.
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.
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.
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.
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.
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 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 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 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.
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.
