LL
← All projectsLightning Labs

LND

Go implementation of a complete Lightning Network node.

BitcoinLightning NetworkNormal
Repository coverage

1400 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
87commits · 30 days
187commits · 60 days
610commits · 180 days
1241commits · 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
656Adequate · 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
ziggieXXX2126070
Analysis record

Published AI watches

Last scanned 1 hour 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.

Lower-prioritygraph/db: version fillTestGraph test helperby Elle Mouton · d48a1603 · Feb 20, 2026 · 1 fileMessage 78 · AdequateInformational 15Details
Commit message · Elle Mouton

graph/db: version fillTestGraph test helper

Make fillTestGraph version-aware and update its call sites to pass an
explicit gossip version (currently v1 at these call sites).

This is a test-helper refactor only; cacheable-iteration API versioning
is handled in the next commit.

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

This commit only changes test code. It updates an internal test helper called fillTestGraph so it can build graph data for either version 1 or version 2 of Lightning's channel-announcement format. All real call sites still pass version 1, so production behavior is unchanged. There is no security issue here.

Lower-prioritygraph/db: add gossip version aliasesby Elle Mouton · 898e4ef8 · Feb 20, 2026 · 1 fileMessage 68 · AdequateInformational 15Details
Commit message · Elle Mouton

graph/db: add gossip version aliases

Introduce gossipV1 and gossipV2 package-level aliases in sql_store.go
to reduce verbosity in version switch statements. Leave hard-coded
v1/v2 call sites untouched so remaining upgrades are obvious.

In other words, it is now easy to see where our remaining work in the
sql_store.go file is by just searching for instances of
`lnwire.GossipVersion1`.

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

This commit is a simple code cleanup in LND's graph database code. It creates two short aliases, gossipV1 and gossipV2, for the existing lnwire.GossipVersion1 and lnwire.GossipVersion2 constants, and replaces many long constant names with the shorter aliases. No behavior changes, no security fixes, and no new features are introduced.

Lower-prioritygraph/db: version ForEachSourceNodeChannelby Elle Mouton · 3ea2423f · Feb 20, 2026 · 6 filesMessage 68 · AdequateInformational 15Details
Commit message · Elle Mouton

graph/db: version ForEachSourceNodeChannel

Add a gossip version parameter to ForEachSourceNodeChannel in the Store
interface and both KV/SQL implementations. The VersionedGraph wrapper
delegates with its baked-in version. Convert the
testAddChannelEdgeShellNodes and testForEachSourceNodeChannel tests to
run against both v1 and v2 gossip versions.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 15/100

This commit is a routine internal refactoring of how LND's channel graph database API passes around gossip protocol versions. It adds a version parameter to one function (ForEachSourceNodeChannel) and moves it from a non-versioned wrapper to a versioned wrapper. There is no security fix or vulnerability here; it is purely code maintenance and test expansion.

Lower-prioritygraph/db: version channelCache by gossip versionby Elle Mouton · 2aaa52ad · Feb 20, 2026 · 4 filesMessage 68 · AdequateLow 34Details
Commit message · Elle Mouton

graph/db: version channelCache by gossip version

Add a channelCacheKey struct keyed by {GossipVersion, chanID}, matching
the pattern already used by rejectCache. This prevents v1 and v2
channel data from colliding in the shared cache.

All callers in KVStore (always GossipVersion1) and SQLStore (version
from context) are updated to pass the version parameter.

This will be needed for later on when we update methods that use this
cache to be versioned (like ChannelUpdatesInHorizon).

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

This commit changes how LND caches Lightning channel information in memory so that entries are separated by gossip protocol version (v1 vs v2). Previously, the cache used only the channel ID, which could let data for the same channel under different protocol versions overwrite or collide with each other. The fix is preventive: it makes the cache key include the version, matching a similar fix already done for another cache. There is no direct evidence in the commit of an exploitable bug or security incident, but cache collisions between protocol versions could theoretically lead to stale or mixed routing data being served to peers.

Security candidateci: add verify-release workflowby ziggie · 5e3d6087 · Feb 13, 2026 · 1 fileMessage 90 · StrongInformational 12Details
Commit message · ziggie

