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 makes on-chain 'MonitorEvent' notifications durable and replay-safe. Previously, if a node crashed after a ChannelMonitor persisted a block update but before the ChannelManager processed the resulting event, the event could be …
Durability/atomicity fix for async persistence: prevents lost MonitorEvents across crashesNew ack-based event lifecycle with random event IDsArchival gating on unacknowledged events to avoid losing preimage/timeout information
This commit refactors how LDK nodes claim incoming Lightning payments. It replaces a separate 'claim with known custom TLVs' method with an options struct passed to the normal claim call, and fixes two edge cases in payment attribution dat…
API change: claim_funds now takes ClaimFundsOptions, consolidating TLV-known behavior into one pathFailure-packet length bound added to prevent oversized onion error messagesIncoming failure packet truncated at 32 KiB before processing
This change fixes a wallet bookkeeping problem in rust-lightning's built-in coin-selection wrappers. Previously, when a splice attempt failed or coin selection errored after picking UTXOs, those UTXOs stayed marked as 'reserved' in memory …
Resource exhaustion / denial-of-service via permanent in-memory UTXO reservationIncorrect state tracking in coin-selection wrapperNew API method required for correct lifecycle management (release_utxos)
This commit fixes a bug in the wallet's coin-selection code. When the wallet picked UTXOs to spend, it locked them immediately so they couldn't be reused. But if a later step—fetching the change address or the previous transaction—failed, …
Resource lock leak on error pathUTXO lock state inconsistency between selection and confirmationDenial-of-service/funds-unavailability risk from persistent UTXO locks
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 fixes a design flaw in LDK's built-in wallet helper where coins selected for a splice-in (or other unclaimed funding) were permanently reserved in memory if the transaction was abandoned. Over repeated failed splices, all spend…
Denial-of-service via UTXO exhaustion from repeated failed splice negotiationsRisk of inability to broadcast fee-bumping/claim transactions due to lack of available UTXOsNew API surface (release_utxos) introduced to mitigate resource leak
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.
Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
Lower-priorityln/refactor: move hex test helpers from blinded payments to test_utilsby Carla Kirk-Cohen · 9cfd18c3 · Nov 12, 2025 · 2 filesMessage 60 · AdequateInformational 15Details
Commit message · Carla Kirk-Cohen
ln/refactor: move hex test helpers from blinded payments to test_utils
60/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
AI analysis · Informational 15/100
This commit is a simple code cleanup: it moves three small helper functions used only in tests from one test file into a shared test utility file. There is no change to production code, no security fix, and no behavior change.
Lower-priorityln/test: move commitment check macro out of outbound testby Carla Kirk-Cohen · 2b92b083 · Nov 12, 2025 · 1 fileMessage 75 · AdequateInformational 15Details
Commit message · Carla Kirk-Cohen
ln/test: move commitment check macro out of outbound test
To be used in the commits that follow for zero fee commitment test vectors.
75/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
AI analysis · Informational 15/100
This commit is a pure test-code refactoring. It moves a large macro used to check commitment transactions from inside one specific test function to a shared location so it can be reused by upcoming tests. No production code, user behavior, or security logic is changed.
Replace calls to `get_htlc_update_msgs` macro to the identically-named function.
50/100 · ThinMessage clarity
✓ Descriptive subject✓ 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 internal cleanup in the rust-lightning test code. It removes a helper macro called `get_htlc_update_msgs!` and replaces every use of it with an already-existing function of the same name. There is no change to production code, user-facing behavior, or security logic.
Splicing should also have fuzz coverage, and it depends on the quiescence protocol.
70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 15/100
This commit is a test-only change. It replaces fuzz-testing coverage for the older 'quiescence' protocol with coverage for the newer 'splicing' feature in a Lightning channel consistency fuzz target. It adds test wallets, message handlers, and fuzz actions to exercise splicing, but makes no changes to production code that handles real user funds or network messages.
Lower-priorityBreak up ChannelContext::funding_tx_constructedby Wilmer Paulino · 25264d75 · Nov 11, 2025 · 1 fileMessage 58 · ThinInformational 15Details
Commit message · Wilmer Paulino
Break up ChannelContext::funding_tx_constructed
This method was originally intended to DRY the logic between `FundedChannel` and `PendingChannelV2` when handling `funding_tx_constructed`, though it's not very useful anymore.
This is a routine code cleanup that removes a helper method and copies its logic directly into the two places that used it. There is no security fix or behavior change visible in the diff.
Remove invalid splice debug assertion in funding_tx_constructed
We incorrectly assumed that both commitments must be at the same height, but this is certainly possible whenever updates are proposed in both directions at the same time.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 28/100
This commit removes a debug-only assertion in the code that handles splicing (a way to resize a Lightning channel). The assertion incorrectly assumed two commitment counters would always match during a splice, but they can legitimately differ when both channel peers propose updates at the same time. The change only affects debug builds and does not alter production behavior, so it is unlikely to be directly exploitable. It is a code-correctness fix rather than a security patch for a live vulnerability.
Lower-priorityAvoid returning user error when stfu is not ready to be sent yetby Wilmer Paulino · c2b15c21 · Nov 11, 2025 · 1 fileMessage 85 · StrongInformational 21Details
Commit message · Wilmer Paulino
Avoid returning user error when stfu is not ready to be sent yet
When we propose quiescence due to a user initiated action, such as a splice, it's possible that the `stfu` message is not ready to be sent out yet due to the state machine pending a change. This would result in an error communicated back to the caller of `ChannelManager::splice_channel`, but this is unnecessary and confusing, the splice is still pending and will be carried out once quiescence is eventually negotiated.
85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Informational 21/100
This change fixes a minor user-experience issue in the Lightning Dev Kit's channel splicing flow. Previously, if a user requested a splice but the internal state machine wasn't ready to send the required 'stfu' (stop, wait for update) message immediately, the code would return an error to the caller even though the splice was still pending and would proceed later. Now it logs the condition and returns success with no message, avoiding an unnecessary and confusing error.
Lower-priorityProperly consider blinded paths in `InFlightHtlcs`by Matt Corallo · dc25a5ba · Nov 11, 2025 · 2 filesMessage 81 · StrongModerate 59Details
Commit message · Matt Corallo
Properly consider blinded paths in `InFlightHtlcs`
When paying a BOLT 12 invoice an amount greater than any one of multiple blinded paths, we need to track how much is in-flight across the paths when retrying. Here we do so, tracking blinded path usage in a new field in `InFlightHtlcs`.
Fixes #2737
81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
AI analysis · Moderate 59/100
This commit fixes a bug in how the Lightning Dev Kit tracks money that is already traveling along hidden ("blinded") payment paths. Previously, when retrying a payment split across several blinded paths, the software could over-send because it did not count how much was already in-flight on each blinded path. The patch adds tracking for those blinded paths and uses it when scoring routes, preventing attempts to exceed each path's stated maximum.
Lower-priorityAdd method to convert FundingTxInput to Utxoby Jeffrey Czyz · 2330ed98 · Nov 11, 2025 · 1 fileMessage 60 · AdequateInformational 15Details
Commit message · Jeffrey Czyz
Add method to convert FundingTxInput to Utxo
Useful for re-using code producing a FundingTxInput set to implement CoinSelectionSource.
60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
AI analysis · Informational 15/100
This commit adds a simple public helper method that exposes the internal Utxo field of a FundingTxInput object. It is a pure API convenience with no security-relevant behavior change.
Security candidateUse a tolerance when estimating remote feesby Jeffrey Czyz · 3aa45740 · Nov 11, 2025 · 1 fileMessage 68 · AdequateLow 33Details
Commit message · Jeffrey Czyz
Use a tolerance when estimating remote fees
The interactive-tx construction protocol uses an agreed upon fee rate. Since the bitcoind coin selection algorithm may underpay fees when no change output is needed, providing a tolerance when checking if the remote's fee contribution could avoid some unexpected failures. This commit introduces a 95% tolerance similar to Eclair.
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 change relaxes a fee-checking rule during Bitcoin Lightning channel transactions. When two parties jointly build a transaction, the code now accepts a remote party's fee contribution that is up to 5% lower than the agreed rate, matching how another major implementation (Eclair) behaves. This avoids false failures caused by real-world coin-selection quirks, but it also means the local node may accept slightly less fee than strictly required.
The interactive-tx construction protocol needs to make sure the constructed transaction does not exceed MAX_STANDARD_TX_WEIGHT. A naive estimate of the transaction weight after signing was used, but was not accurate. Specifically, it double-counted EMPTY_SCRIPT_SIG_WEIGHT and didn't include SEGWIT_MARKER_FLAG_WEIGHT.
This commit fixes how rust-lightning estimates the final size of a Bitcoin transaction during the interactive-tx protocol used to build funding transactions for Lightning channels. The old estimate double-counted a fixed empty-signature weight and forgot to add the SegWit marker/flag bytes, so it could wrongly allow a transaction that is actually too large to be accepted by the Bitcoin network. Such a transaction would not propagate through standard Bitcoin nodes, potentially causing a channel-funding attempt to fail or get stuck.
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.
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 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.
Lower-priorityRemove `do_main_commitment_signed_dance` call in macroby elnosh · b675324a · Nov 10, 2025 · 1 fileMessage 50 · ThinInformational 11Details
Commit message · elnosh
Remove `do_main_commitment_signed_dance` call in macro
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 11/100
This commit removes an unused branch of a Rust macro used only in test helper code. It is a code cleanup change with no apparent effect on production Lightning node behavior or security.
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.
Lower-priorityUse `honggfuzz`'s `--run-time` arg to limit per-fuzz runtime in CIby Matt Corallo · 8015c015 · Nov 10, 2025 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Matt Corallo
Use `honggfuzz`'s `--run-time` arg to limit per-fuzz runtime in CI
We have some complexity in `ci-fuzz.sh` to limit each fuzzer to a rough runtime, but `honggfuzz` has a `--run-time` argument that we can simply use instead, which we do here.
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
fuzzing or regression evidence
AI analysis · Informational 15/100
This commit is a cleanup of the project's continuous integration fuzz-testing script. It replaces a custom, per-target method of limiting how long each fuzz test runs with a built-in honggfuzz command-line option (`--run_time 30`). There is no change to the actual Lightning protocol code, cryptography, networking, or any code that end users run. It only affects how long automated fuzzing jobs run in CI.
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.
AI review queuedDrop required `Box`ing of `lightning` trait `Future`sby Matt Corallo · 3da5f583 · Nov 10, 2025 · 4 filesMessage 73 · AdequateInformational 18Details
Commit message · Matt Corallo
Drop required `Box`ing of `lightning` trait `Future`s
Now that our MSRV is 1.75, we can return `impl Trait` from trait methods. Here we use this to clean up `lightning` crate trait methods, dropping the `Pin<Box<dyn ...>>`/`AsyncResult` we had to use to have trait methods return a concrete type.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 18/100
This commit is a routine code cleanup in the Lightning Dev Kit Rust library. It takes advantage of a newer Rust language feature (available since Rust 1.75) to remove unnecessary 'Box' heap allocations around futures returned from certain trait methods. There is no indication this change fixes a security bug or introduces a vulnerability; it is a refactoring to simplify the code and reduce allocations.
AI review queuedTrivially replace `Box::pin` with `pin!` in a few placesby Matt Corallo · 21052847 · Nov 10, 2025 · 6 filesMessage 73 · AdequateInformational 15Details
Commit message · Matt Corallo
Trivially replace `Box::pin` with `pin!` in a few places
Now that our MSRV is above 1.68 we can use the `pin!` macro to avoid having to `Box` various futures, avoiding some allocations, especially in `lightning-net-tokio`, which happens in a tight loop.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit is a routine code cleanup that swaps one Rust standard-library mechanism for pinning futures (`Box::pin`) with a newer, allocation-free equivalent (`pin!`). It removes heap allocations in a few internal loops and sync wrappers, but does not change program logic, trust boundaries, or behavior. There is no security relevance.
Lower-priorityDrop required `Box`ing of `lightning-block-sync` `Future`sby Matt Corallo · a435228c · Nov 10, 2025 · 6 filesMessage 73 · AdequateInformational 15Details
Commit message · Matt Corallo
Drop required `Box`ing of `lightning-block-sync` `Future`s
Now that our MSRV is 1.75, we can return `impl Trait` from trait methods. Here we use this to clean up `lightning-block-sync` trait methods, dropping the `Pin<Box<dyn ...>>` we had to use to have trait methods return a concrete type.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100
This commit is a routine code cleanup in the Lightning Dev Kit's block synchronization module. It takes advantage of a newer Rust language feature (returning 'impl Trait' from trait methods, now that the project's minimum supported Rust version is 1.75) to remove unnecessary heap-allocated boxed futures. There is no security-relevant change here; it is purely a refactoring to simplify the code and remove an old workaround.
Lower-priorityDrop required `Box`ing of `KVStore` `Future`sby Matt Corallo · 0b4e1b5c · Nov 10, 2025 · 6 filesMessage 68 · AdequateInformational 17Details
Commit message · Matt Corallo
Drop required `Box`ing of `KVStore` `Future`s
Now that our MSRV is 1.75, we can return `impl Trait` from trait methods. Here we use this to clean up `KVStore` methods, dropping the `Pin<Box<dyn ...>>` we had to use to have trait methods return a concrete type. Sadly, there's two places where we can't drop a `Box::pin` until we switch to edition 2024.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 17/100
This commit is a routine Rust code cleanup: it removes the requirement that KVStore trait methods return their futures inside a Box (a heap allocation). It takes advantage of a newer Rust compiler feature (returning 'impl Trait' from trait methods) to make the code simpler and slightly more efficient. There is no indication this fixes a security bug or introduces a vulnerability.
Lower-priorityMove `lightning-transaction-sync` back into the main workspaceby Matt Corallo · 7956af05 · Nov 10, 2025 · 4 filesMessage 65 · AdequateInformational 15Details
Commit message · Matt Corallo
Move `lightning-transaction-sync` back into the main workspace
Now that it has the same MSRV as everything else in the workspace, it doesn't need to live on its own.
65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
AI analysis · Informational 15/100
This commit is purely a housekeeping change: it moves the `lightning-transaction-sync` crate from a separate mini-workspace back into the main project workspace because it now uses the same minimum Rust version as everything else. The only files changed are CI workflow definitions and test scripts. There is no change to application code, no bug fix, and no security patch.