LL
← All projectsLightning Labs

LND

Go implementation of a complete Lightning Network node.

BitcoinLightning NetworkNormal
Repository coverage

1399 commits in the local evidence base

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.

142security candidates195second-pass queue1287AI analyses
86commits · 30 days
186commits · 60 days
609commits · 180 days
1247commits · 365 days
Backfill bands
Aug 5 → Feb 6405 seen5 candidatesComplete
Feb 6 → Jun 6665 seen28 candidatesComplete
Jun 6 → Jul 689 seen4 candidatesComplete
Jul 6 → Aug 569 seen0 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

67/100 average clarity
322Strong · 80–100
655Adequate · 60–79
391Thin · 40–59
31Opaque · 0–39
1security candidate with opaque commit messaging
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Olaoluwa Osuntokun20942204474
Elle Mouton26832268167
ziggie44416413165
Yong28513171
LNBiG111173
Jared Tobin909171
bitromortac661153071
yyforyongyu83861068
Erick Cestari26726070
Andras Banki-Horvath11311072
Gijs van Dam33230073
ziggieXXX2026070
Analysis record

Published AI watches

Last scanned 24 minutes ago

Moderate 62 AI analysisMessage 58 · Thin
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11212 from ziggie1984/disable-legacy-channels

This change stops LND from opening new Lightning channels using the old 'legacy' commitment format. The legacy format makes it harder to recover funds if something goes wrong, because the money owed to you is tied to a secret key that chan…

Prevents opening new channels with the legacy commitment type, whose tweaked to_remote output complicates data-loss recoveryCloses a negotiation path where an empty channel_type TLV bypassed feature checks and forced a legacy channelAdds explicit RPC and wire rejection with a dedicated error code
112cb5f3by ziggieXXX+265−4716 files
Vendor flagged security relevance
Moderate 56 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11223 from gijswijs/legacy-dust-retribution-fix

This update fixes a bug in how LND handles old-style punishment transactions when a channel partner tries to cheat. Previously, tiny (dust) HTLCs were left as blank placeholder entries in the punishment data, which could cause the node to …

nil-pointer dereference risk in breach retribution pathlegacy revocation log handling inconsistency with modern formatdefensive hardening added for trimmed/dust HTLCs
500ca51fby ziggieXXX+168−146 files
No security note in commit
Moderate 62 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11190 from Roasbeef/zpay32-reject-duplicate-payment-hashes

This change tightens how LND reads Lightning invoices (BOLT 11). Previously, if an invoice contained more than one payment hash field, LND would silently keep the first one and ignore the rest. Now it rejects the invoice entirely. The rele…

Behavior change from 'use first duplicate field' to 'reject duplicate fields'New error type ErrDuplicatePaymentHash returned on duplicate payment hash fieldsMalformed/unsupported-length duplicate payment hash now treated as duplicate and rejected
86306f89by Yong+147−106 files
No security note in commit
Moderate 62 AI analysisMessage 98 · Strong
LL Lightning LabsLND BitcoinLightning Network

zpay32: reject duplicate payment hash fields

This change tightens how LND reads Lightning invoices. Previously, if an invoice contained more than one payment hash field, LND would silently keep the first valid one and ignore the rest. Now it rejects such invoices outright. This preve…

Behavioral change from silent first-field acceptance to explicit rejection of duplicate payment hash fieldsPrevents invoice parsing from depending on field ordering when multiple payment hashes are presentCovers malformed first field + valid second field, closing a potential bypass
e2f27063by Olaoluwa Osuntokun+147−106 files
Vendor flagged security relevance
Moderate 53 AI analysisMessage 58 · Thin
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11132 from yyforyongyu/task-11129-pong

This change fixes how LND answers network 'ping' messages from other Lightning nodes. Previously, LND would sometimes silently ignore valid pings to limit reply traffic, which violates the Lightning protocol (BOLT 1) and could make a peer …

Protocol compliance fix: BOLT 1 requires a Pong for every valid PingRemoved silent suppression of Pong replies that could cause peer timeout/misbehaviorUnified rate limiting now accounts for amplification bandwidth, not just ping count
d3d1f1d0by Olaoluwa Osuntokun+274−1715 files
Vendor flagged security relevance
Low 33 AI analysisMessage 90 · Strong
LL Lightning LabsLND BitcoinLightning Network

itest: stop creating legacy channels

This commit updates LND's integration tests to stop using an obsolete 'legacy' channel type and adds a test confirming that LND now rejects that legacy type. The commit message says the real fix is elsewhere in the same pull request: previ…

Deprecated commitment format (legacy) is now rejected by RPCTest added to verify legacy channel type is refusedUnused legacy node configuration flag removed
03d8b09dby ziggie+24−85 files
No security note in commit
Moderate 60 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11198 from gijswijs/amp-setlocal-reconstruction-fix

This change fixes a bug in LND's handling of AMP (Atomic Multi-Path) payments. Previously, if one partial payment set failed to reconstruct its secret preimage, the entire invoice was canceled, including unrelated partial payment sets from…

Denial-of-service against reusable static AMP invoices by causing unrelated accepted HTLC sets to be canceledIncorrect invoice state transition from set-local failure to global invoice cancellationAvailability impact on multi-payer AMP invoice scenarios
88959aecby Olaoluwa Osuntokun+155−44 files
Vendor flagged security relevance
Low 29 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11200 from ziggie1984/build-go-1.27.1

This commit updates the Go programming language version used to build LND from 1.25.13/1.26.6 to 1.26.8 (language version) and 1.27.1 (toolchain). It also regenerates many automatically generated RPC files and adjusts linter settings. The …