ci: add verify-release workflow

Add a workflow that triggers when a release is published. It runs
verify-install.sh inside the official Docker image to validate
signatures and binary hashes. If verification fails, the release
is automatically set back to draft.

90/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing boundarydefensive validationdocumentation-only discount
AI analysis · Informational 12/100

This commit adds a new GitHub Actions workflow that automatically checks a newly published LND software release for valid digital signatures and matching binary hashes. If the check fails, the release is reverted to draft status so users are not exposed to a potentially bad release. It is a defensive hardening change, not a vulnerability fix or malicious change.

Security candidatescripts: switch verify-install.sh from curl to wgetby ziggie · 99eceba7 · Feb 13, 2026 · 2 filesMessage 88 · StrongLow 29Details
Commit message · ziggie

scripts: switch verify-install.sh from curl to wget

Replace curl with wget for downloading release manifests and
signatures in verify-install.sh. wget handles redirects, retries, and
error reporting more robustly by default, which avoids silent download
failures that caused misleading "Invalid signature!" errors.

Also add error checking to all download calls so failures are reported
immediately with the URL that failed, and log which signature file and
user failed gpg verification.

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

This commit changes the LND release verification helper script from using curl to using wget, and adds clearer error messages when downloads fail. The practical security issue being fixed is that curl could silently fail to download release signatures, which then made the script wrongly report 'Invalid signature!' instead of admitting the file simply didn't download. That misleading error could confuse users or hide network/download problems during install verification. It is a hardening/usability fix in a verification helper, not a fix for a vulnerability in the Lightning node itself.

Security candidatescripts: log failing signature details in verify-installby ziggie · b7c47559 · Feb 13, 2026 · 1 fileMessage 88 · StrongInformational 19Details
Commit message · ziggie

scripts: log failing signature details in verify-install

When gpg --verify fails, include the signature filename, username,
and full GPG output in the error message. Previously only a generic
"Invalid signature!" was printed, making it hard to identify which
signer's signature was invalid.

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

This commit improves an error message in a release-verification script. When a GPG signature check fails, it now prints the signature filename, the username, and the full GPG output instead of just a generic 'Invalid signature!' message. This is a usability/debugging improvement, not a security fix.

Lower-priorityci: use haiku model for issue dedupe workflowby Elle Mouton · 5f429f0a · Feb 13, 2026 · 1 fileMessage 80 · StrongInformational 15Details
Commit message · Elle Mouton

ci: use haiku model for issue dedupe workflow

Switch the claude-dedupe-issues workflow from the default (most
expensive) model to claude-haiku-4-5, which is significantly cheaper
and sufficient for issue duplicate detection.

80/100 · StrongMessage clarity
✓ 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 a GitHub automation workflow to use a cheaper AI model for detecting duplicate bug reports. It is a cost-saving configuration change with no security relevance.

Lower-priorityscripts: use ephemeral gocache in check-each-commitby Andras Banki-Horvath · 75de3e3b · Feb 13, 2026 · 1 fileMessage 50 · ThinInformational 15Details
Commit message · Andras Banki-Horvath

scripts: use ephemeral gocache in check-each-commit

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

This change modifies a developer script so that each time it runs, it uses a temporary, throwaway Go build cache instead of the user's normal cache. It then deletes that temporary cache when the script finishes. This is a housekeeping fix to prevent the build cache from growing too large on disk over time. It does not change any code that handles money, network messages, cryptography, or user data, and it does not fix a security vulnerability.

Lower-prioritydocs: add release notes for gossip v2 policy supportby Elle Mouton · 4d4b42d0 · Feb 13, 2026 · 2 filesMessage 62 · AdequateInformational 15Details
Commit message · Elle Mouton

docs: add release notes for gossip v2 policy support

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

This commit only updates release notes and reformats a single line in a test file. There is no functional code change and no security relevance.

AI review queuedgraph/db: update policy builders to support v2 fieldsby Elle Mouton · 40e3ac96 · Feb 13, 2026 · 3 filesMessage 73 · AdequateLow 34Details
Commit message · Elle Mouton

