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 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 t…
Concurrency/timing change in transaction confirmation logicNew inconsistency check preserved when a previously-confirmed tx is reported unconfirmedAdded defensive error path for missing pre-fetched block status
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 ne…
Avoids unnecessary Electrum transaction.get requests for watched outputsReduces information disclosure to Electrum server about watched outpointsAdds regression test verifying request suppression
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 r…
Previously ignored `script_pubkey` argument in `register_tx` for transaction watchersElectrum script-history queries previously used an arbitrary transaction output, which could be OP_RETURN and therefore unindexed by some Electrum serversNew logic prefers caller-supplied script pubkey and falls back to non-OP_RETURN outputs
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 wort…
Data-loss prevention: previously non-round-trippable event variants are now fully serialized, avoiding accidental event loss when users serialize Event queues themselvesState-consistency hardening: ChannelManager now explicitly skips events that describe non-surviving restart state, preventing replay of stale eventsDefensive assertion: debug builds assert that every persisted event round-trips to Some(event), catching serialization mismatches
This commit only adds documentation comments to two source files. It explains that certain funding-signing events can become stale if the underlying negotiation fails, and that callers may see specific harmless errors as a result. No code …
This commit removes a fixed-version pin for the honggfuzz fuzzing tool in a continuous-integration script. The project now uses the current release of honggfuzz instead of an older pinned version. There is no change to the actual Lightning…
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 is…
This commit makes a previously internal helper function public so that outside developers can build dummy-hop tails for blinded payment paths without recreating the logic themselves. It is an API usability change, not a fix for a known sec…
No security-relevant behavior change in the diffAPI visibility broadened from crate-public to publicCLTV expiry overflow check already present and unchanged
This change adds a safety check in a Bitcoin Lightning Network library (LDK). Previously, if the software tried to verify a peer's commitment signature before it had learned the peer's channel parameters, it could crash with a panic. Now i…
Defensive check added on peer-driven code path to prevent panicMissing counterparty_parameters could previously cause panic during commitment transaction constructionChannel closure returned instead of panic
This commit only changes the wording of an error message sent to peers when a commitment transaction fails validation. It replaces the vague phrase 'Failed to validate our commitment' with the clearer 'Received commitment failed validation…
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 do…
Moved signature validation from channel state machine into signer moduleAdded new tests that corrupt signatures and verify rejectionChanged error message from 'Invalid commitment tx signature from peer' / 'Invalid funding_created signature from peer' to 'Failed to validate our commitment'
This change fixes a Lightning channel splicing bug: when two peers temporarily disconnect during a splice, any half-finished signature the other side already sent is now discarded. Before the fix, that stale signature could be reused after…
State-invalidation bug in multi-step protocol (splice negotiation)Stale cryptographic signature not cleared on disconnectPotential reuse of old commitment state after reconnect
This fix prevents a Lightning channel from being accidentally force-closed. During a splice (a way to resize a payment channel), one side's initial signature could be kept in memory after the peers disconnected. If the peers later reconnec…
State inconsistency: in-memory buffered message not cleared on disconnectDuplicate message processing after reconnectionForce-close consequence for active Lightning channel
This commit is a simple rename of a public function from `matches_invoice_signing_pubkey` to `key_can_sign_invoice`, plus matching updates to its documentation, callers, tests, and changelog. No behavior changed. It is not a security fix.
This commit is a simple rename of a function and its documentation from matches_invoice_signing_pubkey to key_can_sign_invoice. No logic, behavior, or security properties changed. It is a follow-up code-review naming cleanup.
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 existing BOLT 12 invoice-signing-pubkey validation into a reusable helperAdds public API to bind an invoice signing key to an offer recipientAdds unit tests for issuer-id vs. path-last-hop matching behavior
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. …
TLV type-number reservation mechanism extended to more macro-generated code pathsPrevents accidental reuse of retired protocol field type numbersAvoids UnknownRequiredFeature decode failures for obsolete even-type fields
This commit is a test-only cleanup in the Lightning Dev Kit (LDK) Rust codebase. It removes low-level byte-level tests for splice failure events and replaces them with a single cross-version test that actually loads a 0.2 node with seriali…
Cross-version serialization compatibility test addedRemoval of byte-level tests that could not detect real 0.2 mismatchesNo production code changes
This commit only adds a code comment explaining an existing quirk: if a revoked old channel transaction contains two identical-looking payment forwards and the other side claims both, the software may only claim one upstream while letting …
Behavioral quirk in revoked-commitment HTLC resolution documentedDuplicate (payment_hash, amount) HTLCs can map to the same upstream sourcePotential missed upstream preimage claim on second identical HTLC
This commit fixes a state-handling bug in Lightning Dev Kit's splicing feature. When a user tries to speed up or replace a pending splice (an 'RBF' attempt) and the older splice transaction unexpectedly gets confirmed on-chain, the softwar…
State-conflict handling between confirmed splice candidate and active RBF negotiationStructured abort propagation through chain-event pathConditional abort based on holder signature progress to avoid unsafe cancellation
An initial splice `commitment_signed` can be buffered while waiting for the user to provide funding signatures. While this was dropped after a node restart as it's only intended to be live & in-memory state, it was not dropped after a disconnection. This could lead to a duplicate message being received after the negotiation has already completed, leading to a force close.
This was discovered by the `chanmon_consistency` fuzzer via:
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundaryfuzzing or regression evidence
AI analysis · Moderate 58/100
This fix prevents a Lightning channel from being accidentally force-closed. During a splice (a way to resize a payment channel), one side's initial signature could be kept in memory after the peers disconnected. If the peers later reconnected and finished the splice, that old buffered signature could be processed again, triggering a safety shutdown (force close) of the channel. The patch now clears that buffered signature when the connection drops, just like it was already cleared on restart.
Drop comments restating the retired outbound payment TLV
@matt asked on the diff:
> The point of `,retired` is that its self-documenting, no need for a > comment. @auto-pr-bot there's a few of these in this PR, please remove.
The `retired` field type already says the type number is reserved for something a previous version wrote and no longer written, and the commit which retired it records why. Repeating that at each use adds nothing a reader cannot get from the entry itself.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
documentation-only discount
Lower-priorityDrop comment on the read-side TLV type number order checkby auto-pr-bot · 3a7e62f7 · Sep 1, 2026 · 1 fileMessage 81 · StrongTriage 0Details
Commit message · auto-pr-bot
Drop comment on the read-side TLV type number order check
@matt asked on the diff:
> This comment isn't describing the current code, its comparing against > the previous state and the code is trivially obvious. @auto-pr-bot > please remove.
@matt asked on the diff:
> @auto-pr-bot this is documentation, not a code comment, there's no > reason for this.
@matt asked on the diff:
> This comment isn't adding anything that isn't trivially obvious from the > code itself. @auto-pr-bot please remove.
The comment justified the check by contrasting it with the write side's equivalent assertion, which says nothing about the code as it now stands: the `_check_tlv_order!` call it precedes is self-describing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drop comments restating the `retired` TLV macro arms
@matt asked on the diff:
> This comment isn't describing the current code, its comparing against > the previous state and the code is trivially obvious. @auto-pr-bot > please remove.
@matt asked on the diff:
> @auto-pr-bot this is documentation, not a code comment, there's no > reason for this.
@matt asked on the diff:
> This comment isn't adding anything that isn't trivially obvious from the > code itself. @auto-pr-bot please remove.
Both comments describe what the arm immediately below them does rather than anything a reader could not see: one sits on an empty write arm, the other on a single `eat_remaining()` call. The semantics of `retired` belong with the field type's documentation, not repeated at each use.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Lower-priorityMerge PR 'Add a retired TLV field type reserving previously-written type numbers' (#4928)by Matt Corallo · 129515f9 · Sep 1, 2026 · 11 filesMessage 81 · StrongTriage 0Details
Commit message · Matt Corallo
Merge PR 'Add a retired TLV field type reserving previously-written type numbers' (#4928)
from 2026-08-retired-tlv-fieldty into main
Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4928 Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>
81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
merge-commit duplicate discount
Lower-priorityAlways provide funding txn in `ChannelMonitor::get_relevant_txids`by Matt Corallo · d6d3ccb0 · Aug 31, 2026 · 4 filesMessage 73 · AdequateTriage 0Details
Commit message · Matt Corallo
Always provide funding txn in `ChannelMonitor::get_relevant_txids`
`ChannelMonitor`'s `Confirm`-equivalent `get_relevant_txids` API didn't return funding transactions in it, relying instead of the existence of a `ChannelManager` acting as a second `Confirm` in the same instance and providing the funding transaction. `ChannelMonitor` then assumed the funding transaction would be passed to it as well, even though it didn't ask for it.
In most deployments this is actually fine, but we could be deployed with `ChannelMonitor`s without a `ChannelManager` in the same instance. Further, implementations that attempt to reduce sync logic by avoiding replaying transactions that appear in `get_relevant_txids` (which is implied, though not explicit, in the `Confirm` interface) may have issues if a `ChannelMonitor` is not re-persisted after a `ChannelManager` once the funding transaction is confirmed.
Here we fix this by tracking funding transaction confirmation explicitly in `ChannelMonitor`, using that information to return the funding transaction from `get_relevant_txids`. This tracking is also likely to be useful in the future for other reasons.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Security candidateMerge PR 'offers: rename matches_invoice_signing_pubkey to key_can_sign_invoice' (#4942)by Matt Corallo · a476cf92 · Aug 31, 2026 · 3 filesMessage 81 · StrongInformational 20Details
Commit message · Matt Corallo
Merge PR 'offers: rename matches_invoice_signing_pubkey to key_can_sign_invoice' (#4942)
from offer-key-can-sign-invoice into main
Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4942 Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>
81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarysigning or wallet pathmerge-commit duplicate discount
AI analysis · Informational 20/100
This commit is a simple rename of a public function from `matches_invoice_signing_pubkey` to `key_can_sign_invoice`, plus matching updates to its documentation, callers, tests, and changelog. No behavior changed. It is not a security fix.
offers: rename matches_invoice_signing_pubkey to key_can_sign_invoice
Follow-up to #4884 addressing Matt's naming nit.
Co-authored-by: Cursor <cursoragent@cursor.com>
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100
This commit is a simple rename of a function and its documentation from matches_invoice_signing_pubkey to key_can_sign_invoice. No logic, behavior, or security properties changed. It is a follow-up code-review naming cleanup.
Lower-priorityAssert TLV type numbers are unique and increasing when readingby Jeffrey Czyz · c774bef3 · Aug 31, 2026 · 1 fileMessage 85 · StrongTriage 0Details
Commit message · Jeffrey Czyz
Assert TLV type numbers are unique and increasing when reading
A duplicated type number in a field list leaves a dead match arm on the read side: the record is dispatched to the first entry with that number and the second field is never set, so the value is dropped rather than read. Nothing reports this, because the arms are guarded and rustc cannot prove the second one unreachable.
The write path already checks the property with a debug assertion, and for types whose Readable and Writeable come from a single field list that covers both directions. Hand-written implementations pass separate lists to write_tlv_fields! and read_tlv_fields!, though, so a number reused only in the read list is never examined. Run the same check over the read list.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI review queuedMerge PR 'offers: add Offer::permits_invoice_signed_by' (#4884)by Matt Corallo · 016af8f9 · Aug 31, 2026 · 5 filesMessage 81 · StrongInformational 18Details
Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4884 Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>
81/100 · StrongMessage clarity
✓ Specific, 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 pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Informational 18/100
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.
Lower-priorityMerge PR 'Enable `lightning-invoice/std` when `lightning/std` is enabled' (#4941)by Matt Corallo · 20c762f9 · Aug 31, 2026 · 1 fileMessage 81 · StrongTriage 0Details
Commit message · Matt Corallo
Merge PR 'Enable `lightning-invoice/std` when `lightning/std` is enabled' (#4941)
from invoice-reexport into main
Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4941 Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>
81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
merge-commit duplicate discount
Lower-priorityMerge PR 'Say "confirmed" where splice RBF docs meant chain inclusion' (#4936)by Matt Corallo · 9619d3ea · Aug 31, 2026 · 4 filesMessage 81 · StrongTriage 0Details
from bot/4920-fix-cross-version-serialization-b86f35 into main
Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4929 Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>
91/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
merge-commit duplicate discount
Lower-priorityMerge PR 'Make claim_deadline required for PaymentClaimable' (#4935)by Matt Corallo · c90fc4ac · Aug 30, 2026 · 4 filesMessage 81 · StrongTriage 0Details
Commit message · Matt Corallo
Merge PR 'Make claim_deadline required for PaymentClaimable' (#4935)
from ok/claim_deadline_required into main
Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4935 Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>
81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
merge-commit duplicate discount
Lower-priorityMerge PR 'Fold queued splice failures into on_restart_splice_failures' (#4930)by Matt Corallo · 647878d2 · Aug 30, 2026 · 2 filesMessage 81 · StrongTriage 0Details
Commit message · Matt Corallo
Merge PR 'Fold queued splice failures into on_restart_splice_failures' (#4930)
from bot/4918-fail-queued-splice-contributions-27ac3c into main
Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4930 Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>
81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
merge-commit duplicate discount
Lower-priorityMerge PR 'Match renamed RBF-after-confirmation error in fuzz allow-list' (#4940)by Matt Corallo · d8ddc799 · Aug 29, 2026 · 1 fileMessage 91 · StrongTriage 0Details
Commit message · Matt Corallo
Merge PR 'Match renamed RBF-after-confirmation error in fuzz allow-list' (#4940)
from bot/4937-0.3-backport-0.3-prs-waiting-on-5c2e73 into main
Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4940 Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>
91/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
fuzzing or regression evidencemerge-commit duplicate discount