Go version bump may indirectly address unlisted runtime/standard-library security fixesLarge regenerated protobuf files suggest dependency/toolchain refresh rather than logic changeLinter configuration expanded to suppress new checks, consistent with a toolchain upgrade
ef4820e5by Olaoluwa Osuntokun+4932−412670 files
No security note in commit
Informational 15 AI analysisMessage 92 · Strong
LL Lightning LabsLND BitcoinLightning Network

build: adopt focused golangci-lint v2.13 checks

This commit is a routine build-maintenance change. It updates the project's Go linter configuration to a newer version and fixes the resulting style warnings: a WebSocket header spelling and several documentation comments that didn't start…

bada7ea3by ziggie+27−1911 files
No security note in commit
Informational 15 AI analysisMessage 68 · Adequate
LL Lightning LabsLND BitcoinLightning Network

lnrpc: regenerate protos with Go 1.27

This commit is a housekeeping change that regenerates automatically generated RPC binding files using a newer Go compiler version. The only differences are in code comments (doc-comment formatting), not in actual program logic or API behav…

dd523108by ziggie+4501−369826 files
No security note in commit
Informational 20 AI analysisMessage 100 · Strong
LL Lightning LabsLND BitcoinLightning Network

build: fix Go 1.27 compatibility

This commit is a routine build-and-test maintenance patch to make the LND codebase compile and pass tests with the upcoming Go 1.27 release. It upgrades the project's custom linter tool, refreshes many indirect tool dependencies, adjusts o…

No production code changesNo vulnerability fix or CVE reference presentDependency-only refresh in tools module (development tooling)
6b54a387by ziggie+365−3706 files
No security note in commit
Informational 15 AI analysisMessage 80 · Strong
LL Lightning LabsLND BitcoinLightning Network

build: bump Go language and toolchain versions

This commit is a routine maintenance update that changes which version of the Go programming language is used to build the lnd project. It does not change any application logic, fix a bug, or address a security vulnerability. The project i…

b1f9ca66by ziggie+39−3930 files
No security note in commit
Moderate 60 AI analysisMessage 83 · Strong
LL Lightning LabsLND BitcoinLightning Network

invoices: cancel only the failing AMP set on reconstruction failure

This commit fixes a bug in LND's invoice handling for reusable AMP (Atomic Multi-Path) invoices. Previously, if one payment set failed to reconstruct its preimage, the entire invoice was canceled, even though other valid payment sets on th…

Denial-of-service-like availability impact: a malicious or buggy payer could cause a whole reusable AMP invoice to be canceled, blocking legitimate concurrent payersSet-local failure incorrectly escalated to invoice-global cancellationRegression test added for concurrent-set survival after reconstruction failure
d74ab6faby Gijs van Dam+141−42 files
No security note in commit
Informational 15 AI analysisMessage 68 · Adequate
LL Lightning LabsLND BitcoinLightning Network

bolt12: describe the lnwire dependency

This is a documentation-only change. A package comment was updated to accurately describe that the bolt12 codec library does depend on LND's lnwire package for low-level message types, while clarifying it still does not interact with the r…

5f53171dby bitromortac+3−21 file
No security note in commit
Moderate 60 AI analysisMessage 91 · Strong
LL Lightning LabsLND BitcoinLightning Network

bolt12: cover the amount overflow guard

This commit adds a test to ensure that when a BOLT 12 invoice is validated against a request, the multiplication of the offer amount by the requested quantity cannot overflow and wrap around to zero. Without this guard, a malicious or malf…

Integer overflow / wraparound in amount calculationMissing test coverage for security-critical branchBOLT 12 invoice amount validation
3c8e2bcbby bitromortac+47−01 file
Vendor flagged security relevance
Low 34 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11061 from bitromortac/2604-bolt12-1f

This commit adds the missing cryptographic signature layer for BOLT 12 offers in LND. It builds a Merkle tree from the message fields, signs that tree with a BIP-340 Schnorr signature, and now rejects invoice requests and invoices whose si…

Adds BIP-340 Schnorr signature verification for BOLT 12 invoice_request and invoice messagesMerkle tree commits to canonical re-encoded TLV records; non-minimal feature/amount encodings now rejected to preserve byte-exactnessSignature TLV type 240 and reserved range 240-1000 excluded from the signed Merkle root
1049d301by Yong+2076−7815 files
Vendor flagged security relevance
Low 35 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11125 from bhandras/codex/reorg-aware-output-lock-20260825

This commit adds a new optional wallet feature to LND that lets users lock UTXOs until the transaction spending them reaches a chosen confirmation depth, instead of relying on a wall-clock timeout. It is a feature addition with safety chec…

New RPC fields release_after_spend_confs and confirmed_spend_height added to LeaseOutput and FundPsbtCustom lock ID enforced as required for confirmation-controlled FundPsbt leases; all-zero and reserved internal IDs rejectedCapability check (ResolveOutputLeaser) prevents silent downgrade to time-only lease when confirmation control is requested
80dde144by Yong+1293−10021 files
No security note in commit
Informational 19 AI analysisMessage 58 · Thin
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #10812 from ziggie1984/chanstate-kv-store-move

This commit is a large internal code reorganization for the LND Lightning node. It moves channel state storage logic from the `channeldb` package into a new `chanstate` package, while keeping the same database keys, serialization formats, …

Large refactoring with no change to cryptographic or consensus-critical logicCodec serialization moved verbatim to new package; wire format unchangedDatabase bucket keys and TLV record types preserved
62b0a073by Olaoluwa Osuntokun+3923−310924 files
No security note in commit
Low 25 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #10804 from GeorgeTsagk/close-immediately-itest-lnd-7c38