graph/db: update policy builders to support v2 fields

Update buildChanPolicy and related functions in both KV and SQL stores
to properly construct ChannelEdgePolicy with version-specific fields:

KVStore changes:
- Reject non-v1 policies in updateEdgePolicy and serializeChanEdgePolicy
since KV store only supports v1 gossip protocol.
- Set Version to GossipVersion1 when deserializing policies from KV.

SQLStore changes:
- Add isNode1 parameter to buildChanPolicy functions to properly set
SecondPeer field (v2 uses SecondPeer instead of ChannelFlags direction).
- Extract Version from database and populate version-specific fields:
- For v1: MessageFlags, ChannelFlags, LastUpdate, ExtraOpaqueData
- For v2: DisableFlags, LastBlockHeight, ExtraSignedFields
- Thread isNode1 through buildChanPolicyWithBatchData and
buildCachedChanPolicies call sites.

This enables the SQL store to read and reconstruct both v1 and v2
channel policies from the database with proper field mapping.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
second-pass: broader security terminology
AI analysis · Low 34/100

This commit updates how the Lightning Network Daemon (LND) stores and rebuilds channel routing policies in its graph database. It adds support for a newer gossip protocol version (v2) in the SQL backend, while the older KV backend is now explicitly restricted to version 1. The changes are primarily about correct data mapping and preventing unsupported versions from being written to the wrong database backend. There is no direct evidence in the commit of an exploitable security vulnerability, but the change touches consensus-relevant routing data and fixes version-handling gaps that could theoretically cause nodes to propagate or accept malformed policy information.

Lower-prioritygraph/db: refactor CachedEdgePolicy to use explicit boolean fieldsby Elle Mouton · 9c7a12c0 · Feb 13, 2026 · 5 filesMessage 83 · StrongInformational 14Details
Commit message · Elle Mouton

graph/db: refactor CachedEdgePolicy to use explicit boolean fields

Replace MessageFlags and ChannelFlags bitfields in CachedEdgePolicy
with explicit boolean fields to improve clarity and support both v1
and v2 channel updates:

- Replace MessageFlags with HasMaxHTLC boolean.
- Replace ChannelFlags with IsNode1 and IsDisabled booleans.
- Update NewCachedPolicy to extract these fields version-appropriately:
- For v1: derive from MessageFlags and ChannelFlags bits.
- For v2: derive from policy.SecondPeer and policy.DisableFlags.

Update all call sites that used method calls IsNode1() and IsDisabled()
to instead access the fields directly. This includes:
- graph_cache.go: policy direction and disable checks
- unified_edges.go: HasMaxHTLC and IsDisabled checks
- Tests: policy construction and assertions

This refactoring improves readability by making the cached policy's
state explicit rather than encoded in bitfields, and enables seamless
support for both gossip protocol versions.

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

This commit is a straightforward internal code cleanup in LND's routing graph cache. It replaces compact bit-field flags with clearly named true/false fields (e.g., 'IsDisabled', 'IsNode1', 'HasMaxHTLC') and updates the code that reads them. There is no security fix or externally reported vulnerability here; it is a readability and maintainability refactor that also prepares the code for a newer gossip protocol version.

Security candidategraph/db: add v2 fields to ChannelEdgePolicy modelby Elle Mouton · 3fe40c65 · Feb 13, 2026 · 15 filesMessage 73 · AdequateInformational 19Details
Commit message · Elle Mouton

graph/db: add v2 fields to ChannelEdgePolicy model

Extend ChannelEdgePolicy to support v2 channel updates by adding:

- Version field to track gossip protocol version (v1 or v2).
- LastBlockHeight for v2's block-height-based timestamps.
- SecondPeer flag to indicate which peer announced the policy in v2.
- DisableFlags for v2-specific channel disable signaling.
- ExtraSignedFields map for v2 extra signed TLV data.

Add version-aware methods:
- IsNode1() determines if the policy was announced by node_1, handling
both v1 (via ChannelFlags direction bit) and v2 (via SecondPeer).
- IsDisabled() checks disable status using ChannelFlags for v1 and
DisableFlags for v2.
- String() provides version-appropriate string representations.

