LL
← All projectsLightning Labs

LND

Go implementation of a complete Lightning Network node.

BitcoinLightning NetworkNormal
Repository coverage

1241 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.

118security candidates168second-pass queue1236AI analyses
55commits · 30 days
171commits · 60 days
830commits · 180 days
1220commits · 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
279Strong · 80–100
564Adequate · 60–79
367Thin · 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 Osuntokun19940198474
Elle Mouton26832268167
ziggie41015408164
Jared Tobin909171
Erick Cestari26726070
bitromortac46546067
yyforyongyu55355065
saubyk15215070
Oli727057
Suheb323075
Yong323073
elnosh323071
Analysis record

Published AI watches

Last scanned 14 minutes ago

Moderate 59 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11023 from ellemouton/update-fee-log

This commit hardens how LND handles Lightning channel fee updates and mailbox message admission. It enforces the protocol rule that only the channel opener can send fee updates, prevents uncommitted fee updates from piling up in the update…

BOLT 2 role validation for UpdateFee senderReplacement of uncommitted fee updates to prevent log bloat and index gapsBounded mailbox wire-message queue (count and bytes)
7f56541dby Yong+750−138 files
No security note in commit
Moderate 57 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11019 from Roasbeef/coop-close-race-public

This update fixes two related problems in LND's cooperative channel-closing code. First, it eliminates a data race where the same state machine was being advanced by two different internal goroutines at once, which could cause crashes or i…

Data race in legacy cooperative close state machine driven concurrently by link and peer goroutinesMissing or inconsistent validation of remote delivery script when no upfront shutdown script is recordedpanic() in DustLimitForSize on unrecognized script sizes replaced with safe fallback
f4ae5656by Yong+463−609 files
Vendor flagged security relevance
Moderate 63 AI analysisMessage 58 · Thin
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11024 from ziggie1984/invoices-update-validation

This commit tightens how LND processes invoice payments, especially for newer multi-path (MPP) and AMP invoices, keysend payments, and replayed payments. It adds checks that ensure the right payment preimage is used for each invoice type a…

Preimage validation added for AMP and regular invoice replaysAMP invoices forced into MPP update path, preventing legacy-path processingLegacy settlement now fails when invoice-level preimage is missing
61f3b5a7by ziggieXXX+482−114 files
No security note in commit
Moderate 59 AI analysisMessage 35 · Opaque
LL Lightning LabsLND BitcoinLightning Network

invoices: refine update handling

This commit tightens how LND handles invoice payment updates, especially for newer 'AMP' invoices and old-style 'keysend' payments. It adds checks so that the wrong kind of payment cannot be processed against the wrong kind of invoice, and…

Added preimage/hash mismatch checks for both regular and AMP invoice replaysAMP records now require an MPP payload, preventing AMP processing on the legacy pathLegacy path now rejects AMP invoices and invoices missing invoice-level preimages
6be6350eby ziggie+476−113 files
No security note in commit
Informational 15 AI analysisMessage 57 · Thin
LL Lightning LabsLND BitcoinLightning Network

docs: update 0.21.2 release notes

This commit only updates the release notes document for version 0.21.2. It adds a bullet point describing a previously merged code change about invoice handling and adds a contributor name to the credits list. No actual code was changed, s…

758bbb8eby ziggie+6−01 file
No security note in commit
Moderate 60 AI analysisMessage 88 · Strong
LL Lightning LabsLND BitcoinLightning Network

peer+lnwallet/chancloser: advance the legacy closer from one goroutine

This commit fixes a concurrency bug in how LND negotiates cooperative channel closures. Previously, two different goroutines could update the same channel-closing state machine at the same time, which could corrupt internal data or cause a…

Data race on ChanCloser state field detected under go test -raceConcurrent access to priorFeeOffers map and signing step by two goroutinesSingle-goroutine ownership invariant now documented on ChanCloser type
e5e134ddby Olaoluwa Osuntokun+292−384 files
Vendor flagged security relevance
Low 29 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

lnwallet/chancloser: record the remote close output only when accepted

This change fixes a bookkeeping bug in how LND records the other party's preferred closing address during a channel close. Previously, a late or unexpected Shutdown message could overwrite the correct address with one from a message that w…