This change fixes a data-handling bug in LND's channel-opening code. When opening a Lightning channel using an optional 'auxiliary funding controller' (used for custom channel types such as Taproot Assets), the funding manager was previous…

Data-correctness fix in funding handshake: negotiated channel configs now exposed to auxiliary funding controllerAuxiliary funding controller receives incomplete channel state before patch, complete state after patchNo explicit security claim, CVE, or advisory referenced in commit or supplied materials
1e127653by Olaoluwa Osuntokun+291−254 files
No security note in commit
Moderate 60 AI analysisMessage 88 · Strong
LL Lightning LabsLND BitcoinLightning Network

bolt12: verify invoice_request and invoice signatures on read

This change makes LND's BOLT 12 invoice and invoice-request reader actually check that the digital signature is valid, instead of only checking that a signature field exists. Before, an attacker could craft or modify a BOLT 12 message and …

Missing cryptographic verification on parsed BOLT 12 messages replaced with BIP-340 Schnorr signature verificationReader accepted any 64-byte placeholder signature before the patchNew negative tests verify rejection of wrong-signer and tampered Merkle-root fields
aa8bd19fby bitromortac+272−723 files
Vendor flagged security relevance
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

AI review queuedlnwallet/chancloser: fix flaky test assertionsby Olaoluwa Osuntokun · fa9163ac · Mar 27, 2026 · 1 fileMessage 78 · AdequateInformational 15Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: fix flaky test assertions

Restore the defaultTimeout constant (500ms) that was lost during the
PR's commit squash, where the hardcoded 10ms replaced it. The 10ms
value was too tight and caused timeouts under -race -count=N.

Also fix assertSingleRemoteRbfIteration to consume both iteration
transitions in a single assertStateTransitions call. When
iteration=true, the state machine emits two ClosingNegotiation
transitions from a single event (via internal events). Making two
separate assertStateTransitions calls races with the "no more states"
check, which could drain the second transition before the second
assertion consumed it.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit fixes flaky test code in the Lightning Network Daemon (LND) project. It restores a longer timeout (500ms instead of 10ms) in a test helper and adjusts how test assertions consume state transitions to avoid race conditions during testing. There is no change to production code or user-facing behavior, and no security issue is present.

Security candidatemulti: wire taproot RBF support throughout the stackby Olaoluwa Osuntokun · 85adad75 · Mar 27, 2026 · 2 filesMessage 73 · AdequateLow 34Details
Commit message · Olaoluwa Osuntokun

multi: wire taproot RBF support throughout the stack

In this commit we, integrate the taproot RBF cooperative close
functionality throughout the LND stack. This includes updating
protocol configuration and peer connection handling to support
the new taproot closing flow.

The changes wire through the taproot channel detection, nonce
exchange during shutdown, and proper handling of the enhanced
wire protocol messages in the peer layer. This completes the
integration of taproot RBF cooperative close functionality,
providing a complete alternate closing path for taproot channels
that leverages MuSig2 signatures and implements proper nonce
rotation for secure RBF scenarios.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundaryparser or protocol path
AI analysis · Low 34/100

This commit enables a new, more flexible way for taproot Lightning channels to close cooperatively. Previously, taproot channels had to fall back to an older close path even when the new RBF-based cooperative close feature was enabled. The change removes that restriction and adds the necessary nonce-exchange logic so taproot channels can use the modern close flow. It is a feature-completion patch rather than a clear-cut security fix, but because it touches cryptographic state setup for channel closing, it could affect safety if the new path has latent bugs.

AI review queuedlnwallet/chancloser: address PR review commentsby Olaoluwa Osuntokun · 1a50eee1 · Mar 27, 2026 · 2 filesMessage 90 · StrongInformational 24Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: address PR review comments

Fix several issues raised in PR review:
- Use safe type assertion in createClosingSigMessage to avoid panic if
localSig is not *MusigPartialSig.
- Fix typo "taprotot" -> "taproot" in comment.
- Remove unnecessary type argument in NewTaprootSigType.
- Simplify nested if to single condition for taproot nonce generation.
- Fix typo "once the no updates" -> "once there are no updates" in
test comments.
- Move misplaced TestRbfCloseClosingNegotiationLocal doc comment to
the correct function definition.

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 or wallet pathsecond-pass: broader security terminologysecond-pass: security-sensitive path
AI analysis · Informational 24/100

This commit is a small code cleanup in LND's cooperative channel-closing logic. The only behavior change that matters for security is replacing a risky type assertion with a safe one, so the program returns an error instead of crashing if an unexpected signature type is passed. The rest of the changes are typo fixes, comment moves, and minor simplifications. There is no evidence this fixes an actively exploitable vulnerability.

Security candidatelnwallet/chancloser: remove dead code and wrap errorsby Olaoluwa Osuntokun · ed1e5411 · Mar 27, 2026 · 1 fileMessage 73 · AdequateInformational 17Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: remove dead code and wrap errors

Remove the redundant `remoteMusig \!= nil` check inside the
`IsTaproot()` guard in sendShutdownEvents. Since IsTaproot() requires
both LocalMusigSession AND RemoteMusigSession to be non-nil, the nested
nil check can never be false.

Also wrap bare `return nil, err` with context in LocalOfferSent and
RemoteCloseStart ProcessEvent methods for prepareClosingSignatures,
CompleteCooperativeClose, and createLocalCloseeSignature calls.

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 · Informational 17/100

