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-priorityDefault to anchor channelsby elnosh · aebcd1f7 · Feb 5, 2026 · 9 filesMessage 50 · ThinLow 42Details
Commit message · elnosh
Default to anchor channels
Set `negotiate_anchors_zero_fee_htlc_tx` default to true.
50/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides an explanatory body
AI analysis · Low 42/100
This commit changes the default setting so that new Lightning channels will use 'anchor outputs' whenever possible. Anchor outputs are a safer, more modern channel type, but they require the user to keep some on-chain bitcoin available to pay fees during an emergency force-close. To make sure users notice this new responsibility, the library now also forces every inbound channel request to be manually accepted. The change is a deliberate policy update, not a hidden bug, but it could surprise users who are not prepared to maintain the extra on-chain reserve.
Removes the `manually_accept_inbound_channels` config option. In upcoming commit we will default to anchor channels which requires users checking if they have enough onchain funds to cover fees in case of a force close. Hence, we move to always require users to manually accept inbound channels.
This commit removes the automatic acceptance of incoming Lightning channels in the LDK library. Previously, users could set a flag to automatically accept inbound channel requests. Now, every inbound channel request must be explicitly approved by the user through an OpenChannelRequest event. This is a deliberate design change to ensure users verify they have enough on-chain funds to cover fees, especially with upcoming anchor channel defaults. It is not a fix for an active vulnerability, but it prevents accidental or unsafe channel acceptance.
Lower-priorityFix off-by-one for unfunded channel peersby elnosh · b6bd3866 · Feb 5, 2026 · 2 filesMessage 68 · AdequateModerate 52Details
Commit message · elnosh
Fix off-by-one for unfunded channel peers
When accepting channels manually, it would fail if the # of peers without funded channels was == `MAX_UNFUNDED_CHANNEL_PEERS`, however, it should fail if the # of peers > `MAX_UNFUNDED_CHANNEL_PEERS`.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Moderate 52/100
This commit fixes a small boundary error in how Lightning Dev Kit counts peers that have unfunded channels. Previously, the software rejected new channel requests one peer too early, meaning legitimate users could be blocked from opening a channel when they were exactly at the configured limit. The fix changes the comparison from 'greater than or equal to' to 'greater than' the limit, restoring the intended behavior.
Lower-priorityDrop `SplicePrototype` featureby Matt Corallo · 5427b0de · Feb 5, 2026 · 1 fileMessage 58 · ThinInformational 15Details
Commit message · Matt Corallo
Drop `SplicePrototype` feature
Now that `SplicePrototype` and `SpliceProduction` share the same feature bit, there's not really any reason to have the `SplicePrototype` feature at all. Instead, we drop it, leaving only a `Splice` feature.
This commit is a routine cleanup of internal feature-flag names in a Lightning network library. It removes a duplicate 'SplicePrototype' label and keeps a single 'Splice' label for the same protocol feature bit. There is no security bug being fixed here.
AI review queuedSwitch `SplicePrototype` feature flag to the prod feature bitby Matt Corallo · 98c3cfff · Feb 5, 2026 · 1 fileMessage 73 · AdequateLow 33Details
Commit message · Matt Corallo
Switch `SplicePrototype` feature flag to the prod feature bit
When we shipped 0.2 we used the feature bit 155 to signal splicing, in line with what eclair was using. However, eclair was actually using that bit to signal splicing on a previous design which is incompatible with the current spec.
The result of this was that eclair nodes may attempt to splice using their protocol and we'd fail to deserialize their splice message (resulting in a reconnect, which luckily would clear their splice attempt and return the connection to normal).
As we really need to get off of their feature bit and there's not much reason to keep using a non-final-spec bit, we simply redefine `SplicePrototype` to bit 63 here.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
second-pass: broader security terminology
AI analysis · Low 33/100
This commit changes which 'feature bit' the Lightning Dev Kit uses to advertise experimental channel splicing support. Previously it used bit 155, the same bit an older Eclair implementation used for a different, incompatible splicing design. That mismatch could cause Eclair nodes to try to splice with LDK using the wrong protocol, leading to failed message parsing and repeated reconnects. The fix moves LDK's prototype splicing flag to bit 63, avoiding the collision. It is a protocol-compatibility fix, not a cryptographic vulnerability, but it does prevent a real interoperability failure.
Support async signing of interactive-tx initial commitment signatures
This commit allows for an async signer to immediately return upon a call to `EcdsaChannelSigner::sign_counterparty_commitment` for the initial commitment signatures of an interactively funded transaction, such that they can call back in via `ChannelManager::signer_unblocked` once the signatures are ready. This is done for both splices and dual-funded channels, though note that the latter still require more work to be integrated. Since `tx_signatures` must be sent only after exchanging `commitment_signed`, we make sure to hold them back if they're ready to be sent until our `commitment_signed` is also ready.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 27/100
This commit adds support for asynchronous (delayed) signing when opening or splicing Lightning channels that use the newer interactive-funding protocol. Previously, if a hardware or remote signer was not ready to produce the initial commitment signature, the code either did not support the delay or could accidentally send transaction signatures before the commitment signature was ready. The change holds back the transaction-signature message until the commitment signature is available, and adds a regression test for splicing. It is a protocol-correctness and robustness improvement rather than a fix for an active exploit.
fuzz: fix ChaCha20 encrypt_single_block to preserve data
The fuzzing ChaCha20 implementation's encrypt_single_block was not copying src to dest, causing encrypted data to be lost (dest remained zeros). This broke payment flows where metadata is encrypted into payment_secret - the receiver would decrypt zeros and detect the wrong payment method (LdkPaymentHash instead of UserPaymentHash), causing payments to fail with "mismatching preimage".
Fix by making encrypt_single_block copy src to dest (identity encryption), matching the behavior of the process() method.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
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 evidencecryptography-sensitive path
AI analysis · Low 27/100
This commit fixes a bug in a fuzzing-only (test-only) fake version of the ChaCha20 encryption code. The fake encryptor accidentally left the output as all zeros instead of copying the input, which caused simulated Lightning payments to fail during testing. The fix makes the test fake copy input to output unchanged. This is not a real cryptographic vulnerability and does not affect production code.
Lower-prioritySimplify in_flight_monitor_updates from Option<HashMap> to HashMapby Joost Jager · b509c4a9 · Feb 5, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Joost Jager
Simplify in_flight_monitor_updates from Option<HashMap> to HashMap
Since there is no semantic difference between None and Some(empty map) for in_flight_monitor_updates, simplify the type to HashMap and use unwrap_or_default() when reading from TLV fields.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100
This is a straightforward internal code cleanup in the Lightning Dev Kit's channel manager. It changes a data field from 'optional map' to just 'map' because an empty map means the same thing as no map. There is no security-relevant behavior change.
Lower-priorityCombine claimable HTLCs with purposes in ChannelManagerDataby Joost Jager · 07bcba97 · Feb 5, 2026 · 1 fileMessage 83 · StrongLow 29Details
Commit message · Joost Jager
Combine claimable HTLCs with purposes in ChannelManagerData
Move the reconstruction of claimable_payments from the main ChannelManager::read into ChannelManagerData::read. This removes the separate claimable_htlc_purposes and claimable_htlc_onion_fields fields from ChannelManagerData, replacing them with the combined claimable_payments HashMap.
This requires adding a node_signer parameter to ChannelManagerDataReadArgs to support verification of legacy hop data when reconstructing payment purposes for very old serialized data (pre-0.0.107).
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
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
defensive validation
AI analysis · Low 29/100
This commit is a code-cleanup refactor that moves the reconstruction of claimable payment data from one deserialization function to another. It does not change the underlying security logic but reorganizes how legacy payment records are verified when loading old wallet state. There is no direct evidence in the commit that this fixes an active security vulnerability.
Lower-prioritySimplify peer_storage_dir from Option<Vec> to Vec in ChannelManagerDataby Joost Jager · 47901533 · Feb 5, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Joost Jager
Simplify peer_storage_dir from Option<Vec> to Vec in ChannelManagerData
Since there is no semantic difference between None and Some(empty vec) for peer_storage_dir, simplify the type to Vec and use unwrap_or_default() when reading from TLV fields.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100
This is a small internal code cleanup in the Lightning Dev Kit's Rust implementation. It changes a data structure field from 'optional list' to just 'list', because an empty list and a missing list meant the same thing. There is no security-relevant change here.
Lower-priorityGroup legacy fields in ChannelManagerData to deduplicate commentby Joost Jager · 77be67b0 · Feb 5, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Joost Jager
Group legacy fields in ChannelManagerData to deduplicate comment
Reorder the struct fields to place all three `_legacy` fields together at the end, allowing the explanatory comment to appear once instead of being duplicated three times.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
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 pure code cleanup: it rearranges three struct fields in the Lightning channel manager so that a single comment can explain all of them instead of repeating the same comment three times. No behavior changes, no security fixes, and no bug fixes are present.
Use consistent unwrap_or_else pattern for optional TLV fields
Initialize pending_claiming_payments and monitor_update_blocked_actions_per_peer with None and resolve with unwrap_or_else, matching the pattern used for other optional hash map fields like pending_intercepted_htlcs_legacy.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 12/100
This is a small internal code cleanup in the Lightning Dev Kit's channel manager. It changes how two optional data fields are initialized during deserialization so they follow the same safe pattern already used elsewhere. There is no indication this fixes a security vulnerability or changes observable behavior for users.
Lower-priorityAdd a `custom` TLV read/write variantby Matt Corallo · 05c9a036 · Feb 4, 2026 · 2 filesMessage 68 · AdequateInformational 12Details
Commit message · Matt Corallo
Add a `custom` TLV read/write variant
At various points we've been stuck in our TLV read/write variants but just want to break out and write some damn code to initialize a field and some more code to decide what to write for a TLV.
We added the write-side part of this with the `legacy` TLV read/write variant, but its useful to also be able to specify a function which is called on the read side.
Here we add a `custom` TLV read/write variant which calls a method both on read and write to either decide what to write or to map a read value (if any) to the final field.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 12/100
This commit adds a new 'custom' variant to LDK's TLV (Type-Length-Value) serialization macros. It is a developer-facing feature that lets programmers supply custom read and write functions when serializing/deserializing data structures. The change is purely additive and does not by itself fix a bug or introduce a vulnerability; it is infrastructure for future message formats.
Introduces the ResourceManager struct. The core of methods that will be used to inform the HTLC forward decisions are add/resolve_htlc.
- add_htlc: Based on resource availability and reputation, it evaluates whehther to forward or fail the HTLC.
- resolve_htlc: Releases the bucket resources used from a HTLC previously added and updates the channel's reputation based on HTLC fees and resolution times.
Lower-priorityAdd Channel to resource managerby elnosh · 7b4ae500 · Feb 4, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · elnosh
Add Channel to resource manager
The Channel struct introduced here has the core information that will be used by the resource manager to make forwarding decisions on HTLCs:
- Reputation that this channel has accrued as an outgoing link in HTLC forwards.
- Revenue (forwarding fees) that the channel has earned us as an incoming link.
- Pending HTLCs this channel is currently holding as an outgoing link.
- Bucket resources that are currently in use in general, congestion and protected.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityAdd BucketResources to resource managerby elnosh · e235d66c · Feb 4, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · elnosh
Add BucketResources to resource manager
Resources available in the channel will be divided into general, congestion and protected resources. Here we implement the bucket resources that will be used for congestion and protected.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityAdd GeneralBucket to resource managerby elnosh · 4a5a9c75 · Feb 4, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · elnosh
Add GeneralBucket to resource manager
Resources available in the channel will be divided into general, congestion and protected resources. Here we implement the general bucket with basic denial of service protections.
In debug mode, using SignedAmount::abs can lead to an integer overflow when used with SignedAmount::MIN. Use SignedAmount::unsigned_abs to avoid this.
85/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
Why it was queued
memory safety
AI analysis · Low 34/100
This commit fixes a potential integer overflow bug in the Lightning Dev Kit's channel splicing code. The bug occurs when converting a negative Bitcoin amount to its absolute value in debug builds, which could crash the program. The fix uses a safer method that cannot overflow. The practical security impact is limited because the overflow only happens in debug mode and the affected values are normally constrained by protocol rules.
Lower-priorityAdd SmoothedDecayingAverage to resource managerby elnosh · c0447e18 · Feb 3, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · elnosh
Add SmoothedDecayingAverage to resource manager
The SmoothedDecayingAverage implemented here will be used in upcoming commits to track the incoming revenue that channels have generated through HTLC forwards.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityAdd DecayingAverage to resource managerby elnosh · 8bae0610 · Feb 3, 2026 · 2 filesMessage 68 · AdequateTriage 0Details
Commit message · elnosh
Add DecayingAverage to resource manager
Implements a decaying average over a rolling window. It will be used in upcoming commits by the resource manager to track reputation and revenue of channels.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityCheck semver of all workspace crates rather than an explicit listby Matt Corallo · a123cfa0 · Feb 3, 2026 · 1 fileMessage 50 · ThinInformational 15Details
Commit message · Matt Corallo
Check semver of all workspace crates rather than an explicit list
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
documentation-only discount
AI analysis · Informational 15/100
This commit updates an automated GitHub workflow that checks whether code changes break promised version compatibility. It replaces a manually maintained list of checks with a single tool command that scans all crates in the project. There is no change to the actual Lightning library code, user-facing behavior, or network security.
AI review queuedCorrect crate version numbers that have broken semverby Matt Corallo · 784b85c1 · Feb 3, 2026 · 10 filesMessage 73 · AdequateInformational 15Details
Commit message · Matt Corallo
Correct crate version numbers that have broken semver
The semver CI check is great but only checks the immediate crate in question. It doesn't catch that many of our crates depend on `lightning` and thus have actually broken semver as the types they use have changed to `lightning` 0.3.
Here we hump the version of crates that have actually changed semver since 0.2.
In addition to those that depend on `lightning`, `lightning-invoice`'s API has changed (but was not being checked by the semver CI task).
Finally, `lightning-macros` was updated to 0.2.1, so the version is changed to 0.2.2.
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 only changes version numbers in package configuration files (Cargo.toml). It bumps crate versions from 0.2.x to 0.3.x to keep them aligned with semantic versioning rules after the underlying `lightning` crate changed its public types. There is no code change, no bug fix, and no security patch.
Security candidateFix 0.2 CHANGELOG to note that offers will break on downgradeby Matt Corallo · e245c0aa · Feb 3, 2026 · 1 fileMessage 73 · AdequateInformational 18Details
Commit message · Matt Corallo
Fix 0.2 CHANGELOG to note that offers will break on downgrade
It turns out we also switched the key we use to authenticate offers *created* in the 0.2 upgrade and as a result downgrading to 0.2 will break any offers created on 0.2. This wasn't intentional but it doesn't really seem worth fixing at this point, so just document it.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
update trustdocumentation-only discount
AI analysis · Informational 18/100
This commit is a documentation-only update to the 0.2 release CHANGELOG. It adds a note warning users that if they upgrade to LDK 0.2, create BOLT 12 offers, and then downgrade to an older LDK version, those offers will not be accepted. This is a compatibility/operational issue, not a security vulnerability, and no code behavior is changed.
Security candidateAdd AChainMonitor trait and use it in background processorby Joost Jager · 4800a473 · Feb 3, 2026 · 2 filesMessage 73 · AdequateInformational 15Details
Commit message · Joost Jager
Add AChainMonitor trait and use it in background processor
Add a new `AChainMonitor` trait following the same pattern as `AChannelManager`. This trait provides associated types for all generic parameters of `ChainMonitor` and a `get_cm()` method to access the underlying `ChainMonitor`.
Update the background processor to use `AChainMonitor` trait bounds instead of spelling out the full `ChainMonitor` generic parameters. This simplifies the function signatures by removing 5-6 explicit generic parameters (CF, T, F, P, ES) per function.
This is preparation for adding a flush method to the AChainMonitor trait.
Co-Authored-By: Claude Opus 4.5 <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 · Informational 15/100
This commit is a pure internal refactoring in the Lightning Dev Kit Rust library. It introduces a new helper trait called AChainMonitor that wraps the existing ChainMonitor type, and updates background-processor functions to use that trait instead of listing many generic type parameters directly. There is no change to user-visible behavior, no bug fix, and no security-sensitive logic change.
AI review queuedAdd Utxo::new_v1_p2trby Willem Van Lint · 1f6095b5 · Feb 2, 2026 · 1 fileMessage 28 · OpaqueInformational 15Details
Commit message · Willem Van Lint
Add Utxo::new_v1_p2tr
28/100 · OpaqueMessage clarity
✓ Subject identifies a change! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: opaque commit messagesecond-pass: security-sensitive path
AI analysis · Informational 15/100
This commit adds a new helper function to create a UTXO descriptor for modern Taproot (P2TR) single-key spending. It is purely additive API surface with no changes to existing behavior, no bug fixes, and no security-sensitive logic beyond correctly estimating transaction weight for fee calculations.