LL
← All projectsLightning Labs

LND

Go implementation of a complete Lightning Network node.

BitcoinLightning NetworkNormal
Repository coverage

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

141security candidates194second-pass queue1285AI analyses
73commits · 30 days
173commits · 60 days
596commits · 180 days
1234commits · 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
318Strong · 80–100
646Adequate · 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
bitromortac531051069
yyforyongyu83861068
Erick Cestari26726070
Andras Banki-Horvath11311072
Gijs van Dam33230073
ziggieXXX2026070
Analysis record

Published AI watches

Last scanned 45 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
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
Informational 15 AI analysisMessage 78 · Adequate
LL Lightning LabsLND BitcoinLightning Network

itest: cover confirmation-controlled leases

This commit only adds a new integration test for an existing feature called confirmation-controlled leases. It does not change production code, so it cannot introduce a security vulnerability or fix one directly. The test exercises how lon…

a1ab4e92by Andras Banki-Horvath+152−02 files
No security note in commit
Moderate 68 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11122 from gijswijs/websocket-proxy-hardening

This update fixes two security-related bugs in LND's REST WebSocket proxy. First, a specially crafted WebSocket protocol header could crash the proxy (a panic). Second, the proxy previously had no limit on how large an incoming WebSocket m…

panic fix in request header parsingunbounded incoming WebSocket message read now cappedincorrect header value assignment possible before fix
c662f853by Yong+227−104 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.

Lower-prioritydiscovery+funding+peer+server: migrate gossip result to actor.Future[error]by Olaoluwa Osuntokun · ac71ea75 · Apr 11, 2026 · 8 filesMessage 85 · StrongModerate 64Details
Commit message · Olaoluwa Osuntokun

discovery+funding+peer+server: migrate gossip result to actor.Future[error]

In this commit, we eliminate the three buffered chan error patterns in
the discovery package and replace them with actor.Promise[error]/
actor.Future[error]. The old pattern is error-prone: if a channel is
completed more than once (e.g. when a deferred message copy is
re-enqueued and processed again), the second write to a capacity-1
channel blocks forever. actor.Promise.Complete() is idempotent via
sync.Once, so the second call is always a safe no-op regardless of
whether anyone holds a reference to the Future.

Additionally, PropagateChanPolicyUpdate previously blocked on <-errChan
after enqueuing a policy update with no quit-channel check, creating a
latent deadlock if the gossiper shut down between enqueue and send. It
now uses AwaitGossipResult with a ContextFromQuit-derived context, so
shutdown is always respected.

This is an atomic migration that updates all callers in the same
commit so each commit builds standalone. The three main pieces are:

discovery

networkMsg.err chan error becomes errPromise actor.Promise[error].
chanPolicyUpdateRequest.errChan chan error becomes errPromise.
syncTransitionReq.errChan chan error becomes errPromise. All ~65 sites
that previously wrote to the error channel now call
completeGossipResult(nMsg.errPromise, err) instead.

ProcessRemoteAnnouncement and ProcessLocalAnnouncement now return
actor.Future[error] instead of chan error. The capacity-2 buffer
comment on ProcessRemoteAnnouncement, which was itself a workaround
for the old pattern, is removed along with the TODO referencing the
actor model redesign. ProcessSyncTransition in syncer.go follows the
same pattern: the errChan select is replaced with AwaitGossipResult
using a ContextFromQuit-derived context.

funding

The SendAnnouncement function type in funding.Config changes from
returning chan error to returning actor.Future[error]. The call sites
in addToGraph and announceChannel are updated to await the future with
AwaitGossipResult, passing a context derived from f.quit via
ContextFromQuit. Shutdown signals (context.Canceled and
discovery.ErrGossiperShuttingDown) are both mapped to
ErrFundingManagerShuttingDown via the new mapGossipError helper, which
also factors out the duplicated graph-rejected / unknown-error
handling. The three mock SendAnnouncement implementations in
manager_test.go are updated accordingly.

peer+server

In peer/brontide.go, the ProcessRemoteAnnouncement call in the gossip
stream handler intentionally discards the result since remote gossip
messages are fire-and-forget from the peer's perspective. The old
comment explaining why the chan error was unsafe to use is replaced
with a note that an unawaited Future[error] carries no overhead.