This is a small code cleanup in LND's cooperative channel-closing logic. It removes a redundant safety check that could never fail and adds more descriptive error messages when closing a Lightning channel. There is no direct security vulnerability being fixed, and no exploit path is introduced or removed.

Security candidatelnwallet/chancloser: move nonce rotation to LocalOfferSentby Olaoluwa Osuntokun · d7302cfc · Mar 27, 2026 · 2 filesMessage 88 · StrongInformational 12Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: move nonce rotation to LocalOfferSent

Move the RemoteCloseeNonce update from updateAndValidateCloseTerms to
LocalOfferSent.ProcessEvent. This keeps updateAndValidateCloseTerms
focused on close term validation, and makes the nonce rotation point
explicit in the state machine — it happens when processing the
LocalSigReceived event, alongside signature extraction.

Update TestNextCloseeNonceStorageFromClosingSig to verify that
updateAndValidateCloseTerms no longer modifies RemoteCloseeNonce.

88/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarydefensive validationsigning or wallet path
AI analysis · Informational 12/100

This is a small internal code cleanup in LND's cooperative channel-closing logic. It moves where a cryptographic nonce is updated from one function to another within the same state machine, with no indication of a security bug or user-facing behavior change. The change is framed by the author as improving code organization, not fixing a vulnerability.

Security candidatelnwire: add taproot signatures support to closing_complete messageby Olaoluwa Osuntokun · 0ce026af · Mar 27, 2026 · 9 filesMessage 88 · StrongLow 46Details
Commit message · Olaoluwa Osuntokun

lnwire: add taproot signatures support to closing_complete message

In this commit we, add support for taproot partial signatures with
nonces to the ClosingComplete message. This is the foundation for
taproot RBF cooperative channel closing, implementing the JIT nonce
pattern required for the modern taproot closing flow.

The changes include a new TaprootClosingSigs struct that mirrors the
existing ClosingSigs but uses PartialSigWithNonce for taproot channels.
The decoding and encoding functions are updated to handle both regular
ECDSA signatures and taproot partial signatures. For taproot channels,
the TaprootClosingSigs field is populated while ClosingSigs remains
empty, maintaining backward compatibility.

We also fix a minor typo in the comment for CloserNoClosee field
(clsoee -> closee).

lnwire: add taproot partial signatures support to closing_sig message

In this commit we, extend the ClosingSig message to support taproot
partial signatures for the RBF cooperative close flow. The ClosingSig
message is sent by the closee in response to a ClosingComplete message.

For taproot channels, we add TaprootPartialSigs which contains partial
signatures without nonces since the remote party already knows our
nonce from the previous ClosingComplete message. We also add a
NextCloseeNonce field for RBF iterations, allowing the closee to
provide a new nonce for the next potential RBF round.

The decoding and encoding functions are updated to handle both regular
signatures and taproot partial signatures, maintaining backward
compatibility with existing non-taproot channels while enabling the
advanced taproot RBF flow.

lnwire: add shutdown nonce support for taproot channels

In this commit we, add support for closee nonces in the Shutdown
message to enable taproot RBF cooperative channel closing. The
ShutdownNonce field allows taproot channels to exchange the initial
nonces required for the MuSig2 signing process during cooperative
closure.

This nonce represents the closee nonce that the remote party will use
when they act as the closer in the RBF flow. The nonce is transmitted
as part of the shutdown flow and is essential for the JIT nonce pattern
used in the modern taproot closing protocol.

The changes maintain backward compatibility as the ShutdownNonce field
is optional and only used for taproot channels that support the
enhanced RBF flow.

lnwire: update test message with taproot signature fields

In this commit we, update the test message utilities to include the new
taproot signature fields added to ClosingComplete and ClosingSig
messages. This ensures the wire protocol tests properly exercise the
new taproot partial signature functionality.

chancloser: add taproot channel infrastructure and nonce state management

In this commit we, add the fundamental infrastructure for taproot RBF
cooperative channel closing. This includes adding taproot channel
detection, MuSig2 session management, and nonce state tracking
throughout the closing state machine.

Key additions include the IsTaproot method on Environment to detect
taproot channels based on the presence of MuSig sessions, and
LocalMusigSession/RemoteMusigSession fields for managing the different
signing contexts. We add NonceState tracking to maintain closee nonces
exchanged during the shutdown phase.

The SendShutdown and ShutdownReceived events are extended to carry
closee nonces for taproot channels, and we add proper error handling
for missing nonces in taproot shutdown messages. These changes provide
the foundation for the taproot-specific state transitions while
maintaining compatibility with existing non-taproot channels.

chancloser: implement taproot cooperative close state transitions

In this commit we, implement the complete taproot RBF cooperative close
state machine transitions. This is a comprehensive change that adds all
the necessary components for taproot channel closing support.

The implementation includes several key areas:

First, we add nonce management helpers including initLocalMusigCloseeNonce
and initRemoteMusigCloseeNonce for properly initializing MuSig2 sessions
with the appropriate closee nonces during the RBF flow.

Second, we implement signature extraction and validation helpers including
partialSigToWireSig for converting partial signatures to wire format, and
extractTaprootSigAndNonce, extractSigAndNonce, and validateAndExtractSigAndNonce
for handling both taproot and regular signatures with proper validation.

Third, we add comprehensive signature encoding logic with encodeClosingSignatures
that creates appropriate signature structures for both channel types, and helper
functions like processRemoteTaprootSig, createLocalCloseeSignature, and
createClosingSigMessage for managing the complex taproot signing flow.

