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
Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/5014 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
When a counterparty's on-chain preimage claim of an HTLC first confirms, the `ChannelMonitor` records both an `OnchainEventEntry` to monitor for the claim's anti-reorg safety and a `MonitorEvent` to surface to the `ChannelManager` for the claim.
If this on-chain claim was reorged out and then reconfirmed before the manager had a chance to process the monitor event, prior to this patch the monitor would drop the on-chain event entry when it saw the reorg and then fail to re-add it when the claim re-confirmed on chain, causing a phantom `Balance` for the HTLC to stay forever and prevent the monitor from being archived.
Here we stop gating the `OnchainEventEntry` queueing on whether a monitor event is already present for the claim, ensuring a new entry will be pushed when the reorged claim re-confirms.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Claim HTLC when preimage appears after queued fail-back
When a forwarded HTLC's downstream channel is on chain and the upstream HTLC is about to expire, ChannelMonitor queues a failure of the HTLC upstream to avoid the upstream channel force-closing.
If the downstream counterparty then claims the HTLC on chain with the preimage before the ChannelManager has picked up that queued failure, we should drop the queued failure and queue success instead. Prior to this patch, we would instead ignore the late success claim and fail the HTLC backwards.
Co-Authored-By: Claude Fable 5.1 <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
Regenerate the unicode category tables from UnicodeData 18.0.0
@matt asked:
> @auto-pr-bot please fix.
The nightly `check_unicode` workflow regenerates `lightning-types/src/unicode.rs` from the latest published `UnicodeData.txt` and files an issue when the result differs from what is committed. It has been failing since Unicode 18.0.0 was published, so the tables were still those of 17.0.0, the version they were originally generated from.
Only the `Cn` (Unassigned) table moves: 18.0.0 assigns codepoints that `PrintableString` was therefore still replacing with U+FFFD, and unassigns none. The `Cc`/`Cf`/`Cs`/`Co` and `Zl`/`Zp` tables come out byte-identical, so no previously-printable character starts being filtered.
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 'Emit SpliceNegotiationFailed for pending negotiation upon force closing' (#4988)by Matt Corallo · 64db7eeb · Sep 16, 2026 · 4 filesMessage 81 · StrongTriage 0Details
Commit message · Matt Corallo
Merge PR 'Emit SpliceNegotiationFailed for pending negotiation upon force closing' (#4988)
from missing-splice-failed-force-close into main
Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4988 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-priorityExpose what a contribution reserved for itselfby Jeffrey Czyz · 31af7812 · Sep 15, 2026 · 7 filesMessage 68 · AdequateTriage 0Details
Commit message · Jeffrey Czyz
Expose what a contribution reserved for itself
A wallet retrying a failed splice contribution must reserve again the inputs and outputs the failure released. The `DiscardFunding` event that released them is handled by the wallet, while the retry is decided by whoever handles `SpliceNegotiationFailed`, and that event exposed only the full contribution, inherited parts included. So the retry handler could not tell which parts to reserve.
`FundingContribution::reserved_inputs` and `reserved_outputs` return the parts the contribution reserved for itself, which are exactly what a failure releases. They live on the contribution rather than on `FailedSpliceContribution`, so they remain once that type is replaced by the contribution itself when downgrading to 0.2 is no longer supported.
Co-Authored-By: Claude <noreply@anthropic.com>
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityMerge PR 'Clean up the transient-event serialization nits from #4791' (#4996)by Matt Corallo · be7232f1 · Sep 15, 2026 · 5 filesMessage 81 · StrongTriage 0Details
Commit message · Matt Corallo
Merge PR 'Clean up the transient-event serialization nits from #4791' (#4996)
from bot/4791-serialize-transient-event-varian-9095a3 into main
Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4996 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
AI review queuedMerge PR 'tx-sync: Parallelize esplora status queries' (#4913)by Matt Corallo · c303f515 · Sep 15, 2026 · 1 fileMessage 81 · StrongInformational 19Details
Commit message · Matt Corallo
Merge PR 'tx-sync: Parallelize esplora status queries' (#4913)
from max/2026-08-20-upstream-parallelize-esplora into main
Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4913 Reviewed-by: tnull <tnull@noreply.git.rust-bitcoin.org> 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 19/100
This commit rewrites how a Lightning wallet talks to Esplora block-explorer servers so that many status checks happen in parallel instead of one at a time. It is a performance/refactoring change. There is no direct evidence in the commit that it fixes a security vulnerability, but it does add a small amount of new error-handling logic and changes timing/ordering assumptions that could affect correctness if the server returns inconsistent data.
Lower-priorityTest a stale template from a round dropped when an earlier one locksby Jeffrey Czyz · 5eb0a2b9 · Sep 14, 2026 · 1 fileMessage 83 · StrongTriage 0Details
Commit message · Jeffrey Czyz
Test a stale template from a round dropped when an earlier one locks
A template taken while an RBF chain is pending starts from the latest round's contribution and is tied to it. If an earlier candidate locks instead, the latest round is dropped, releasing the input it reserved itself, and a contribution built from the template is rejected as stale. Its refusal must release only what it added on top of the inherited parts: the promoted transaction spent one of them, and the other was released with the dropped round.
Add a test with a two-round chain whose earliest candidate locks after a template was taken from the second round. It asserts that promotion releases the second round's own input, that a contribution amending the template is refused with ContributionInvalid releasing only its fresh input, and that the released inputs are accepted from a fresh template.
Co-Authored-By: Claude <noreply@anthropic.com>
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Lower-priorityTest a queued contribution owning its parts once an earlier round locksby Jeffrey Czyz · 6a486bb4 · Sep 14, 2026 · 1 fileMessage 83 · StrongTriage 0Details
Commit message · Jeffrey Czyz
Test a queued contribution owning its parts once an earlier round locks
Across an RBF chain, each round's contribution inherits the inputs and outputs of the round it replaces and reserves only what it adds, and a contribution queued behind the chain inherits from the latest round the same way. When the earliest candidate locks, every later round is dropped at once and the queued contribution survives if it shares nothing with the promoted transaction. From then on it owns everything it holds: the rounds it inherited from are gone, so nothing else will release what it inherited.
Add a test with a three-round chain whose earliest candidate locks while a contribution inheriting from the last round is queued. It asserts that promotion releases only the middle round's own input, withholding the input the queued contribution inherited, and that canceling the queued contribution afterwards releases that input along with its own.
Co-Authored-By: Claude <noreply@anthropic.com>
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
`funding_contributed` reported every refusal as an `APIError`, whose variants were chosen for other `ChannelManager` methods. A stale template, a splice-out above the channel's maximum, an RBF attempt below the minimum feerate, a pending splice that can no longer be replaced, and a channel that is shutting down all surfaced as `APIMisuseError` with the same message, and the `NegotiationFailureReason` the channel refused with was dropped. No `SpliceNegotiationFailed` is emitted for a refused contribution, so the error is the only report the caller gets, yet it could not tell a refusal that calls for building a new contribution from a fresh template apart from one where retrying is pointless.
Return a `SpliceContributionError` instead. `ChannelUnavailable` means no funded channel matches the given ids, `ContributionPending` means a contribution of ours is already queued or under negotiation, and `NegotiationFailed` carries the reason the channel refused with, the same `NegotiationFailureReason` that `SpliceNegotiationFailed` reports for an attempt failing later, so its `is_retriable` applies to both.
Co-Authored-By: Claude <noreply@anthropic.com>
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Test contributions amended from a template whose attempt resolved
A FundingTemplate taken while a splice attempt is pending starts from that attempt's contribution, so the builder is seeded with its inputs and outputs and the built contribution records them as inherited. The application may swap every inherited part for a fresh input it has never used, leaving a contribution that shares nothing with the attempt. Once the attempt resolves, whether the candidate locks or the counterparty-initiated round the contribution had merged into is aborted, the record still names parts no longer committed anywhere, so submitting that contribution is rejected as stale although it spends nothing the attempt held: the channel's splice state changed since the template was obtained, and the client restarts from a fresh template.
Add two tests asserting that such a contribution is refused, that the DiscardFunding releasing it lists only the fresh input, and that the same input is accepted once resubmitted from a fresh template, each paired with a control that builds the same parts without the prior contribution and is accepted right away. The helpers are compiled only for unit tests, as they read the channel's splice candidates through a test-only accessor while the file is also built with `_test_utils`.
Co-Authored-By: Claude <noreply@anthropic.com>
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
from 2026-09-electrum-skip-creator-download into main
Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4992 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 · Low 30/100
This change stops the Electrum-based transaction sync client from downloading the very transaction that created an output it is watching. Previously, the client could request that transaction from Electrum, even though a transaction can never spend its own output. This wasted bandwidth and could leak slightly more information to the Electrum server than necessary. The patch adds a simple skip and a test that verifies no such download happens.
AI review queuedMerge PR 'Use preferred sPK of watched txn in electrum, not rand ones' (#4867)by tnull · bfe5ca89 · Sep 14, 2026 · 3 filesMessage 81 · StrongLow 44Details
Commit message · tnull
Merge PR 'Use preferred sPK of watched txn in electrum, not rand ones' (#4867)
✓ 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 · Low 44/100
This change improves how the Lightning Dev Kit's Electrum and Esplora transaction-sync clients track watched Bitcoin transactions. Previously, the code ignored the script pubkey (the 'address' associated with a transaction) supplied when registering a transaction, and instead picked an arbitrary output from the transaction when querying Electrum servers. The patch now records and prefers the script pubkey(s) the caller actually registered, falling back to an arbitrary non-OP_RETURN output only when needed. This makes the wallet more robust against Electrum servers that may not index certain script types (like OP_RETURN), and against callers that register a transaction with an incorrect script pubkey. It is a hardening fix rather than a clear-cut vulnerability patch, because the commit message and diff do not describe a specific exploitable bug.
Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4791 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 · Low 33/100
This commit changes how LDK stores pending event notifications. It adds serialization support for several event types that previously were not fully saved to disk, and introduces a helper method so the code can decide which events are worth keeping across restarts. The commit is a defensive correctness improvement: it makes event persistence more consistent and prevents stale or meaningless events from being replayed after a node restarts. It does not appear to fix an active exploit, but it removes a class of bugs where an event could be silently lost or mishandled around restarts.
Report DiscardFunding from per-contribution records, not channel state
A wallet managing UTXO locks through `Event::DiscardFunding` needs each input and output it hands to a `FundingContribution` released exactly once, and never while a splice transaction that can still confirm uses it. Deriving the event from channel state at failure time cannot do that. Once the channel is force closed there is no state left, so refusing a fee bump built from a `FundingTemplate` reported the pending splice's inputs as discardable, inviting the wallet to double-spend its own splice. While the channel is open, RBF rounds share inputs and outputs, so a part could be reported by several failures or by none.
Each contribution instead records what it inherited from the template's prior contribution, and every failure reports its inputs and outputs minus that record: exactly what it reserved itself. A part removed by one round and added back by a later one is reserved by the round that added it back. When a splice locks, the rounds it replaces release what they reserved themselves, except that a round negotiated before the locked one withholds what the locked transaction uses, as the locked round may have inherited it from there. A surviving queued contribution takes ownership of what it inherited.
The application must reserve a contribution's parts for it alone, other than what it inherited, and a retry must reserve the released parts again first, as a failure's `DiscardFunding` precedes its `SpliceNegotiationFailed`. As defense in depth, `funding_contributed` rejects a contribution whose record names funding no longer committed anywhere, including one built from a template that outlived its attempt, so misuse strands a lock rather than releasing funding a confirmable transaction uses.
The refusal's `DiscardFunding` marks the `ChannelManager` as needing persistence, as it is the only unlock signal the caller will get.
Fixes #4986
Co-Authored-By: Matt Corallo <git+claude@bluematt.me> Co-Authored-By: Claude <noreply@anthropic.com>
81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Lower-priorityMerge PR 'Drop the `claimable_payment` entry if the first HTLC is rejected' (#4982)by Matt Corallo · 83bb21dd · Sep 9, 2026 · 1 fileMessage 81 · StrongTriage 0Details
Commit message · Matt Corallo
Merge PR 'Drop the `claimable_payment` entry if the first HTLC is rejected' (#4982)
from 2026-09-bad-claimable-0.3 into main
Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4982 Reviewed-by: Val Wallace <val@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