In server.go (applyChannelUpdate), the previous select on errChan and
the quit channel is replaced with ContextFromQuit + AwaitGossipResult.

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

This commit refactors how LND's gossip subsystem reports errors back to callers. Previously, code used buffered Go channels to carry a single error result. That pattern could deadlock if a deferred gossip message was processed twice, because the second write to an already-full channel would block forever. The change replaces those channels with a new 'actor.Promise/Future' abstraction whose completion is idempotent (safe to call many times). It also makes shutdown handling more uniform by deriving contexts from quit channels, preventing another latent deadlock in channel-policy propagation. The commit includes regression tests for premature-announcement reprocessing and shutdown paths.

Lower-priorityactor/test: extend TestAwaitFuture to cover fn.Err result pathby Olaoluwa Osuntokun · fb86988c · Apr 11, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Olaoluwa Osuntokun

actor/test: extend TestAwaitFuture to cover fn.Err result path

In this commit, we extend TestAwaitFuture to cover the case where the
future is completed with an fn.Err result. The existing test only
exercised the fn.Ok (success) and context cancellation paths.

The new case calls promise.Complete(fn.Err[string](sentinel)) directly
and verifies that AwaitFuture surfaces the error as the second return
value while returning the zero string value in the first, which is the
documented contract for Result[T].Unpack().

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 15/100

This commit only adds a new test case to an existing unit test. It checks that a helper function correctly returns an error when a future/promise is completed with an error value. There are no changes to production code, no bug fixes, and no security-relevant behavior changes.

Lower-prioritylnutils: add ContextFromQuit to bridge quit channels to contextsby Olaoluwa Osuntokun · eadea00a · Apr 11, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Olaoluwa Osuntokun

lnutils: add ContextFromQuit to bridge quit channels to contexts

In this commit, we add ContextFromQuit, a utility for bridging the quit
channel shutdown pattern to context.Context-based cancellation.

Several subsystems in lnd use a plain quit <-chan struct{} for
cooperative shutdown rather than a context.Context. When those
subsystems need to await a Future[error], which uses a context for
cancellation, they need a way to derive a context that is cancelled
when the quit channel closes.

ContextFromQuit does exactly that: it returns a context tied to
context.Background() plus a cancel function, and spins up a minimal
goroutine that cancels the context as soon as quit is closed. The
returned cancel must be called (deferred at the call site) so the
goroutine exits when the enclosing operation completes normally before
shutdown.

This is a pure utility with no policy and no default timeout, so
callers remain in full control of lifetime.

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

This commit adds a small internal helper function that lets existing shutdown channels in lnd work with newer code that expects Go's standard context-based cancellation. It does not change any behavior, fix any bug, or introduce any user-facing feature. There is no security relevance in the change itself.

Lower-prioritylnd: skip network validation when migrations are skippedby ziggie · e744e19b · Apr 10, 2026 · 1 fileMessage 73 · AdequateLow 31Details
Commit message · ziggie

lnd: skip network validation when migrations are skipped

Skip the chain_params network check when startup is explicitly
configured to skip SQL migrations. In that mode the schema is assumed
to already be managed externally, and the chain_params table may not
exist yet. Avoid failing startup on a missing table in this path.

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

This change lets LND skip a safety check that prevents accidentally using a database from the wrong Bitcoin network (like mainnet vs testnet) when the user has explicitly told LND to skip SQL database migrations. The check is skipped because the table it reads may not exist in that special setup. This is a deliberate relaxation of a guardrail, not a fix for an attack, and it only affects users who opt into the 'skip migrations' mode.

Lower-prioritydocs: add release note for network separation safeguardby ziggie · a10cd169 · Apr 10, 2026 · 1 fileMessage 85 · StrongModerate 58Details
Commit message · ziggie

docs: add release note for network separation safeguard

This is in particular important when running with a postgres
backend.

This only works if you run LND with the native sql flag but
people should run it with this flag from 21 on anyways.

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