Fourth, we extend the shutdown validation logic to require nonces for
taproot channels and update all state transitions to properly handle
nonce exchange, MuSig2 session initialization, and the dual signature
paths for taproot vs non-taproot channels.

Finally, we add signature preparation logic with prepareClosingSignatures
and extraction helpers like extractSigAndNonceFromComplete that handle
the complex musig signature combination required for taproot channels
while maintaining compatibility with existing ECDSA signatures.

The changes maintain backward compatibility with existing non-taproot
channels while enabling the full taproot RBF cooperative close flow
with proper nonce rotation and signature handling.

chancloser: add taproot test infrastructure and test cases

In this commit we, extend the RBF cooperative close test suite to
support taproot channels. This includes adding schnorr signature
test constants, taproot channel test helpers, and comprehensive
test coverage for the taproot RBF flow.

The changes add localSchnorrSig and remoteSchnorrSig test constants
to mirror the existing ECDSA signatures, and include proper imports
for musig2, chainhash, and lnwallet to support the taproot testing
infrastructure.

The test modifications ensure that both taproot and non-taproot
channels are properly tested throughout the RBF cooperative close
state machine, validating the dual signature handling paths and
nonce management logic introduced in the main implementation.

chancloser: update test utilities and message mapping for taproot

In this commit we, update the chancloser test utilities and message
mapping functions to properly handle the new taproot-specific fields
in the RBF cooperative close flow.

The changes ensure that test harnesses and message mapping functions
are aware of the taproot signature fields and nonce handling required
for the extended wire protocol support. This maintains test coverage
for both existing non-taproot functionality and the new taproot
capabilities.

88/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarydefensive validationsigning or wallet path
AI analysis · Low 46/100

This commit adds support for taproot (MuSig2) cooperative channel closing in LND's RBF close protocol. It introduces new wire message fields for taproot partial signatures and nonces, updates the state machine to handle both ECDSA and taproot paths, and adds tests. There is no direct evidence in the commit message or diff that this fixes a known security vulnerability; it appears to be a feature implementation for taproot channel compatibility.

AI review queuedlnwallet/chancloser: split taproot/non-taproot test helpersby Olaoluwa Osuntokun · 4f669cef · Mar 27, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: split taproot/non-taproot test helpers

Split testSendOfferRbfIterationLoop, testRecvOfferRbfLoopIterations,
and testSendOfferIterationNoDust into separate taproot and non-taproot
variants. This removes the isTaproot bool parameter and inlines each
branch, making the tests easier to read and maintain.

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
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit is a pure test-code refactoring. It takes three helper functions in a Go test file and splits each into two versions: one for non-taproot channels and one for taproot channels. The behavior being tested is unchanged; only the way the tests are organized is different. There is no production code change and no security fix or vulnerability introduced.

AI review queuedlnwallet/chancloser: fix comments and wrap errors for debuggingby Olaoluwa Osuntokun · e2a91b23 · Mar 27, 2026 · 2 filesMessage 83 · StrongInformational 15Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: fix comments and wrap errors for debugging

Fix incorrect comment about PartialSigWithNonce nonce - it's the JIT
closer nonce for current session verification, not a closee nonce for
future RBF. Wrap errors from validateSigFields and CreateCloseProposal
with additional context to aid debugging.

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 validationsigning or wallet pathsecond-pass: near security thresholdsecond-pass: broader security terminologysecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only cleans up comments and adds more descriptive error messages in the cooperative channel-closing code. It does not change any security logic or fix a vulnerability.

Security candidatelnwallet/chancloser: fix MuSig2 nonce reuse across RBF roundsby Olaoluwa Osuntokun · f4fff172 · Mar 27, 2026 · 9 filesMessage 78 · AdequateHigh 82Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: fix MuSig2 nonce reuse across RBF rounds

MusigChanCloser.ClosingNonce() cached the local nonce and returned
the same one on subsequent calls. Since each RBF round creates a new
MuSig2 session via ProposalClosingOpts() but passes the same SecNonce,
the btcd library's per-session nonce reuse guard was bypassed (fresh
Session each round). Signing different closing transactions (different
fees/sighashes) with the same secret nonce enables private key
extraction via simple linear algebra on the partial signatures.

Fix by adding ClearNonce() to the MusigSession interface and calling
it after each signing round completes, forcing fresh nonce generation
on every RBF iteration. Also fix a rebase issue where
updateAndValidateCloseTerms was not extracting NextCloseeNonce from
ClosingSig messages for subsequent RBF rounds.

lnwallet/chancloser: fix MuSig2 nonce reuse across RBF rounds

MusigChanCloser.ClosingNonce() cached the secret nonce and returned
the same one across RBF rounds. Since each round creates a new
MuSig2 session via ProposalClosingOpts() but passes the same
SecNonce, signing different closing transactions with different
sighashes enables private key extraction.

Fix this by:

1. Storing the full MusigPartialSig from LocalCloseStart in the
LocalOfferSent state, eliminating the second CreateCloseProposal
call in prepareClosingSignatures. This was also flagged in PR
review as wasteful.

2. Adding InvalidateNonce() to the MusigSession interface. After
the closer round completes (CompleteCooperativeClose), the closer
nonce is invalidated so the next RBF round generates fresh. For
the closee, the nonce is invalidated before generating the next
closee nonce in createClosingSigMessage.

78/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
secret or key materialsigning boundarydefensive validationnonce handlingsigning or wallet path
AI analysis · High 82/100