The new fields use zero values for v1 compatibility (Version defaults
to GossipVersion1, LastBlockHeight to 0, SecondPeer to false). This
lays the groundwork for v2 policy support; a subsequent commit will
handle reading and writing these fields from/to the database.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
boot or update path
AI analysis · Informational 19/100

This commit is a preparatory code change for the Lightning Network gossip protocol. It extends an internal data structure (ChannelEdgePolicy) to store new fields needed for a future 'v2' channel-update format, while keeping existing 'v1' behavior unchanged. It does not, by itself, fix or introduce a security vulnerability; it is groundwork for a later feature.

Lower-prioritygraph/db: add versioned HasChannelEdge methodby Elle Mouton · 506ec037 · Feb 13, 2026 · 8 filesMessage 68 · AdequateLow 34Details
Commit message · Elle Mouton

graph/db: add versioned HasChannelEdge method

Add a new HasChannelEdge method that takes a gossip version parameter
and returns only existence and zombie status, without timestamp data.
This supports both v1 and v2 gossip protocols.

The original HasChannelEdge method is renamed to HasV1ChannelEdge to
preserve v1-specific functionality for callers that need timestamp
information. All call sites are updated accordingly.

The SQL store implementation now handles both gossip versions, using
timestamps for v1 and block heights for v2 policies, with proper
reject cache support for both versions.

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

This commit refactors how LND checks whether a Lightning channel edge exists in its graph database, adding support for both v1 and v2 gossip protocols. It is a code-maintenance and feature-extension change, not a direct security fix. There is no vendor statement or external report linking it to a known vulnerability, and the diff does not show a patch for an exploitable bug. However, because it touches core graph/caching logic, any mistake could affect routing or spam handling, so it warrants normal review rather than urgent response.

Lower-prioritysqldb: use version-specific staleness checks in UpsertChannelPolicyby Elle Mouton · 677e6ea8 · Feb 13, 2026 · 2 filesMessage 73 · AdequateLow 46Details
Commit message · Elle Mouton

sqldb: use version-specific staleness checks in UpsertChannelPolicy

Update the UpsertChannelPolicy query to apply different staleness
checks based on gossip version. For v1 policies, continue checking
last_update timestamps. For v2 policies, check block_height instead,
using >= comparison to handle policies from the same block.

The version-specific WHERE clause ensures that policy updates are only
applied when they contain newer information according to the versioning
scheme appropriate for that gossip version.

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

This change fixes how LND stores routing policy updates received over the Lightning network gossip protocol. Different gossip versions use different freshness indicators: v1 uses a timestamp, while v2 uses a block height. Previously the code always compared timestamps, which could cause newer v2 policies to be ignored if their timestamp was older, or stale v2 policies to overwrite newer ones. The patch makes the database update conditional on the correct freshness field for each gossip version.

Lower-prioritygraph/db: add gossip version parameter to ForEachChannelby Elle Mouton · 0cfb9c9d · Feb 13, 2026 · 7 filesMessage 73 · AdequateInformational 15Details
Commit message · Elle Mouton

graph/db: add gossip version parameter to ForEachChannel

Update ForEachChannel to accept a gossip version parameter, allowing
callers to specify which gossip version's channels should be iterated.
This change prepares the graph database for supporting multiple gossip
versions while maintaining backward compatibility.

The KVStore implementation validates that only GossipVersion1 is
requested, returning ErrVersionNotSupportedForKVDB for other versions.
The SQLStore implementation validates known versions and passes the
version through to the underlying paginated query.

Update VersionedGraph to include a ForEachChannel method that
automatically uses its configured gossip version, and update the
DescribeGraph RPC handler to use the v1Graph instead of the global
graphDB.

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

This commit is a routine internal refactoring of how the Lightning Network graph database iterates over channels. It adds a 'gossip version' parameter to the ForEachChannel function so the code can later support multiple gossip versions, but currently only version 1 is supported. There is no security fix or vulnerability present in the change itself.