This commit is just a documentation update adding a release note for a safeguard that was already merged via a previous code change (PR #10684). The safeguard prevents LND from accidentally starting up with the wrong Bitcoin network while reusing the same database, which could silently corrupt data. The actual protective code is not in this commit; only the description of it is.

Lower-priorityitest: cover postgres network separationby ziggie · ccabac60 · Apr 10, 2026 · 3 filesMessage 45 · ThinInformational 12Details
Commit message · ziggie

itest: cover postgres network separation

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

This commit only adds an integration test that checks an existing safety feature: LND refuses to start if the Bitcoin network setting doesn't match the one already recorded in a Postgres database. It does not change production code or fix a new vulnerability. The test helps prevent accidental data corruption from reusing the same database across different Bitcoin networks, but it is not itself a security patch.

Lower-prioritysqldb: add validate-network unit testsby ziggie · d988682e · Apr 10, 2026 · 3 filesMessage 55 · ThinInformational 15Details
Commit message · ziggie

sqldb: add validate-network unit tests

55/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
defensive validation
AI analysis · Informational 15/100

This commit only adds new unit tests for an existing database network-validation feature. It does not change any production code, fix a bug, or alter behavior users would see. There is no security issue here.

Lower-prioritysqldb: add new chainparam storeby ziggie · 3697f63a · Apr 10, 2026 · 1 fileMessage 45 · ThinInformational 15Details
Commit message · ziggie

sqldb: add new chainparam store

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

This commit adds a new database-backed store that records which Bitcoin network (mainnet, testnet, etc.) the node was first started with. On every startup it checks the stored value against the current configuration and refuses to run if they differ. This is a defensive safety feature, not a vulnerability fix or exploitable change.

Lower-prioritylnd: validate native-sql network on startupby ziggie · 5eebbb0e · Apr 10, 2026 · 1 fileMessage 45 · ThinModerate 58Details
Commit message · ziggie

lnd: validate native-sql network on startup

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
defensive validation
AI analysis · Moderate 58/100

This commit adds a startup safety check in LND (a Bitcoin Lightning Network node implementation) that verifies a native SQL database was created for the same Bitcoin network (mainnet, testnet, etc.) the node is currently configured to use. Without this check, a user could accidentally point LND at the wrong database—such as reusing a mainnet database while running on testnet—which could silently corrupt payment channel data. The change makes LND refuse to start rather than risk that corruption.

Lower-prioritysqldb/sqlc: add chain_param schema and queriesby ziggie · 0b82a89f · Apr 10, 2026 · 7 filesMessage 45 · ThinInformational 15Details
Commit message · ziggie

sqldb/sqlc: add chain_param schema and queries

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

This commit adds a new database table called chain_params to store which Bitcoin network (e.g., mainnet or testnet) the database was created for. It also adds simple read/write queries and registers a new migration. There is no security fix or vulnerability here; it is ordinary infrastructure code.

Lower-prioritysqldb: harden migration config consistency testsby ziggie · bd7e950c · Apr 9, 2026 · 3 filesMessage 78 · AdequateInformational 16Details
Commit message · ziggie

sqldb: harden migration config consistency tests

Strengthen migration consistency coverage by checking the reverse
mapping from embedded SQL files to migrationConfig entries, deriving
previous schema state from slice order instead of Version, rejecting
schema version regressions, and asserting migration names match the
embedded SQL file stems.

Also fix the graph v2 migration config name to match the embedded
migration filename.

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

This commit is a hardening patch for database migration tests in LND. It adds and strengthens automated checks that ensure every embedded SQL migration file is registered in the migration configuration, that schema versions never go backwards, and that migration names match their SQL filenames. It also fixes one mismatched migration name. There is no runtime code change that would directly create or fix an exploitable vulnerability; the change is defensive test coverage.

Lower-prioritysqldb: register migration 14 in migration configby ziggie · 8a9f774f · Apr 9, 2026 · 1 fileMessage 68 · AdequateInformational 22Details
Commit message · ziggie

sqldb: register migration 14 in migration config

Add the 000014_payments_no_fail_reason_index migration to the
main migration configuration so the global migration list stays in
sync with the embedded SQL schema files.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 22/100

This commit is a small bookkeeping fix: it adds a previously-created database migration to the master list so that LND's database upgrade tracker knows about it. On its own, the change does not introduce a security vulnerability or fix an exploitable bug. However, if the migration had been left unregistered, future upgrades could potentially get out of sync, which in database systems can sometimes lead to inconsistent state or upgrade failures.

Lower-prioritydocs: add release notes for Android 16KB page sizeby ajaysehwal · bb1b56f3 · Apr 9, 2026 · 1 fileMessage 62 · AdequateInformational 19Details
Commit message · ajaysehwal

docs: add release notes for Android 16KB page size

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

This commit only adds a line to the release notes describing a previous build-system change for Android. It does not change any code, configuration, or behavior, and it does not fix or introduce any security issue.

Lower-prioritydocs: add release-notes for 21by ziggie · 15135222 · Apr 9, 2026 · 1 fileMessage 57 · ThinInformational 15Details
Commit message · ziggie

docs: add release-notes for 21

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 that was already merged in a previous pull request. It does not change any program code, so it cannot by itself introduce or fix a security issue. The underlying bug it describes was a deadlock during shutdown that could freeze invoice processing, but this commit is purely documentation.

Lower-priorityhtlcswitch: fix hodlQueue deadlock by stopping htlcManager firstby ziggie · f550ac1f · Apr 9, 2026 · 1 fileMessage 73 · AdequateHigh 70Details
Commit message · ziggie

htlcswitch: fix hodlQueue deadlock by stopping htlcManager first

The channelLink.Stop() teardown had an inverted ordering that could
cause a permanent deadlock of the invoice registry under concurrent
peer disconnect.

The previous order was:
1. HodlUnsubscribeAll -- removes subscriptions
2. hodlQueue.Stop() -- kills the queue's internal goroutine
3. cg.Quit() -- signals htlcManager to stop
4. cg.WgWait() -- waits for htlcManager to exit

The race window between steps 2 and 4 left htlcManager alive. A
RevokeAndAck arriving during that window could drive processRemoteAdds
→ processExitHop → NotifyExitHopHtlc, registering a new hodl
subscription backed by a dead hodlQueue (ChanIn() has no reader).

Any subsequent call to notifyHodlSubscribers (e.g. MPP auto-release
timer, expiry watcher, or explicit settle/cancel) would then block
indefinitely on the unbuffered ChanIn(), holding hodlSubscriptionsMux.
Concurrent NotifyExitHopHtlc calls waiting for that lock, plus callers
holding the invoice-level lock waiting for those, produce a full
deadlock of the invoice registry with no recovery path short of a
daemon restart.

The fix is to stop htlcManager before touching the hodl subscription
state. htlcManager is the sole caller of NotifyExitHopHtlc, so once
cg.WgWait() returns no new subscriptions can be registered, making
HodlUnsubscribeAll and hodlQueue.Stop() race-free.

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

This commit fixes a bug in LND's payment channel shutdown code that could freeze the entire invoice handling system. The old shutdown order stopped a message queue before stopping the goroutine that uses it, creating a brief window where a new subscription could be attached to a dead queue. Once that happened, later invoice operations would block forever waiting for a queue that would never respond, deadlocking the invoice registry and requiring a full node restart to recover. The fix simply reverses the shutdown order so the worker goroutine exits before the queue is torn down.

Lower-prioritybuild: add Android 16KB page size flags to Makefileby ajaysehwal · 38575679 · Apr 9, 2026 · 1 fileMessage 62 · AdequateInformational 19Details
Commit message · ajaysehwal

build: add Android 16KB page size flags to Makefile

62/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
AI analysis · Informational 19/100

This commit changes the Android build settings for LND's mobile library so it works on newer Android devices that use 16KB memory pages. It is a compatibility/build fix, not a security patch. There is no indication it fixes a vulnerability.

Lower-prioritygraph/db: fix FetchChannelEdgesByID zombie fallback versioningby Elle Mouton · ebb199d2 · Apr 9, 2026 · 2 filesMessage 83 · StrongLow 35Details
Commit message · Elle Mouton

graph/db: fix FetchChannelEdgesByID zombie fallback versioning

The zombie fallback in SQLStore.FetchChannelEdgesByID unconditionally
constructed a models.NewV1Channel regardless of the requested gossip
version. Use the passed version to select the correct constructor so
that v2 zombie edges carry the right version.

A new testFetchZombieEdgeVersioning versioned test verifies that
zombie edges returned by FetchChannelEdgesByID have the correct
gossip version for both v1 and v2.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Low 35/100

This commit fixes a bug in LND's Lightning graph database where a fallback path for deleted ('zombie') channels always created a version-1 channel object, even when the caller asked for version 2. The fix makes the fallback use the requested gossip version. The bug could cause version mismatches when reading zombie channel data, but it does not appear to be directly exploitable for theft or denial of service.

Lower-prioritydocs: add release note for FilterKnownChanIDs versioningby Elle Mouton · 4d85877a · Apr 9, 2026 · 1 fileMessage 62 · AdequateInformational 15Details
Commit message · Elle Mouton

docs: add release note for FilterKnownChanIDs versioning

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 adds a release note describing a previously merged code change. It does not modify any program code, network behavior, or configuration. There is no security issue in the commit itself.

Security candidategraph/db: add gossip version parameter to FilterKnownChanIDsby Elle Mouton · 12f8e509 · Apr 9, 2026 · 5 filesMessage 78 · AdequateLow 27Details
Commit message · Elle Mouton

graph/db: add gossip version parameter to FilterKnownChanIDs

Add an explicit lnwire.GossipVersion parameter to FilterKnownChanIDs
on the Store interface, SQLStore, KVStore, and ChannelGraph. Since
FilterKnownChanIDs is always called from a version-scoped ChanSeries
context, a single version parameter is cleaner than per-item version
reads. A convenience wrapper on VersionedGraph preserves the existing
ChanSeries call-site signature by threading c.v automatically.

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 · Low 27/100

This commit refactors how a Lightning Network routing database method, FilterKnownChanIDs, receives the gossip protocol version. Previously the version was read from each individual channel record; now it is passed explicitly from the version-scoped wrapper. The change also adds a sanity check that zombie channels returned by the database match the expected gossip version, and updates tests to cover both v1 and v2 gossip. It is a defensive correctness improvement rather than a clear-cut fix for an active vulnerability.

Lower-prioritygraph/db: parameterize forEachChanInSCIDList with gossip versionby Elle Mouton · bcadafa1 · Apr 9, 2026 · 1 fileMessage 73 · AdequateInformational 19Details
Commit message · Elle Mouton

graph/db: parameterize forEachChanInSCIDList with gossip version

Replace the hardcoded GossipVersion1 in forEachChanInSCIDList with an
explicit version parameter so the helper can be used for v2 channel
lookups. The caller in FilterKnownChanIDs now passes the version
through.

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

This is a small internal code cleanup in LND's channel graph database code. It replaces a hardcoded gossip version number with a parameter so the same helper function can be reused for both old and new channel gossip formats. The only visible behavior change is that zombie-channel checks now use the version carried in each channel's own metadata rather than always assuming the old version. There is no obvious security vulnerability here; it looks like a correctness/refactoring change.

Lower-prioritysqldb/v2: align sqlite idle defaultsby yyforyongyu · 7074419b · Apr 9, 2026 · 3 filesMessage 90 · StrongInformational 18Details
Commit message · yyforyongyu

sqldb/v2: align sqlite idle defaults

Keep SQLite's default idle connection limit aligned with the
open connection limit so the default pool matches v1 behavior.

This is a follow-up regression fix to the restored open-connection
default in e263ea145. After that change, SQLite again defaulted to
SetMaxOpenConns(2), but SetMaxIdleConns still fell back to 6. Go
silently caps idle connections at the open limit, so nothing
crashed, but the configured idle default became misleading and no
longer matched v1.

Use cfg.MaxConns() as the inherited idle default, keep the
explicit MaxIdleConnections override, and add unit coverage for
the default and override cases. The mismatch was easy to miss
because the code still compiled and basic tests did not assert the
effective idle pool sizing.

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

This commit fixes a minor configuration mismatch in how LND's new SQLite database layer (v2) manages its connection pool. Previously, the default number of idle connections was set to 6, while the default number of open connections was only 2. Go's database library silently limits idle connections to the open-connection cap, so the effective idle pool was already 2, but the configured default was misleading and differed from the older v1 behavior. The change makes the idle default inherit the open-connection default unless the user explicitly overrides it, and adds tests. It is not a security vulnerability.

Lower-prioritysqldb/v2: scope retry rollbacksby yyforyongyu · 115daef4 · Apr 9, 2026 · 1 fileMessage 68 · AdequateLow 33Details
Commit message · yyforyongyu

sqldb/v2: scope retry rollbacks

Scope the safety-net rollback to each retry attempt instead of
storing one deferred rollback per loop iteration.

This keeps cleanup local to the active attempt while
preserving the existing commit and rollback behavior.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 33/100

This change refactors how database transaction retries are cleaned up in LND's SQL layer. Previously, a rollback was scheduled once per loop and could pile up across retries; now each retry attempt gets its own scoped rollback. The commit message frames this as a safety/cleanup improvement, not a reported vulnerability, and the diff shows only a structural refactor with no change to commit or rollback behavior.

Lower-prioritysqldb/v2: validate migration setsby yyforyongyu · 70ab2fc5 · Apr 9, 2026 · 5 filesMessage 78 · AdequateLow 26Details
Commit message · yyforyongyu

sqldb/v2: validate migration sets

Validate migration descriptor ordering before executing a
migration stream so inconsistent metadata fails fast.

In addition to checking contiguous descriptor versions and keeping
LatestMigrationVersion aligned with the last descriptor, reject a
non-zero LatestMigrationVersion when the descriptor list is empty.
Without that guard, a set such as {LatestMigrationVersion: 5}
passed validation silently.

The validation intentionally focuses on version consistency.
Descriptor names remain optional metadata for debugging, and the
checks still run only when migrations execute, which means
SkipMigrations continues to bypass validation by design. Add unit
coverage for the new empty-descriptor case.

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 · Low 26/100

This commit adds a safety check to LND's database migration system. Before running any migration, it now verifies that the list of migration steps matches the declared 'latest version' number. The change prevents a specific misconfiguration where a migration set claims to be at version 5 but contains no actual migration steps, which previously would have passed validation silently. It is a defensive hardening fix rather than a response to an active attack.

Lower-prioritysqldb/v2: harden fixture namesby yyforyongyu · 275fe497 · Apr 9, 2026 · 2 filesMessage 83 · StrongInformational 18Details
Commit message · yyforyongyu

sqldb/v2: harden fixture names

Sanitize Docker container names more aggressively and add a
random suffix so concurrent test runs do not collide on the
same fixture name.

Normalize unsupported characters, trim leading and trailing
punctuation, and keep the fallback name for cases that sanitize
down to nothing. Add unit coverage for the sanitizer so the
allowed name surface stays explicit.

83/100 · StrongMessage clarity
✓ 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
defensive validation
AI analysis · Informational 18/100

This change tightens how test-only Docker container names are built for Postgres test fixtures. It replaces a simple slash-to-underscore replacement with a stricter sanitizer that allows only letters, digits, underscores, and hyphens, trims leading/trailing punctuation, adds a random suffix, and falls back to a default name if the input sanitizes to nothing. The goal is to stop concurrent test runs from creating containers with the same name and to avoid invalid Docker names. It is test infrastructure hardening, not a fix for a user-facing vulnerability.

Lower-prioritysqldb/v2: align test helper argsby yyforyongyu · a0a52734 · Apr 9, 2026 · 1 fileMessage 90 · StrongInformational 15Details
Commit message · yyforyongyu

sqldb/v2: align test helper args

Use the same NewTestDBWithVersion argument order across the
SQLite and Postgres test helpers.

This was a latent build-tag API mismatch rather than a current
package-wide compile failure. Any shared helper that called
NewTestDBWithVersion(t, set, version) would compile under one
backend tag and fail under the other, but the mismatch stayed
hidden because nothing in sqldb/v2 called the helper yet.

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

This is a tiny code cleanup in a test-only helper. It swaps the order of two function arguments in the Postgres test helper so it matches the SQLite test helper. It does not change any production code, user-facing behavior, or runtime security. The commit itself notes it was a hidden build-tag mismatch that had not caused any actual compile failure yet.