This patch fixes a critical cryptographic bug in LND's taproot cooperative channel close feature. During RBF (fee-bump) rounds, the same secret random number (nonce) was being reused to sign different closing transactions. In MuSig2/taproot signing, reusing a secret nonce with different messages lets an attacker who sees the partial signatures recover your private key. The fix forces a fresh nonce for every RBF round and also stores the partial signature so it isn't regenerated (which would also reuse the nonce).

Security candidatelnwire: reject messages with both regular and taproot signaturesby Olaoluwa Osuntokun · d4da3502 · Mar 27, 2026 · 2 filesMessage 73 · AdequateLow 47Details
Commit message · Olaoluwa Osuntokun

lnwire: reject messages with both regular and taproot signatures

Add decode-time validation to closing_complete and closing_sig that
rejects messages containing both regular ECDSA and taproot partial
signatures. This provides defense-in-depth rather than relying solely
on state machine validation.

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 47/100

This change adds an extra safety check when LND receives certain channel-closing messages. It now rejects messages that contain both old-style ECDSA signatures and new taproot-style signatures at the same time. The developers describe this as 'defense-in-depth,' meaning it is an extra guard rail rather than a fix for a known active attack. It makes the protocol stricter so a malformed or malicious message cannot carry both signature types.

AI review queuedlnwallet/chancloser: fix rbf close docsby Olaoluwa Osuntokun · 763fea92 · Mar 27, 2026 · 1 fileMessage 45 · ThinInformational 15Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: fix rbf close docs

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing or wallet pathdocumentation-only discountsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only updates documentation for the RBF (Replace-By-Fee) cooperative channel close protocol in LND. It corrects which nonces are sent and how they are combined during signing, but does not change any actual code, message formats, or cryptographic behavior. There is no security vulnerability present in the diff itself.

Security candidatelnwallet/chancloser: fix local session nonce rotation bugby Olaoluwa Osuntokun · ca60f9c3 · Mar 27, 2026 · 2 filesMessage 65 · AdequateModerate 59Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: fix local session nonce rotation bug

We weren't properly using the latest closee nonce from the remote party
when signing.

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Moderate 59/100

This commit fixes a bug in LND's cooperative channel-closing code for Taproot (MuSig2) channels. The wrong order of operations meant the wallet sometimes tried to create a closing signature before it had loaded the remote party's latest nonce, which could cause the cooperative close to fail with a 'final signature is invalid' error. The patch reorders the steps so the nonce is loaded first, and renames a helper function to make clear which nonce it is handling. A new test was added to enforce the correct order.

AI review queuedlnwallet/chancloser: use AND for IsTaproot check, use partialSigToWireSigby Olaoluwa Osuntokun · a0cf1466 · Mar 27, 2026 · 3 filesMessage 73 · AdequateModerate 59Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: use AND for IsTaproot check, use partialSigToWireSig

Change IsTaproot() from OR to AND: both LocalMusigSession and
RemoteMusigSession must be set to consider the channel taproot. This
prevents panics from nil session access when only one session is
initialized.

Also use partialSigToWireSig helper for consistency in
extractSigAndNonceFromComplete instead of inline conversion.

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 · Moderate 59/100

This commit fixes a logic bug in LND's cooperative channel-closing code. The program previously treated a channel as a modern 'taproot' channel if either side's special signing session was set, but it really needs both. When only one was set, the code could later try to use a missing session and crash. The patch also swaps an inline signature conversion for an existing helper to keep the code consistent. It is a defensive bug fix that prevents a panic rather than a clear remote-exploitable vulnerability.

Lower-prioritydocs: add taproot RBF coop close to 0.21.0 release notesby Olaoluwa Osuntokun · 55854e1d · Mar 27, 2026 · 1 fileMessage 62 · AdequateInformational 15Details
Commit message · Olaoluwa Osuntokun

docs: add taproot RBF coop close to 0.21.0 release notes

62/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
documentation-only discount
AI analysis · Informational 15/100

This commit only updates the release notes document for version 0.21.0. It describes a new feature—taproot channel support for an RBF-based cooperative close protocol—but makes no code changes. There is no security issue in the commit itself.

AI review queuedchancloser: update RBF close to match current flowby Olaoluwa Osuntokun · 7197fd21 · Mar 27, 2026 · 1 fileMessage 50 · ThinInformational 15Details
Commit message · Olaoluwa Osuntokun

chancloser: update RBF close to match current flow

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing or wallet pathdocumentation-only discountsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only updates a Markdown design document (rbf_close.md) describing how RBF (Replace-By-Fee) cooperative channel closes should handle MuSig2 nonces. It does not change any source code, cryptographic operations, network behavior, or state machine logic. The changes clarify documentation wording, add a table of helper functions, and correct file references. There is no security-relevant code change to assess.

Security candidatechancloser: update RBF close documentation for taproot supportby Olaoluwa Osuntokun · 57def3bc · Mar 27, 2026 · 1 fileMessage 78 · AdequateInformational 15Details
Commit message · Olaoluwa Osuntokun

chancloser: update RBF close documentation for taproot support

In this commit we, update the RBF cooperative close documentation to
comprehensively cover the taproot channel closing flow. The documentation
now explains the JIT nonce pattern, asymmetric signature roles, and the
complete nonce exchange protocol for taproot channels.

Key additions include detailed explanations of how nonces flow through
the RBF process, the distinction between closer and closee roles, and
the specific wire message extensions for PartialSigWithNonce and
NextCloseeNonce fields. The documentation also covers validation
requirements and implementation notes specific to taproot channels.

This documentation provides a complete reference for understanding
and implementing the enhanced taproot RBF cooperative close protocol.

78/100 · AdequateMessage clarity
✓ Specific, 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 pathdocumentation-only discount
AI analysis · Informational 15/100

