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
Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
Security candidateClamp our selected reserve to the counterparty's dust limitby Leo Nash · 4ae44e73 · Mar 12, 2026 · 6 filesMessage 73 · AdequateModerate 58Details
Commit message · Leo Nash
Clamp our selected reserve to the counterparty's dust limit
In a subsequent commit, we will allow the counterparty's dust limit to be greater than our `MIN_THEIR_CHANNEL_RESERVE_SATOSHIS`. Our selected reserve must always be greater than their dust limit, so we set our selected reserve to be equal to or greater than their dust limit.
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 · Moderate 58/100
This commit changes how Lightning channels set a minimum 'reserve' amount that each side must keep in the channel. The reserve is now forced to be at least as large as the other side's 'dust limit' (the smallest transaction output considered worth tracking). Without this, a peer could set a very high dust limit while the reserve stayed low, potentially allowing tiny outputs to be treated as non-existent or causing the channel's accounting rules to disagree between the two sides. The change is defensive and prepares for a later feature allowing larger dust limits.
We plan to have a single channel signer type going forward, so this is unnecessary.
33/100 · OpaqueMessage clarity
✓ Subject identifies a change✓ Provides an explanatory body! Too few words to establish purpose! Opaque security-relevant change
Why it was queued
signing or wallet pathboot or update path
AI analysis · Informational 15/100
This commit is a routine internal code cleanup in the Lightning Dev Kit's Rust implementation. It removes a wrapper type called ChannelSignerType that previously distinguished between different kinds of channel signers, because the project now plans to support only one signer type (ECDSA). The change simplifies function signatures and removes now-unnecessary pattern matching, but does not fix a security bug or change cryptographic behavior.
Taproot support is not planned we see an increase in demand for it by users. The `musig2` crate is now owned by a third-party, and ultimately won't be used by the production version of Taproot that we end up releasing.
51/100 · ThinMessage clarity
✓ Subject identifies a change✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathboot or update path
AI analysis · Informational 15/100
This commit removes an unused experimental Taproot/MuSig2 code path from the rust-lightning project. It deletes the optional `musig2` dependency, removes the `taproot` build flag, and strips out all conditional Taproot-related message fields and serialization logic. There is no indication this fixes a security vulnerability; it is a cleanup change because Taproot support is not currently planned and the external `musig2` crate is now owned by a third party.
Handle FeeRateAdjustmentError variants in splice acceptor path
Replace the generic error handling in splice_init and tx_init_rbf with explicit matching on FeeRateAdjustmentError variants:
- FeeRateTooLow: initiator's feerate is below our minimum. Proceed without contribution and preserve QuiescentAction for an RBF retry at our preferred feerate. - FeeRateTooHigh: initiator's feerate exceeds our maximum and would consume too much of our change output. Reject the splice with WarnAndDisconnect. - FeeBufferInsufficient: our fee buffer can't cover the acceptor's estimated fee at this feerate. Proceed without contribution.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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 · Low 44/100
This commit fixes how a Lightning node responds when a peer proposes a splice or RBF transaction fee rate that is too high for the node to afford. Previously, the node would silently drop its own contribution and continue, which could let the peer push through an unexpectedly expensive transaction. Now the node explicitly rejects the splice with a warning and disconnects when the fee rate is too high, while still allowing lower or retryable cases to proceed safely.
Security candidateHandle tx_ack_rbf on the initiator sideby Jeffrey Czyz · b07bfff8 · Mar 12, 2026 · 3 filesMessage 90 · StrongLow 32Details
Commit message · Jeffrey Czyz
Handle tx_ack_rbf on the initiator side
After sending tx_init_rbf, the initiator receives tx_ack_rbf from the acceptor. Implement the handler to validate the response and begin interactive transaction construction for the RBF funding transaction.
Only clear the interactive signing session in `reset_pending_splice_state` when the current funding negotiation is in `AwaitingSignatures`. When an earlier round completed signing and a later RBF round is in `AwaitingAck` or `ConstructingTransaction`, the session belongs to the prior round and must be preserved. Otherwise, disconnecting mid-RBF would destroy the completed prior round's signing session and fire a false debug assertion.
Update test_splice_rbf_acceptor_basic to exercise the full initiator flow: rbf_channel → funding_contributed → STFU exchange → tx_init_rbf → tx_ack_rbf → interactive TX → signing → mining → splice_locked. This replaces the previous test that manually constructed tx_init_rbf.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
90/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
signing boundarydefensive validation
AI analysis · Low 32/100
This commit adds support in the Lightning Dev Kit for handling a specific protocol message (tx_ack_rbf) when a channel participant initiates a fee-bump (RBF) of a pending splice transaction. Previously, receiving this message caused an error. The change also fixes a related bug where resetting splice state could incorrectly discard a completed signing session from an earlier round, which could trigger a debug assertion. The commit is primarily a feature implementation with a defensive bugfix, not a disclosed security vulnerability.
ln/events: multiple htlcs in/out for trampoline PaymentForwarded
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
boot or update path
AI analysis · Informational 19/100
This commit is a routine API refactor in the Lightning Dev Kit. It changes how a 'payment forwarded' event reports the incoming and outgoing payment channels, grouping them into lists so that future 'trampoline' routing can report multiple parts. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a feature/structural improvement.
Security candidateContribute to splice as acceptorby Jeffrey Czyz · d964be91 · Mar 4, 2026 · 3 filesMessage 68 · AdequateLow 33Details
Commit message · Jeffrey Czyz
Contribute to splice as acceptor
When both nodes want to splice simultaneously, the quiescence tie-breaker designates one as the initiator. Previously, the losing node responded with zero contribution, requiring a second full splice session after the first splice locked. This is wasteful, especially for often-offline nodes that may connect and immediately want to splice.
Instead, the losing node contributes to the winner's splice as the acceptor, merging both contributions into a single splice transaction. Since the FundingContribution was originally built with initiator fees (which include common fields and shared input/output weight), the fee is adjusted to the acceptor rate before contributing, with the surplus returned to the change output.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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 33/100
This commit changes how the Lightning Dev Kit handles a rare situation where both sides of a channel try to splice funds at the same time. Previously, the node that lost the tie-breaker would sit out and start a second splice later. Now, the loser contributes its funds to the winner's splice as an 'acceptor,' combining both into one transaction. The change also adjusts fees and change outputs when the winner's chosen fee rate differs from what the loser expected. This is a protocol optimization, not a clear security fix, but it touches fee accounting and transaction construction, which are sensitive areas.
Security candidateAdjust FundingContribution for acceptorby Jeffrey Czyz · 7942c745 · Mar 4, 2026 · 6 filesMessage 58 · ThinLow 44Details
Commit message · Jeffrey Czyz
Adjust FundingContribution for acceptor
When constructing a FundingContribution, it's always assumed the estimated_fee is for when used as the initiator, who pays for the common fields and shared inputs / outputs. However, when the contribution is used as the acceptor, we'd be overpaying fees.
Additionally, the initiator's chosen fee rate may not be compatible with the acceptors contributions. The selected UTXOs may not be enough to pay for a higher feerate (i.e., the change output is not enough to pay or there is no change output).
This change provides a method on FundingContribution for adjusting the fee rate with the above concerns in mind. It also updates it to include a max_feerate specified by the user when initiating a splice. This ensures the acceptor isn't forced to pay an overly high fee rate.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit fixes a fee-calculation bug in Lightning splicing. Previously, when both sides tried to splice at the same time, the loser of a tie-break (the 'acceptor') built their contribution as if they were going to pay for the whole shared transaction. That made them overpay fees, and a high fee rate chosen by the other side could drain more from their wallet than intended or even make the transaction invalid. The patch adds logic to re-estimate fees from the acceptor's perspective and lets users set a maximum fee rate they are willing to accept.
Include change output weight in estimate_transaction_fee
Add a `change_output: Option<&TxOut>` parameter to `estimate_transaction_fee` so the initial fee estimate accounts for the change output's weight. Previously, the change output weight was omitted from `estimated_fee` in `FundingContribution`, causing the estimate to be slightly too low when a change output was present.
This also eliminates an unnecessary `Vec<TxOut>` allocation in `compute_feerate_adjustment`, which previously cloned outputs into a temporary Vec just to include the change output for the fee estimate.
A mock `TightBudgetWallet` is added to `splicing_tests` to demonstrate that `validate()` correctly rejects contributions where the input value is sufficient without the change output weight but insufficient with it.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarydefensive validation
AI analysis · Low 37/100
This commit fixes a fee-estimation bug in rust-lightning's channel funding and splicing code. When building a transaction that creates a change output, the code previously forgot to include the change output's size/weight when estimating the required transaction fee. That made the fee estimate slightly too low. The patch adds the missing weight and adds a test showing that a contribution with barely enough money would now be correctly rejected, whereas before it might have been accepted and later failed to broadcast or confirm reliably.
Stop persisting QuiescentAction and remove legacy code
Now that the Splice variant (containing non-serializable FundingContribution) is the only variant produced, and the previous commit consumes the acceptor's quiescent_action in splice_init(), there is no longer a need to persist it. This allows removing LegacySplice, SpliceInstructions, ChangeStrategy, and related code paths including calculate_change_output, calculate_change_output_value, and the legacy send_splice_init method.
With ChangeStrategy removed, the only remaining path in calculate_change_output was FromCoinSelection which always returned Ok(None), making it dead code. The into_interactive_tx_constructor method is simplified accordingly, and the signer_provider parameter is removed from it and from splice_init/splice_ack since it was only needed for the removed change output calculation.
On deserialization, quiescent_action (TLV 65) is still read for backwards compatibility but discarded, and the awaiting_quiescence channel state flag is cleared since it cannot be acted upon without a quiescent_action.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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 · Low 35/100
This commit removes old, no-longer-used code paths for splicing (a way to resize a Lightning channel). It stops saving a 'quiescent action' to disk because the only remaining variant cannot be serialized, and it drops legacy change-output calculation logic. On loading old data, the stored action is read and then discarded, and the 'awaiting quiescence' flag is cleared so the node does not get stuck waiting for something it can no longer act upon. The change is mostly cleanup and hardening against stale persisted state.
Security candidatePropagate unexpected metadata errors when preserving mtime in fs_storeby benthecarman · 6a43a451 · Feb 25, 2026 · 1 fileMessage 73 · AdequateLow 35Details
Commit message · benthecarman
Propagate unexpected metadata errors when preserving mtime in fs_store
Previously, all fs::metadata errors were silently ignored via .ok(), which could hide permission or I/O errors. Now error are properly handled.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
credential or privilege state
AI analysis · Low 35/100
This change fixes a bug in the file storage component where errors from checking a file's metadata (such as permission denied or disk I/O problems) were silently ignored. Now, most unexpected errors are reported up the chain instead of being swallowed, so the software can react appropriately rather than silently losing information about file modification times.
Security candidateMultiply the feerate by the spike multiple in `can_accept_incoming_htlc`by Leo Nash · 51f8c4c9 · Feb 24, 2026 · 3 filesMessage 73 · AdequateLow 45Details
Commit message · Leo Nash
Multiply the feerate by the spike multiple in `can_accept_incoming_htlc`
We choose to multiply `FEE_SPIKE_BUFFER_FEE_INCREASE_MULTIPLE` by the feerate when checking the fee spike buffer in `can_accept_incoming_htlc` instead of multiplying the multiple by the commitment transaction fee. This allows us to delete `NextCommitmentStats::commit_tx_fee_sat`, and return balances including the commitment transaction fee in `TxBuilder::get_channel_stats`. This unblocks a good amount of cleanup.
Note that this means LDK now rejects HTLCs that previous versions of LDK would have accepted. We made the mirroring change in `get_available_balances_for_scope` a few commits earlier.
We also now account for non-dust HTLCs turning to dust at the multiplied feerate, decreasing the overall weight of the transaction.
We also remove other fields in `NextCommitmentStats` which can be easily calculated in `channel` only.
`TxBuilder::get_channel_stats` could also check the reserve requirements, given that it gets the reserves in `ChannelConstraints`. I leave this to follow-up work.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathboot or update path
AI analysis · Low 45/100
This commit tightens how Lightning Dev Kit (LDK) checks whether an incoming payment (HTLC) can be safely accepted. It changes the fee-spike buffer calculation so that LDK now rejects more borderline HTLCs than before, reducing the risk that a sudden on-chain fee spike leaves the channel unable to close safely. The change is described by the authors as a stricter policy alignment, not a fix for a known active exploit.
The following types have methods for returning contributed inputs and outputs: - FundingNegotiationContext - InteractiveTxConstructor - InteractiveTxSigningSession - ConstructedTransaction
Having iterators for these can avoid allocations, which is useful for filtering contributed input and outputs when producing DiscardFunding events.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
68/100 · AdequateMessage clarity
✓ 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 is a straightforward internal code cleanup in the Lightning Dev Kit's transaction-building code. It replaces a few methods that always built full lists of contributed inputs and outputs with new iterator methods that let callers decide when to build those lists. There is no change to security logic, no bug fix, and no externally visible behavior change.
Security candidateClean up fuzz crate: use panic=abort, add stdin_fuzz support, remove dylibby Joost Jager · 69e2d8cf · Feb 23, 2026 · 75 filesMessage 95 · StrongInformational 15Details
Commit message · Joost Jager
Clean up fuzz crate: use panic=abort, add stdin_fuzz support, remove dylib
This commit makes three related changes to the fuzz infrastructure:
1. Set panic=abort on both dev and release profiles, and remove the dylib crate type (keeping rlib and staticlib). The dylib crate type was added in e28fd78e6 (2019) for a C-callable harness that was never implemented. Removing dylib is what enables panic=abort, since Rust forces panic=unwind on dylib crates. staticlib is retained as it is compatible with panic=abort.
2. Add stdin_fuzz support: a new Stdout logger, updated target template so that stdin_fuzz calls _test() with Stdout logging, and updated README with usage instructions. This allows reproducing crashes via piped input, useful for git bisect and AI-assisted debugging.
3. Update all fuzzer frontends (AFL, honggfuzz, libfuzzer, stdin_fuzz) to call the _test() functions directly instead of going through the _run() C wrappers.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidencesigning or wallet pathboot or update pathauthentication pathparser or protocol path
AI analysis · Informational 15/100
This commit is a routine cleanup of the project's fuzz-testing infrastructure. It changes how fuzz tests are compiled and run, adds a new way to feed test input via standard input, and removes an unused dynamic-library build mode. There is no indication it fixes or introduces a security vulnerability in the actual Lightning library code.
Security candidateInclude MPP payment amount in `RecipientOnionFields`by Matt Corallo · abf258a6 · Feb 20, 2026 · 29 filesMessage 95 · StrongLow 36Details
Commit message · Matt Corallo
Include MPP payment amount in `RecipientOnionFields`
In some uses of LDK we need the ability to send HTLCs for only a portion of some larger MPP payment. This allows payers to make single payments which spend funds from multiple wallets, which may be important for ecash wallets holding funds in multiple mints or graduated wallets which hold funds across a trusted wallet and a self-custodial wallet.
In order to allow for this, we need to separate the concept of the payment amount from the onion MPP amount. Here we start this process by adding a `total_mpp_amount_msat` field to `RecipientOnionFields` (which is the appropriate place for a field describing something in the recipient onion).
We currently always assert that it is equal to the existing fields, but will relax this in the coming commit(s).
We also start including a payment preimage on probe attempts, which appears to have been the intent of the code, but which did not work correctly.
The bulk of the test updates were done by Claude.
95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
signing or wallet pathboot or update path
AI analysis · Low 36/100
This commit is a preparatory refactor in LDK's payment-sending code. It adds a new `total_mpp_amount_msat` field to `RecipientOnionFields` so that, in future commits, a payer can send an HTLC that is only one part of a larger multi-part payment. For now the new field is always required and is asserted to match the existing payment amount, so behavior is unchanged. The commit also fixes a small related bug where probe payments were not including a payment preimage as intended. There is no immediate security vulnerability here; it is a feature-building change with a minor bug fix.
Security candidateValidate the `Router` is meeting MPP and max-fee limitations givenby Matt Corallo · c31a7bee · Feb 20, 2026 · 6 filesMessage 73 · AdequateLow 47Details
Commit message · Matt Corallo
Validate the `Router` is meeting MPP and max-fee limitations given
When `OutboundPayments` calls the provided `Router` to fetch a `Route` it passes a `RouteParameters` with a specific max-fee. Here we validate that the `Route` returned sticks to the limits provided, and also that it meets the MPP rules of not having any single MPP part which can be removed while still meeting the desired payment amount.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
defensive validationboot or update path
AI analysis · Low 47/100
This commit adds safety checks inside the Lightning payment code to make sure the route finder (the 'Router') actually follows the rules it was given. Before sending a payment, the code now verifies that the chosen route does not exceed the user-set maximum fee, does not contain useless empty paths, and does not include unnecessary multi-path payment (MPP) parts. If the router misbehaves, the payment is abandoned instead of being sent. It is a defensive hardening change rather than a fix for a known active attack.
Security candidateReplace `get_closing_signed_broadcast!` macro with direct function callsby elnosh · 28388c40 · Feb 19, 2026 · 5 filesMessage 65 · AdequateInformational 15Details
Commit message · elnosh
Replace `get_closing_signed_broadcast!` macro with direct function calls
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing or wallet pathboot or update path
AI analysis · Informational 15/100
This commit is a straightforward code cleanup in the project's test suite. It replaces a Rust macro used only in tests with an equivalent regular function. There is no change to the actual Lightning node logic that runs in production, and no security-relevant behavior is altered.
Security candidateReplace `get_payment_preimage_hash!` macro with direct function callsby elnosh · e48478a7 · Feb 19, 2026 · 9 filesMessage 65 · AdequateInformational 15Details
Commit message · elnosh
Replace `get_payment_preimage_hash!` macro with direct function calls
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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 straightforward code cleanup in the project's test suite. It removes a helper macro used only in tests and replaces it with direct calls to an existing function. There is no change to the actual Lightning node logic that runs in production, and nothing in the commit suggests a security fix.
Security candidateReplace `check_closed_broadcast!` macro with direct function callsby elnosh · 63f4f8f5 · Feb 19, 2026 · 13 filesMessage 65 · AdequateInformational 15Details
Commit message · elnosh
Replace `check_closed_broadcast!` macro with direct function calls
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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 straightforward code cleanup in the project's test suite. It replaces a Rust macro called `check_closed_broadcast!` with direct calls to an equivalent function. Macros are a shorthand in Rust; replacing them with normal function calls makes the test code easier to read and maintain but does not change what the tests actually do. There is no change to the live Lightning node software that users run, so this cannot affect real funds or network security.
Security candidateTime out incomplete MPP payments in chanmon_consistencyby Wilmer Paulino · 520dcbb2 · Feb 18, 2026 · 4 filesMessage 73 · AdequateLow 27Details
Commit message · Wilmer Paulino
Time out incomplete MPP payments in chanmon_consistency
This requires calling `timer_tick_occurred`. As a result, when `timer_tick_occurred` is called, disabled/enabled updates and `WarnAndDisconnect` events may be triggered.
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 · Low 27/100
This commit changes how a Lightning payment library runs its internal fuzz tests. It makes the test harness call the normal periodic timer function instead of a special stripped-down version, so incomplete multi-part payments time out properly during testing. The production code is mostly unchanged, but a few internal test-only helpers are now available under a new test-utilities feature flag. There is no direct evidence this fixes a real-world security bug; it appears to be a test-harness cleanup that makes fuzzing more realistic.
Security candidateDrive splices to completion in chanmon_consistencyby Wilmer Paulino · 3c09513b · Feb 18, 2026 · 1 fileMessage 85 · StrongInformational 12Details
Commit message · Wilmer Paulino
Drive splices to completion in chanmon_consistency
This commit adds support for locking splices. This required confirming transactions, which this target previously didn't consider.
It also fixes a `serial_id` collision, due to its generation using the first 4 bytes of `get_secure_random_bytes`, that was preventing splices from negotiating up to the `tx_signatures` exchange.
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 12/100
This commit updates a fuzzing test harness (chanmon_consistency) in the Lightning Dev Kit project. It adds the ability to simulate confirming splice transactions on a fake blockchain and fixes a serial ID collision in the test's random number generator. The changes are confined to test/fuzzing code and do not alter production Lightning logic.
This commit adds new opcodes to enable/disable signer operations one by one. Note that this only covers signer operations post-funding.
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 · Informational 13/100
This commit only changes test and fuzzing code. It adds new test controls that let developers temporarily disable or enable individual signer operations during fuzz testing, and it removes one unused signer-operation flag. There is no change to production Lightning code, so it does not create a real-world security vulnerability or fix one.
After cad88af, a few code paths that also lead to a quiescence exit were not accounted for. This commit addresses the last remaining path where we exit quiescence when we exchange `tx_signatures` with the counterparty.
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 44/100
This patch fixes a bug in the Lightning Dev Kit where, after a special quiet period called 'quiescence' used during splicing (modifying a channel's funds), some queued payment updates were not released when the quiet period ended via the 'tx_signatures' message exchange. The fix ensures those queued updates are freed and processed, preventing payment delays or stalls during splice operations.
Security candidateUse CoinSelection::change_output when splicingby Jeffrey Czyz · 96b9e6af · Feb 17, 2026 · 7 filesMessage 68 · AdequateLow 32Details
Commit message · Jeffrey Czyz
Use CoinSelection::change_output when splicing
Now that CoinSelection is used to fund a splice funding transaction, use that for determining of a change output should be used. Previously, the initiator could either provide a change script upfront or let LDK generate one using SignerProvider::get_destination_script.
Since older versions may have serialized a SpliceInstruction without a change script while waiting on quiescence, LDK must still generate a change output in this case.
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 changes how Lightning Dev Kit handles 'change' money during Bitcoin channel splicing. Previously, the user could provide a change address or LDK would generate one itself. Now, the wallet's coin-selection logic decides whether a change output is needed and what it looks like. The commit keeps a fallback for older stored data that may not include a change script. It is a code-quality and consistency improvement rather than a clear security fix, though it reduces the chance of fee or change-output mistakes during splicing.
Security candidateTest restart-claim of two MPP holding cell HTLCsby Valentine Wallace · 5daf51c0 · Feb 12, 2026 · 3 filesMessage 78 · AdequateInformational 15Details
Commit message · Valentine Wallace
Test restart-claim of two MPP holding cell HTLCs
Test that if we restart and had two inbound MPP-part HTLCs received over the same channel in the holding cell prior to shutdown, and we lost the holding cell prior to restart, those HTLCs will still be claimed backwards.
Test largely written by Claude
78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
boot or update path
AI analysis · Informational 15/100
This commit is a new regression test, not a fix. It verifies that a forwarding Lightning node can still claim two parts of a multi-path payment backwards after restarting, even if the node's temporary 'holding cell' state was lost during the crash. The test infrastructure was updated so the test can observe messages released from the holding cell during protocol exchanges. There is no production code change here.