State variable written before validationRejected message could overwrite accepted close outputFix prevents stale/incorrect close metadata
fb89732dby Olaoluwa Osuntokun+7−21 file
No security note in commit
High 72 AI analysisMessage 68 · Adequate
LL Lightning LabsLND BitcoinLightning Network

htlcswitch: bound peer-controlled channel ingress

This commit hardens LND's channel message handling against a peer that tries to overwhelm the node. It adds limits on how many ordered messages and how much data a peer can queue up for a channel, and it disconnects the peer if either limi…

Adds resource bounds on peer-controlled channel ingress (count + bytes)Disconnects peer on mailbox admission failure instead of silently dropping ordered channel messagesPrevents unauthorized UpdateFee from channel initiator before fee-exposure calculations
ef24f2c5by Elle Mouton+507−94 files
Vendor flagged security relevance
Moderate 64 AI analysisMessage 83 · Strong
LL Lightning LabsLND BitcoinLightning Network

lnwallet/chancloser: validate delivery scripts in the RBF closer

This commit fixes a bug in LND's cooperative channel-closing code where a peer could supply an invalid, empty, or even money-burning Bitcoin address during a close, and LND would accept it without checking. The fix makes the newer 'RBF' cl…

Missing input validation on remote-supplied shutdown/delivery scriptEmpty/zero-length script accepted as valid due to nil-treatment in validatorMid-negotiation script swap via ClosingComplete not validated
a8e2a0f7by Olaoluwa Osuntokun+131−142 files
Vendor flagged security relevance
Moderate 51 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

lnwallet: make DustLimitForSize total over the sizes it can be handed

This change removes a deliberate program crash (panic) in LND's fee/dust-limit helper and replaces it with a safe fallback. Previously, if the helper received a script length it didn't explicitly recognize, it would panic and potentially c…

Removal of a panic/default branch in favor of a conservative fallbackDefensive handling of arbitrary and future witness-version script sizesPotential denial-of-service vector eliminated: unhandled script lengths no longer crash the helper
f80f92dcby Olaoluwa Osuntokun+23−62 files
No security note in commit
Informational 15 AI analysisMessage 57 · Thin
LL Lightning LabsLND BitcoinLightning Network

docs: move gossip bounds note to v0.21.2

This commit only moves an existing release-note entry from one version's notes (v0.22.0) to another (v0.21.2). It does not change any code, build files, configuration, or tests. The change is purely editorial documentation bookkeeping.

83e7eb8cby ziggie+11−112 files
No security note in commit
High 72 AI analysisMessage 68 · Adequate
LL Lightning LabsLND BitcoinLightning Network

discovery: bound channel range reply buffering

This change fixes a way a malicious or buggy peer could make an LND node use an unpredictable amount of memory while syncing the Lightning channel graph. Before the fix, the node only limited the size of one compressed reply message, but a…

Resource exhaustion / unbounded memory growth in gossip syncRemote peer can influence memory allocation via ReplyChannelRange streamMissing aggregate limit on decoded working set
ceff94faby Olaoluwa Osuntokun+335−153 files
Vendor flagged security relevance
Low 33 AI analysisMessage 47 · Thin
LL Lightning LabsLND BitcoinLightning Network

docs: update release notes

This commit updates the release notes for LND 0.21.2 to describe a fix for a bug in the HTLC interceptor RPC. The bug caused LND to fail to forward payments in blinded routes when the next hop was identified by node ID instead of channel I…

Blinded route forwarding failure could disrupt payment routing or be used to probe path structure.Sentinel value change in RPC API could cause client misclassification of forwards if not handled.Release notes describe the change as a fix for a forwarding issue, not as a security vulnerability.
f42b4298by bitromortac+20−01 file
No security note in commit
Informational 14 AI analysisMessage 83 · Strong
LL Lightning LabsLND BitcoinLightning Network

itest: cover blinded route next_node_id forwarding

This commit only adds new integration tests for an existing feature in LND: forwarding blinded payments where the next hop is identified by node ID rather than channel ID. It does not change production code, fix a bug, or introduce any new…