This commit only adds documentation to a markdown file describing how taproot channel cooperative closes work in LND. It changes no source code, no configuration, and no executable behavior. There is no security issue in the commit itself.

Security candidatemulti: fix nonce handling bugby Olaoluwa Osuntokun · 34a86ca8 · Mar 27, 2026 · 3 filesMessage 95 · StrongModerate 59Details
Commit message · Olaoluwa Osuntokun

multi: fix nonce handling bug

In this commit, we fix a nonce handling bug. The bug was unnoticed until
interop testing due to some inadvertent mutation. Before this commit, in
peer/brontide.go, we used the _same_ instance of the musig2 chan closer,
which masked the bug.

The issue was that we would attempt to generate a siganture for the
remote party _before_ we had applied their JIT nonce to our remote (used
to sign their close txn) musig session.

We first created a new test to confirm the issue (in peer, as it needed
to be in order to avoid a circular dep test). Without these changes, the
test fails.

The fix is two fold:
1. Create two independent musig2 chan closers.
2. Update the ordering to apply their nonce before we generate a
signature.

95/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarysigning or wallet path
AI analysis · Moderate 59/100

This commit fixes a bug in LND's cooperative channel-closing code for Taproot channels. When two parties try to close a Lightning channel together, the code accidentally used the same internal helper for both sides and tried to create a signature before the other side's one-time 'nonce' had been applied. The fix creates two separate helpers and reorders the steps so the nonce is applied before signing. The commit message and new test say the bug was hidden in normal use because a shared object masked the ordering problem, and it only surfaced during interoperability testing.

Security candidatelnwallet/chancloser: address lint and PR review feedbackby Olaoluwa Osuntokun · d9284abe · Mar 27, 2026 · 7 filesMessage 85 · StrongInformational 17Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: address lint and PR review feedback

Fix all lint issues across the taproot RBF coop close changes:

- Fix line length violations (ll) by wrapping long lines and adding
nolint:ll where wrapping would hurt readability.
- Fix nlreturn: add blank lines before return statements.
- Fix misspell: correct "siganture" typos.
- Fix forcetypeassert: add checked type assertions.
- Fix nonamedreturns: remove named returns from function signatures.
- Fix usetesting: replace context.Background() with t.Context().
- Fix unused: remove unused remoteSchnorrSig variable.
- Fix whitespace: add newlines after multi-line func signatures.
- Fix gocritic appendAssign warning.
- Fix gci: correct import ordering.

Also address PR review comments from @erickcestari:

- Remove nonce cache in ClosingNonce() to prevent future footguns.
- Rename extractSigAndNonce to extractSigAndNonceFromClosingSig.
- Rename extractSigAndNonceFromComplete to
extractSigAndNonceFromClosingComplete with channel type validation.
- Replace env.RemoteMusigSession \!= nil with env.IsTaproot().
- Swap manual mocks to mock.Mock in musig_nonce_order_test.go.

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 boundarysigning or wallet path
AI analysis · Informational 17/100

This commit is a follow-up cleanup patch for a larger feature adding RBF (Replace-By-Fee) cooperative channel closes for Taproot channels in LND. It contains no direct security fixes. The changes are almost entirely code-style fixes (line length, blank lines, spelling, import ordering), test-only refactors, and minor defensive tweaks such as adding checked type assertions and removing a nonce cache that could be a 'footgun' in the future. The one substantive behavior change—removing the nonce cache—is described by the author as preventing future mistakes rather than fixing an active vulnerability.

AI review queuedlnwallet/chancloser: revamp sig type parsing to be spec compliantby Olaoluwa Osuntokun · 1d2fa8dc · Mar 27, 2026 · 4 filesMessage 73 · AdequateModerate 58Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: revamp sig type parsing to be spec compliant

In this commit, we revise the sig type parsing to make the control flow
clearer, and also to be spec compliant. Before we would error out if
_both_ the CloserNoClosee and the CloserAndClosee fields were set.

lnwallet/chancloser: fix priority ordering for rbf sig parsing

We need to parse the sigs in a strict order, as it's possible for a
party to send more than one siganture.

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 · Moderate 58/100

This commit fixes how LND parses signature fields during RBF (fee-bumping) cooperative channel closes. Previously, the code rejected valid protocol messages that contained both a 'closer-only' and a 'both-parties' signature, and it didn't always pick the right signature in the order required by the Lightning spec. The change makes signature selection follow the BOLT specification strictly, which prevents a peer from accidentally or deliberately stalling or breaking a cooperative close by sending a spec-compliant message.

Lower-priorityrouterrpc: implement DeleteForwardingHistory RPC handlerby ziggie · 66f64c2b · Mar 27, 2026 · 4 filesMessage 95 · StrongLow 41Details
Commit message · ziggie

routerrpc: implement DeleteForwardingHistory RPC handler

In this commit, we implement the server-side handler for the
DeleteForwardingHistory RPC, connecting the proto definition to the
database layer through the ForwardingLogDB interface on RouterBackend.

The handler resolves the time specification from the request oneof: an
absolute Unix timestamp is used directly, while a relative duration
string is parsed via parseDuration and resolved against the current
clock time. We use the injected clock (RouterBackend.Clock) rather than
time.Now to keep the handler testable.

A configurable minimum age guard (MinFwdHistoryAge, defaulting to 1h)
prevents accidental deletion of recent events. The minimum age can be
overridden via --routerrpc.min-fwd-history-age for environments such as
integration tests that need a shorter threshold.