Lower-prioritygraph/db: convert testEdgePolicyCRUD to versioned testby Elle Mouton · d948c5bf · Feb 13, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Elle Mouton

graph/db: convert testEdgePolicyCRUD to versioned test

Convert testEdgePolicyCRUD to a versioned test that runs against both
v1 and v2 gossip versions. Update the test to use version-specific
edge creation helpers and to test version-specific fields and flag
behavior (ChannelFlags/MessageFlags for v1, DisableFlags/
ExtraSignedFields for v2).

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 changes a test file. It converts an existing test so it runs against two versions of the network gossip protocol, using version-specific helpers and fields. There is no change to production code, no bug fix, and no security-relevant behavior change.

Lower-prioritygraph/db: add gossip version parameter to ForEachNodeChannelby Elle Mouton · 1e35f258 · Feb 13, 2026 · 7 filesMessage 73 · AdequateInformational 14Details
Commit message · Elle Mouton

graph/db: add gossip version parameter to ForEachNodeChannel

Update ForEachNodeChannel to accept a gossip version parameter,
allowing callers to specify which gossip version's channels should be
iterated. This change mirrors the approach taken in ForEachChannel and
prepares the graph database for supporting multiple gossip versions
while maintaining backward compatibility.

The Store interface is updated to include the version parameter, and
both KVStore and SQLStore implementations are updated accordingly:

- KVStore validates that only GossipVersion1 is requested, returning
ErrVersionNotSupportedForKVDB for other versions.
- SQLStore passes the version through to the underlying node query,
enabling version-specific channel iteration.

The ChannelGraph wrapper is updated to accept and pass through the
version parameter. VersionedGraph gains a ForEachNodeChannel method
that automatically uses its configured gossip version, providing a
clean interface for version-specific operations.

Update all call sites to explicitly pass lnwire.GossipVersion1, except
for the local channel manager in server.go which now uses the v1Graph
directly (matching the pattern used in other parts of the codebase).

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
defensive validation
AI analysis · Informational 14/100

This commit is a routine internal refactoring of how LND's network graph database iterates over a node's channels. It adds a 'gossip version' parameter to one function so the code can eventually support multiple versions of Lightning channel gossip, but currently only version 1 is used. There is no security fix or vulnerability here.

Lower-prioritymulti: add ChanEdgePolicyFromWire constructor for ChannelEdgePolicyby Elle Mouton · a73c4594 · Feb 13, 2026 · 4 filesMessage 83 · StrongInformational 15Details
Commit message · Elle Mouton

multi: add ChanEdgePolicyFromWire constructor for ChannelEdgePolicy

Add ChanEdgePolicyFromWire to construct ChannelEdgePolicy from channel
update messages, centralizing v1/v2 field mapping.
Update call sites to use the helper:

- discovery/gossiper: handleChanUpdate
- graph/builder: ApplyChannelUpdate
- routing/router_test: ApplyChannelUpdate test helper

This consolidates update-to-policy conversion logic across versions.

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 is a straightforward code cleanup: it creates a single helper function that builds an internal data structure from two different kinds of channel update messages, and updates three places to use that helper. There is no change to security behavior, no bug fix, and no disclosed vulnerability.

Lower-prioritygraph/db: set policy version for cache loadby Elle Mouton · bd215b1a · Feb 13, 2026 · 1 fileMessage 60 · AdequateLow 46Details
Commit message · Elle Mouton

graph/db: set policy version for cache load

Ensure policies loaded for graph cache reconstruction are tagged as v1.

60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
AI analysis · Low 46/100

This small code change fixes a bug where Lightning Network routing policies loaded from the database into an in-memory cache were missing a version tag. The fix explicitly marks them as version 1 policies. Without the version set, other parts of the node that rely on the version field could misinterpret the policy, potentially causing incorrect fee or time-lock calculations when routing payments through the network.

Lower-prioritygraph/db: version reject cache for policiesby Elle Mouton · 4a6213c3 · Feb 13, 2026 · 4 filesMessage 68 · AdequateLow 26Details
Commit message · Elle Mouton