da6a40c0by bitromortac+432−02 files
No security note in commit
Low 25 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

witness beacon: report node-ID next hop to the on-chain HTLC interceptor

This change fixes a reporting gap in LND's 'witness beacon,' a component that watches on-chain transactions and tells the HTLC interceptor where a payment should go next. Previously, when the next hop was identified by a node ID rather tha…

Missing security-critical metadata in on-chain interception pathBehavioral parity between on-chain and off-chain HTLC interceptionPotential misclassification of node-ID forwards as final receives
9c4b8bfeby bitromortac+59−52 files
No security note in commit
Moderate 59 AI analysisMessage 81 · Strong
LL Lightning LabsLND BitcoinLightning Network

htlcswitch: forward node-ID blinded hops via non-strict forwarding

This commit fixes a bug in LND's payment forwarding for 'blinded routes'—a privacy feature in the Lightning Network. Previously, if the next hop was identified by node ID rather than a specific channel ID, the payment could not be forwarde…

Fixes a functional forwarding failure for blinded-route payments using node-ID next hops (issue #10937).Prevents private channel SCID leakage in failure messages for node-ID blinded hops by returning FailUnknownNextPeer instead of a channel_update.Adds circular-route filtering for node-ID next hops before non-strict forwarding selection.
dbc57040by bitromortac+334−416 files
No security note in commit
Informational 19 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

htlcswitch+lnrpc: report node-ID next hop to the off-chain HTLC interceptor

This change improves how the Lightning Network Daemon (LND) reports forwarding details to external plugins that inspect HTLCs (payment packets). For a new type of blinded route where the next hop is identified by node ID rather than a spec…

Information-correctness fix for HTLC interceptor APIPrevents misclassification of node-ID forwards as exit hopsAdds explicit sentinel to disambiguate zero SCID semantics
32373b76by bitromortac+29−13 files
No security note in commit
Low 25 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

htlcswitch: classify a node-ID forward as a forward event

This commit fixes a bookkeeping bug in LND's HTLC event stream. When a payment is forwarded to a 'blinded' next hop identified only by a node public key (not a channel ID), and it fails before the switch picks an outgoing channel, the even…

Event misclassification in HTLC event stream (forward reported as receive)Blinded/node-ID forwarding path introduced prior to this fixFailure and resolution packets dropped next-hop metadata before fix
a4844ef5by bitromortac+149−04 files
No security note in commit
Low 29 AI analysisMessage 68 · Adequate
LL Lightning LabsLND BitcoinLightning Network

htlcswitch/hop: decode next_node_id blinded hops

This commit adds support in LND for a different way of identifying the next hop in a private ('blinded') Lightning payment route. Previously LND expected the next hop to be identified by a channel ID; now it also accepts the next node's pu…

New validation enforces BOLT 4 mutual exclusivity of short_channel_id and next_node_id in blinded route dataPreviously ambiguous or unhandled next_node_id forwarding case now explicitly decodedNo memory-safety, cryptographic, or authorization changes observed
4fd4289aby bitromortac+471−86 files
No security note in commit
Moderate 60 AI analysisMessage 78 · Adequate
LL Lightning LabsLND BitcoinLightning Network

lnwire: cap decoded short channel IDs

This commit tightens a safety limit in LND's Lightning wire protocol parser. Previously, a compressed network message could decompress into an unbounded number of short channel IDs, potentially consuming far more memory than the wire messa…

Resource-limit bypass: compressed-input bound did not bound decoded outputMemory-exhaustion risk from zlib decompression of peer-supplied dataTruncated/corrupt zlib streams previously accepted as valid partial results
d1622919by Olaoluwa Osuntokun+271−502 files
No security note in commit
Repository ledger

Explore captured commits

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

Security candidatekeys: increase expiry of signing keyby Norbert · b669494a · Nov 6, 2025 · 1 fileMessage 60 · AdequateInformational 15Details
Commit message · Norbert

keys: increase expiry of signing key

The key did not change just the meta data.

60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundary
AI analysis · Informational 15/100

This commit updates an OpenPGP public key file stored in the repository. The underlying cryptographic key material did not change; only the key's metadata (specifically its self-signatures and expiry dates) was refreshed to extend the key's validity period. There is no code change and no direct security vulnerability in the commit itself.

Lower-prioritybuild: bump version to v0.7.0 rc4by Olaoluwa Osuntokun · 2ddb630a · Nov 4, 2025 · 1 fileMessage 57 · ThinInformational 15Details
Commit message · Olaoluwa Osuntokun

build: bump version to v0.7.0 rc4

57/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
AI analysis · Informational 15/100

This commit only changes a single version string from 'beta.rc3' to 'beta.rc4' in the LND software. It is a routine release-candidate version bump with no functional code changes and no security relevance.

Lower-prioritydocs: add release notes entryby Olaoluwa Osuntokun · adaa893f · Nov 3, 2025 · 1 fileMessage 57 · ThinInformational 15Details
Commit message · Olaoluwa Osuntokun

docs: add release notes entry

57/100 · ThinMessage clarity
✓ 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 adds a line to the release notes document describing a bug fix from another pull request. It does not change any program code, so by itself it cannot introduce or fix a security issue. The actual bug fix happened elsewhere.

Lower-prioritydiscovery/test: add comprehensive tests for state handler error exitsby Olaoluwa Osuntokun · b8ca8764 · Nov 3, 2025 · 1 fileMessage 95 · StrongInformational 15Details
Commit message · Olaoluwa Osuntokun

discovery/test: add comprehensive tests for state handler error exits

Add comprehensive test coverage to verify that state handler errors cause
the channelGraphSyncer goroutine to exit cleanly without entering endless
retry loops. These tests use mutation testing principles to ensure they
would fail if the fixes were removed.

TestGossipSyncerStateHandlerErrors is a table-driven test covering four
scenarios: context cancellation and peer disconnect during syncingChans
state, and context cancellation and network errors during queryNewChannels
state. Each test case verifies both attempt count (no endless loop) and
clean shutdown (no deadlock).

TestGossipSyncerProcessChanRangeReplyError verifies that errors from
processChanRangeReply in the waitingQueryRangeReply state cause clean
exit. This test sends multiple malformed messages and checks that only
the first is processed before the goroutine exits, using channel queue
depth to detect if the goroutine is still running.

All tests are race-detector clean and use mutation testing validation:
removing any of the error return statements causes the corresponding
tests to fail, confirming the tests properly verify the fixes.

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

This commit only adds new test code to the LND repository. It does not change any production code, so it cannot introduce a security vulnerability or fix one directly. The tests verify that certain error-handling paths in the gossip syncer exit cleanly rather than looping forever. Because the commit is purely tests, its immediate security risk is none, though it may increase confidence that prior fixes work as intended.

Lower-prioritydiscovery: fix endless loop in gossip syncer on context cancellationby Olaoluwa Osuntokun · 06c7d604 · Nov 3, 2025 · 2 filesMessage 85 · StrongModerate 60Details
Commit message · Olaoluwa Osuntokun

discovery: fix endless loop in gossip syncer on context cancellation

This commit fixes a critical bug where the channelGraphSyncer goroutine
would enter an endless loop when context cancellation or peer disconnect
errors occurred during the syncingChans or queryNewChannels states.

The root cause was that state handler functions (handleSyncingChans and
synchronizeChanIDs) did not return errors to the main goroutine loop.
When these functions encountered fatal errors like context cancellation,
they would log the error and return early without changing the syncer's
state. This caused the main loop to immediately re-enter the same state
handler, encounter the same error, and loop indefinitely while spamming
error logs.

The fix makes error handling explicit by having state handlers return
errors. The main channelGraphSyncer loop now checks these errors and
exits cleanly when fatal errors occur. We return any error (not just
context cancellation) because fatal errors can manifest in multiple
forms: context.Canceled, ErrGossipSyncerExiting from the rate limiter,
lnpeer.ErrPeerExiting from Brontide, or network errors like connection
closed. This approach matches the error handling pattern already used in
other goroutines like replyHandler.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Moderate 60/100

This commit fixes a bug in LND's gossip syncer where a background goroutine could get stuck in an endless loop when a peer disconnected or its work was cancelled. Instead of exiting cleanly, the goroutine would repeatedly try the same step, flood error logs, and never stop. The fix makes the goroutine return errors to its main loop so it can shut down properly.

Security candidatemulti: allow invalid tlv data when decoding payment fail infoby ziggie · 870d603c · Nov 3, 2025 · 5 filesMessage 75 · AdequateLow 47Details
Commit message · ziggie

multi: allow invalid tlv data when decoding payment fail info

Older payments might have a invalid tlv stream, we now catch this
case and add a unit test.

75/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
boot or update path
AI analysis · Low 47/100

This change makes LND more forgiving when reading old payment failure records that contain slightly corrupted extra data fields. Previously, such records could cause the database read to fail entirely; now the code logs a warning and continues, leaving the failure message empty but preserving the rest of the record. It is a robustness fix rather than an active vulnerability patch.

Lower-prioritybuild: bump version to v0.20 rc3by Olaoluwa Osuntokun · 0ff9c2e6 · Oct 27, 2025 · 1 fileMessage 57 · ThinInformational 15Details
Commit message · Olaoluwa Osuntokun

build: bump version to v0.20 rc3

57/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
AI analysis · Informational 15/100

This commit only changes a single version string from 'beta.rc2' to 'beta.rc3' in the software's build metadata. It is a routine release-candidate version bump with no functional code changes and no security relevance.

Lower-prioritydocs: added a user guide for db migrationby saubyk · 99745f3e · Oct 27, 2025 · 1 fileMessage 57 · ThinInformational 15Details
Commit message · saubyk

docs: added a user guide for db migration

57/100 · ThinMessage clarity
✓ 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 adds a new documentation file explaining how LND node operators can migrate their database from the legacy bbolt format to SQLite or PostgreSQL. It contains no code changes, no configuration changes, and no security fixes or vulnerabilities.

Lower-prioritydocs: update release notes v0.20.0by Mohamed Awnallah · f761dc4c · Oct 22, 2025 · 1 fileMessage 57 · ThinInformational 15Details
Commit message · Mohamed Awnallah

docs: update release notes v0.20.0

57/100 · ThinMessage clarity
✓ 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.20.0. It adds a description of a previously fixed bug about wallet rescanning during header sync. No code changes are included, so this commit itself does not alter software behavior or introduce security risk.

Lower-prioritylnd.go: sync headers before chain notifier startup to prevent premature rescanby Mohamed Awnallah · c6f458e4 · Oct 22, 2025 · 1 fileMessage 95 · StrongLow 43Details
Commit message · Mohamed Awnallah

lnd.go: sync headers before chain notifier startup to prevent premature rescan

This commit addresses a regression where Neutrino rescanning starts
from an outdated height (~100k blocks behind) instead of using the
current synced height.

Root Cause:
In commit 16a8b623b, the initialization order was changed so that
Chain Notifier starts before wallet syncing completes. This means
the rescan begins using the stale height from BuildChainControl
rather than the fully synced height.

Old behavior (commit 1dfb5a0c2):
1. RPC server starts
2. Headers sync as part of daemon server
3. Chain Notifier starts after sync completes
4. Rescan begins from current (synced) height

Current behavior (regression):
1. Chain Notifier starts in newServer (before RPC)
2. Wallet sync happens after RPC server starts
3. Rescan uses outdated height from BuildChainControl

Solution:
- Ensure headers are fully synced before starting the chain notifier,
and after starting the RPC server.
- Move chain notifier startup to its correct location after headers are
fully synced.
- Make sure the starting beat is lazily called after chain notifier
started and before that starting beat result is used.

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

This patch fixes a startup-order bug in the Lightning Network Daemon (LND). Because a previous change started the chain notifier before the wallet's block headers were fully synced, rescans could begin from an old block height roughly 100,000 blocks behind the current chain tip. The fix moves chain notifier startup to after header synchronization and delays the 'starting beat' block reference until after the notifier is running. The main risk is operational/money-loss: a node that rescans from a stale height can miss recent on-chain events such as channel closes, force-closes, or swept funds, which may lead to incorrect balances or delayed detection of transactions. It is not a remote code execution or direct theft vulnerability.

AI review queued[docs] Typo recovery.mdby AbelLykens · 529ee2ef · Oct 22, 2025 · 1 fileMessage 28 · OpaqueInformational 15Details
Commit message · AbelLykens

[docs] Typo recovery.md

`-multi_file` should be `--multi_file`

28/100 · OpaqueMessage clarity
✓ Subject identifies a change! No meaningful explanatory body
Why it was queued
documentation-only discountsecond-pass: opaque commit message
AI analysis · Informational 15/100

This commit fixes a single-character typo in the user documentation. The command example showed '-multi_file' instead of the correct '--multi_file'. It does not change any code, commands, or security behavior.

Security candidatescripts/keys: update roasbeef keys with new expiryby Olaoluwa Osuntokun · 81ff01c9 · Oct 22, 2025 · 1 fileMessage 78 · AdequateInformational 15Details
Commit message · Olaoluwa Osuntokun

scripts/keys: update roasbeef keys with new expiry

My key recently expired, in this commit, we update the keys to the new
refreshed version. These are the same keys, but with an expiry further
out.

Here's a clear sign of the latest Bitcoin block hash:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

000000000000000000013215ef7c32bc0427f388fc83623affe712f388
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQQpYhJoGq3wVlaize6QUl997uCthgUCaPi6xwAKCRCQUl997uCt
hpqNAQC5VnnbO6h/PjywGhU4LLRvH8SdgdDEMSc7xrtWd1vgPgD+IDrHqiAb+h38
ORBnUVJCVuZrPebtdnYXVQhII91eaw4=
=WRbl
-----END PGP SIGNATURE-----

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 boundary
AI analysis · Informational 15/100

This commit simply refreshes an expired PGP public key file used to verify software releases. The same cryptographic key is kept, but its expiration date is extended. There is no code change and no security vulnerability.

AI review queueddocs: fix build instructions doc urlby saubyk · 5ef97632 · Oct 22, 2025 · 1 fileMessage 72 · AdequateInformational 16Details
Commit message · saubyk

docs: fix build instructions doc url

Signed-off-by: saubyk <39208279+saubyk@users.noreply.github.com>

72/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body
Why it was queued
signing or wallet pathdocumentation-only discountsecond-pass: security-sensitive path
AI analysis · Informational 16/100

This commit fixes a broken hyperlink in a documentation file. The old URL was missing a slash between 'master' and 'docs', making it invalid. The fix replaces it with a proper relative link. There is no code change and no security impact.

Lower-prioritymulti: update mapstructure/v2by Boris Nagaev · 6ee8e2a8 · Oct 21, 2025 · 8 filesMessage 58 · ThinLow 49Details
Commit message · Boris Nagaev

multi: update mapstructure/v2

go-viper's mapstructure may leak sensitive information in logs when processing
malformed data. Updating to the version where the bug is fixed.

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
AI analysis · Low 49/100

This commit updates a dependency called go-viper/mapstructure from version 2.3.0 to 2.4.0 across several parts of the LND project. The commit message says the older version could leak sensitive information into logs when handling malformed data, and this update fixes that. The actual code change is only to version numbers in Go module files; no LND source code is changed. We can see the stated security reason but have no independent details about exactly what data could leak or how severe the upstream bug was.

Security candidatebuild: update CI+release version to Go 1.25.3by Boris Nagaev · 4fc8d8dd · Oct 21, 2025 · 21 filesMessage 72 · AdequateInformational 15Details
Commit message · Boris Nagaev

build: update CI+release version to Go 1.25.3

We also update the go.mod files to pin to Go 1.24.9.

72/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body
Why it was queued
access control
AI analysis · Informational 15/100

This commit is a routine build-maintenance change. It updates the version of the Go programming language used by the project's automated tests, release builds, Docker images, and documentation from Go 1.25.2 to Go 1.25.3 (and the minimum required Go version from 1.24.8 to 1.24.9). There are no code logic changes, no bug fixes, and no security patches in the project itself.

Lower-priorityci: use enhanced cleanup action in release workflowby Olaoluwa Osuntokun · b82ed88b · Oct 20, 2025 · 1 fileMessage 85 · StrongInformational 15Details
Commit message · Olaoluwa Osuntokun

ci: use enhanced cleanup action in release workflow

In this commit, we replace the basic inline cleanup command in the release
workflow with the comprehensive cleanup-space action that was previously
only used in the main CI workflow. The previous release workflow cleanup
simply removed the hostedtoolcache directory, which freed only a few
gigabytes and proved insufficient for multi-platform release builds.

By switching to the cleanup-space action (now enhanced to free 20-25GB),
the release workflow will have substantially more disk space available
before beginning the build process. This should resolve the disk space
exhaustion issues that were occurring during the Windows ARM build phase,
which is one of the final platforms in the 15-platform build sequence.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
documentation-only discount
AI analysis · Informational 15/100

This commit changes the release build pipeline to use a more thorough disk cleanup step before compiling. It is purely a reliability improvement for GitHub Actions builds and has no security relevance.

Lower-prioritybuild: clear Go cache between platform builds in release scriptby Olaoluwa Osuntokun · dfee5702 · Oct 20, 2025 · 1 fileMessage 97 · StrongInformational 15Details
Commit message · Olaoluwa Osuntokun

build: clear Go cache between platform builds in release script

In this commit, we add a call to "go clean -cache" after each platform
build in the release script to prevent the Go build cache from accumulating
unbounded disk space during the sequential 15-platform build process.

When building for multiple platforms in sequence with "go build -v", Go
creates intermediate build artifacts and caches compiled packages for each
target platform. While this caching improves build performance within a
single platform build, it causes the cache to grow substantially when
building for many platforms sequentially. With 15 different platform/
architecture combinations, each with their own cached artifacts, this
accumulation was contributing to the disk space exhaustion.

By clearing the build cache after each platform completes, we prevent this
unbounded growth while still allowing each individual platform build to
benefit from caching during its own compilation. The module cache is
preserved (we only clear the build cache), so dependencies don't need to be
re-downloaded between platforms.

97/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Informational 15/100

This commit changes the release build script to clear Go's temporary build cache after compiling for each platform. It is a routine build-hygiene fix to prevent disk space from running out during long release builds. There is no security vulnerability here.

Lower-priorityci: enhance cleanup-space action for release buildsby Olaoluwa Osuntokun · 2ccf4b98 · Oct 20, 2025 · 1 fileMessage 85 · StrongInformational 15Details
Commit message · Olaoluwa Osuntokun

ci: enhance cleanup-space action for release builds

In this commit, we significantly expand the cleanup-space GitHub Actions
workflow to free up substantially more disk space on GitHub runners. The
previous cleanup only removed three large toolsets (dotnet, android,
ghc), which should free ~14GB. This enhancement adds removal of several
additional large packages and caches, bringing the total freed space to
approximately 20-25GB.

The specific additions include removing Swift and Julia language runtimes,
the hosted toolcache directory, all Docker images, numerous large apt
packages (aspnetcore, llvm, php, mongodb, mysql, azure-cli, browsers, and
development tools), and various cache directories. We also add disk space
reporting before and after cleanup to provide visibility into how much
space is actually being freed during workflow runs.

This enhancement was motivated by release builds running out of disk space
when building for all 15 supported platforms (darwin, freebsd, linux,
netbsd, openbsd, windows across multiple architectures). The sequential
builds with verbose output were consuming more space than the basic cleanup
could provide.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
documentation-only discount
AI analysis · Informational 15/100

This commit only changes a GitHub Actions workflow that deletes unused software from build machines to free up disk space. It is a routine infrastructure/maintenance change and does not modify any wallet, network, or cryptographic code. There is no security issue visible in the diff.

Lower-prioritybuild: bump version to v0.20.0 rc2by Olaoluwa Osuntokun · 6b7ad412 · Oct 20, 2025 · 1 fileMessage 57 · ThinInformational 15Details
Commit message · Olaoluwa Osuntokun

build: bump version to v0.20.0 rc2

57/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
AI analysis · Informational 15/100

This commit only changes a single version string from 'beta.rc1' to 'beta.rc2' in the software's build metadata. It is a routine release-candidate version bump with no functional code changes and no security relevance.

Lower-prioritydocs: add release-notesby ziggie · 7c92c882 · Oct 13, 2025 · 1 fileMessage 40 · ThinLow 39Details
Commit message · ziggie

docs: add release-notes

40/100 · ThinMessage clarity
✓ Subject identifies a change✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
documentation-only discount
AI analysis · Low 39/100

This commit only adds a line to the release notes describing a prior bug fix: HTLCs (payment contracts) with a locktime of 0 were not being swept by an older legacy sweeper component called utxonursery. The actual code fix is in a separate pull request referenced by the note. Because this commit is documentation-only, it does not itself change any program behavior, but it confirms a past bug existed that could have left some funds unrecovered.

Lower-prioritycontractcourt: patch 0 timelock baby outputsby ziggie · bed021fc · Oct 13, 2025 · 2 filesMessage 80 · StrongLow 41Details
Commit message · ziggie

contractcourt: patch 0 timelock baby outputs

Older LND versions had a bug which would create HTLCs with
0 locktime. The utxonursery will have problems dealing with such
htlc outputs because we do not allow height hints of 0. Now we
will fetch the closeSummary of the channel and will add a
conservative height for rescanning.

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Low 41/100

This commit fixes a bug in LND's UtxoNursery where old HTLC outputs stored with a 0-block locktime could not be properly rescanned because the chain notifier rejects height hints of 0. The patch adds a fallback that derives a valid height hint from the channel's close height or short channel ID. It is a defensive fix for a historical data corruption issue, not a remote-exploitable vulnerability.

Security candidatebuild: update CI+release version to Go 1.25.2by Olaoluwa Osuntokun · 7fcbbd44 · Oct 11, 2025 · 21 filesMessage 72 · AdequateInformational 15Details
Commit message · Olaoluwa Osuntokun

build: update CI+release version to Go 1.25.2

We also update the go.mod files to pin to Go 1.24.8.

72/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body
Why it was queued
access control
AI analysis · Informational 15/100

This commit is a routine build-maintenance change. It updates the Go compiler version used in CI, release pipelines, Docker images, and documentation from Go 1.24.6 to Go 1.25.2, and bumps the minimum Go version declared in go.mod files from 1.24.6 to 1.24.8. There are no code logic changes and no security fix or vulnerability patch is visible in the diff.

Lower-prioritygo.mod: remove sqldb and fn replacementsby Elle Mouton · 7867aa8d · Oct 9, 2025 · 2 filesMessage 45 · ThinInformational 15Details
Commit message · Elle Mouton

go.mod: remove sqldb and fn replacements

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 15/100

This commit is a routine dependency housekeeping change. It removes two temporary local overrides in the Go module file and switches to published versions of internal helper packages (fn v2.0.9 and sqldb v1.0.11). There is no indication in the commit or supplied references that this fixes a security issue.

Lower-prioritygraph/db: gracefully handle duplicate channel policy announcementsby Elle Mouton · eb67757a · Oct 6, 2025 · 2 filesMessage 50 · ThinLow 37Details
Commit message · Elle Mouton

graph/db: gracefully handle duplicate channel policy announcements

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

This commit fixes a bug in LND's channel graph database where applying the exact same Lightning channel policy update twice in one batch would cause an error. The fix makes the code ignore the harmless duplicate instead of failing. It is a robustness improvement rather than a clear-cut security vulnerability, but the prior failure path could have caused database errors or inconsistent graph state during normal network operation.

Lower-prioritygraph/db: gracefully handle duplicate node announcementsby Elle Mouton · abb96548 · Oct 6, 2025 · 2 filesMessage 73 · AdequateLow 34Details
Commit message · Elle Mouton

graph/db: gracefully handle duplicate node announcements

It can happen that we are handling 2 of the same node announcements in
the same batch transaction. In that case, our `UpsertNode` conflict
assertion may fail. We need to handle this gracefully.

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

This change fixes a database error that could occur when the same Lightning Network node announcement was processed twice in quick succession. Instead of crashing or returning an error, the code now ignores the duplicate. It is a robustness fix rather than a vulnerability that allows theft or remote takeover.