The context is threaded through to DeleteForwardingEvents so that client
cancellation or deadline expiry aborts the deletion between batches.
Batches already committed at cancellation time are permanent, but the
operation is safe to re-run since deletion is idempotent.

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
AI analysis · Low 41/100

This commit adds a new RPC command that lets an authenticated user permanently delete old Lightning Network forwarding records from the database. It includes safety guards: the cutoff time must not be before 1970, and it must be at least one hour in the past (or a dev/test override). The change is mostly defensive, but it introduces a powerful deletion capability that could be abused by anyone who steals the right admin/macaroon credentials or exploits a caller with that permission.

Lower-prioritychanneldb: add tests for DeleteForwardingEventsby ziggie · 1c80f589 · Mar 27, 2026 · 1 fileMessage 78 · AdequateInformational 15Details
Commit message · ziggie

channeldb: add tests for DeleteForwardingEvents

In this commit, we add test coverage for the new DeleteForwardingEvents
method. The tests cover basic deletion, partial deletion by time range,
batch processing across multiple transactions, idempotency, empty
database handling, and exact boundary conditions.

Property-based tests using the rapid package validate key invariants
across randomized inputs: correct event counts, fee calculation
accuracy, time boundary enforcement, and idempotent behaviour.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
defensive validation
AI analysis · Informational 15/100

This commit only adds new automated tests for an existing database cleanup feature called DeleteForwardingEvents. It does not change any production code, so it cannot introduce a security vulnerability or fix one directly. The tests verify that old forwarding records are deleted correctly, in batches, and that the operation is idempotent.

Lower-priorityrouterrpc: add DeleteForwardingHistory to Router protoby ziggie · 9f787790 · Mar 27, 2026 · 7 filesMessage 73 · AdequateLow 36Details
Commit message · ziggie

routerrpc: add DeleteForwardingHistory to Router proto

In this commit, we define the DeleteForwardingHistory RPC in the Router
sub-server protocol and regenerate all derived Go stubs, JSON bindings,
and Swagger documentation.

The RPC uses a oneof for time specification, allowing callers to provide
either an absolute Unix timestamp (delete_before_time) or a relative
duration string (delete_before_duration, e.g. "-30d", "-1M"). The
response includes the count of deleted events and total fees earned in
millisatoshis, allowing operators to maintain financial records while
purging detailed routing surveillance data.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 36/100

This commit only adds a new RPC definition called DeleteForwardingHistory to the protocol buffer (proto) layer of LND's router sub-server. It does not include the actual server-side implementation that would perform the deletion, nor any access-control or authentication changes. The new RPC is intended to let node operators purge old forwarding records for privacy/data-retention purposes. Because it is just an interface change, it does not by itself create a vulnerability, but it does expose a future destructive operation over the existing API surface, which will need careful implementation and permission checks in later commits.

Lower-priorityrouterrpc: add parseDuration helper for relative time specsby ziggie · 67b68096 · Mar 27, 2026 · 2 filesMessage 73 · AdequateInformational 12Details
Commit message · ziggie

routerrpc: add parseDuration helper for relative time specs

In this commit, we introduce a parseDuration helper that extends Go's
standard time.ParseDuration with additional user-friendly time units:
d (days), w (weeks), M (months, averaged to 30.44 days), and y (years,
averaged to 365.25 days). Fractional values are supported for all units.

All durations must be negative to indicate "time ago" semantics, making
invocations like "-30d" or "-1M" unambiguous at the call site.

The standard library parser is tried first, so all existing Go duration
strings (e.g. "-24h", "-1.5h") continue to work as expected.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 12/100

This commit adds a new helper function that lets users write time spans in more human-friendly ways (like "-30d" for 30 days ago or "-1y" for one year ago). It is purely additive code with tests and does not change any existing behavior. There is no indication it fixes a security bug or introduces a vulnerability.

Lower-prioritychanneldb: use new for range directive in testcasesby ziggie · 92fea597 · Mar 27, 2026 · 1 fileMessage 50 · ThinInformational 15Details
Commit message · ziggie

channeldb: use new for range directive in testcases

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 15/100

This commit only updates test code to use a newer Go language feature ('for range' over integers). It does not change any production code or affect how the software behaves when running live. There is no security relevance.

Lower-prioritychanneldb: add DeleteForwardingEvents to ForwardingLogby ziggie · 842c054b · Mar 27, 2026 · 1 fileMessage 85 · StrongInformational 22Details
Commit message · ziggie

channeldb: add DeleteForwardingEvents to ForwardingLog

In this commit, we add a new DeleteForwardingEvents method to the
ForwardingLog that allows callers to permanently delete all forwarding
events with a timestamp at or before a specified cutoff time.

The deletion is performed in batches (default 10k, max 50k events per
transaction) to avoid holding large database locks that would block
concurrent operations. Each batch runs in its own transaction, so
other database operations can proceed between batches. Context
cancellation is checked at the start of each batch, allowing callers
to abort mid-way through a large deletion. Any batches already
committed are permanent and will not be rolled back on cancellation.

The method returns a DeleteStats struct containing the number of events
deleted and the sum of fees (AmtIn - AmtOut) earned during that period.
This allows operators to maintain aggregate financial records for
accounting purposes even after purging the detailed event history.

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 22/100

This commit adds a new database cleanup feature to LND that lets node operators permanently delete old payment forwarding records in batches. It is a routine data-management addition, not a fix for an active security flaw. The main risk is that any bug in how it selects or deletes records could accidentally erase important financial history, but the code appears careful: it copies keys before deleting, caps batch sizes, and checks for caller cancellation between batches.