graph/db: version reject cache for policies

Make the reject cache version-aware so v1 and v2 policy state can be
cached independently per channel ID. Add helpers to store v1 timestamps
or v2 block heights and thread the versioned cache key through KV/SQL
store cache accesses.

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

This commit reworks an in-memory cache in LND's channel graph database so that it can separately store metadata for two different gossip protocol versions (v1 and v2). The change is mostly a correctness/performance improvement to avoid cache collisions between versions, but it also fixes places where the SQL backend was not invalidating or updating the cache with the correct version key. There is no direct evidence in the commit message or diff that this is a security fix, and no CVE or advisory is referenced.

Security candidategraph/db: support v2 channel proofs in AddEdgeProofby Elle Mouton · 99d622ca · Feb 13, 2026 · 2 filesMessage 78 · AdequateLow 32Details
Commit message · Elle Mouton

graph/db: support v2 channel proofs in AddEdgeProof

Update AddEdgeProof to handle both v1 (four separate signatures) and
v2 (single aggregated signature) channel authentication proofs using
the appropriate SQL queries.

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 boundaryaccess control
AI analysis · Low 32/100

This commit extends a database function in the LND Lightning node so it can store both old-style (v1) and new-style (v2) channel authentication proofs. Previously, the code only accepted v1 proofs and would reject v2 proofs with an error. The change is a feature completion / bug fix for the new gossip protocol support, not a fix for an active security vulnerability. It adds the matching SQL query and tests for both versions.

Security candidategraph/db: treat empty channel signatures as missingby Elle Mouton · 6328c4d8 · Feb 13, 2026 · 5 filesMessage 100 · StrongModerate 51Details
Commit message · Elle Mouton

graph/db: treat empty channel signatures as missing

This commit improves handling of missing channel signatures in the
database:

- Return nil from auth proof accessors instead of empty slices so that
missing signatures are stored as NULL in SQL.
- Update public channel checks to require signature length > 0, which
properly handles existing empty bytea values in the database.
- Add regression test covering empty v1 and v2 channel signatures to
prevent future issues.

100/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✓ Names security-relevant behavior explicitly
Why it was queued
signing boundaryfuzzing or regression evidenceauthentication path
AI analysis · Moderate 51/100

This commit fixes a bug in LND's Lightning Network graph database where empty channel signatures were being treated as valid proof that a channel was publicly announced. Because the code previously treated empty byte slices the same as real signatures, a node connected only by such a 'channel' could incorrectly be considered public. The fix makes the database store empty signatures as NULL and changes all public-channel checks to require a signature length greater than zero. The commit message frames this as a correctness improvement and adds regression tests, but does not label it a security vulnerability.

Lower-prioritygraph/db: make TestPartialNode version-awareby Elle Mouton · dcd0b9da · Feb 13, 2026 · 1 fileMessage 78 · AdequateInformational 15Details
Commit message · Elle Mouton

graph/db: make TestPartialNode version-aware

Convert TestPartialNode to a versioned test that runs for both v1 and
v2 gossip versions, ensuring shell node creation works correctly for
both channel types.

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

This commit only changes a test file. It converts an existing single-version test into a versioned test that runs against both v1 and v2 gossip protocol versions. There is no change to production code, no bug fix, and no security-relevant behavior change.

Lower-prioritymulti: add DeleteChannelEdges to VersionedGraphby Elle Mouton · b3cf9a80 · Feb 13, 2026 · 5 filesMessage 68 · AdequateLow 26Details
Commit message · Elle Mouton

multi: add DeleteChannelEdges to VersionedGraph

Add version-aware DeleteChannelEdges method to VersionedGraph and
update call sites in graph builder, rpcserver, and server to use
versioned graphs. This ensures channel deletion operations are
properly scoped to the correct gossip version.

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

This commit refactors how LND deletes channel edges from the network graph so that deletions go through a new version-aware wrapper. The change is mostly a code cleanup to support multiple gossip graph versions, but it includes a TODO noting that one RPC path still only supports v1 channel deletions. There is no direct evidence in the commit of an exploitable security bug.