LL
← All projectsLightning Labs

LND

Go implementation of a complete Lightning Network node.

BitcoinLightning NetworkNormal
Repository coverage

1399 commits in the local evidence base

Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.

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

Does the history explain itself?

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

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

Who is changing the project?

Public Git author strings; identities are not independently verified.

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

Published AI watches

Last scanned 35 minutes ago

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

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

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

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

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

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

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

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

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

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

zpay32: reject duplicate payment hash fields

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

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

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

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

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

itest: stop creating legacy channels

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

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

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

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

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

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

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

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

build: adopt focused golangci-lint v2.13 checks

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

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

lnrpc: regenerate protos with Go 1.27

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

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

build: fix Go 1.27 compatibility

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

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

build: bump Go language and toolchain versions

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

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

invoices: cancel only the failing AMP set on reconstruction failure

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

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

bolt12: describe the lnwire dependency

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

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

bolt12: cover the amount overflow guard

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

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

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

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

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

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

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

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

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

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

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

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

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

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

bolt12: verify invoice_request and invoice signatures on read

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

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

Explore captured commits

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

Lower-prioritypeer: add test for createHtlcValidatorby George Tsagkarelis · 8d30e7d1 · Mar 4, 2026 · 1 fileMessage 55 · ThinInformational 15Details
Commit message · George Tsagkarelis

peer: add test for createHtlcValidator

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

This commit only adds a new unit test for an existing function called createHtlcValidator. It does not change any production code, so it cannot introduce a security vulnerability or fix one directly. The test checks that the validator correctly skips bandwidth checks for non-custom channels and properly handles bandwidth and error cases for custom channels.

AI review queuedlnwallet: add aux test utilsby George Tsagkarelis · 1edf8123 · Mar 4, 2026 · 1 fileMessage 78 · AdequateInformational 15Details
Commit message · George Tsagkarelis

lnwallet: add aux test utils

We add this constructor for an AuxHtlcDescriptor that allows setting
some of the internal fields. This is useful for testing purposes for
code external to this package that may need to extensively test the
AuxHtlcView.

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

This commit adds a small helper function used only in tests. It creates a test-only object for constructing Lightning Network payment descriptors with specific values. There is no change to production code, no user-facing behavior change, and no security fix or vulnerability introduced.

Lower-prioritypeer: set and use aux htlc validatorby George Tsagkarelis · b1701cf2 · Mar 4, 2026 · 1 fileMessage 68 · AdequateModerate 57Details
Commit message · George Tsagkarelis

peer: set and use aux htlc validator

When instantiating the lightning channel we now pass in the created HTLC
validator. This validator simply performs a bandwidth check and errors
out if that is insufficient.

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

This commit adds a final safety check for a new type of Lightning payment channel feature. Before an HTLC (a pending payment) is locked into the channel state, the code now asks an external 'traffic shaper' whether the channel has enough bandwidth. This closes a race condition where multiple payments could be approved based on outdated balance information. It is a defensive hardening change, not a fix for a known active exploit, and it only applies when the optional aux traffic shaper is in use.

AI review queuedlnwallet: add and use AuxHtlcValidator to lightning channelby George Tsagkarelis · 773b2c1c · Mar 4, 2026 · 1 fileMessage 73 · AdequateLow 42Details
Commit message · George Tsagkarelis

lnwallet: add and use AuxHtlcValidator to lightning channel

Previously we'd perform aux bandwidth checks during path finding. This
could lead to issues where multiple HTLCs where querying the same
bandwidth but were not accounting for each other before being added to
the commitment log. We now add a new validator function that will serve
as the last point of checks before adding the HTLC to the commitment.

During path finding HTLCs could query channel bandwidth asynchronously.
At this new call site all HTLCs that are about to be added to the
channel have been organised in sequence, so it's safe to query bandwdith
again at this point as we're getting the actual up-to-date values.

We remove the aux bandwidth check from the helper canSendHtlc, which was
called from CheckHTLCTransit and CheckHTLCForward (both are methods of
the htlcswitch).

For forwards we now fail at the link level, following the introduction
of the AuxHtlcValidator.

For payments, we now may fail either at the pathfinding level, or at the
link level. The htlcswitch may no longer fail for aux bandwidth checks.

Finally, when fetching the latest htlc view (for bandwidth checks during
pathfinding) we'd silently set the nextHeight of the view to the default
zero value. We now make sure to set it to the correct nextHeight value.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 42/100

This commit changes how Lightning Network channels check whether a special 'custom' payment (HTLC) can be added. Previously, bandwidth checks for these custom payments happened earlier, while routes were still being planned, and multiple payments could look at the same balance without knowing about each other. The new code moves the final check to the moment just before the payment is committed to the channel, using the most up-to-date balance and a corrected view of pending payments. It also fixes a bug where a height counter used in these checks was being left at zero. The change is defensive and aimed at preventing inconsistent or over-committed custom channel states rather than a classic remote exploit.

Lower-prioritydocs: add release-notesby ziggie · d767c1e7 · Mar 4, 2026 · 1 fileMessage 40 · ThinInformational 16Details
Commit message · ziggie

docs: add release-notes

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

This commit only adds a line to the release notes describing a previously merged performance fix. It does not change any code, configuration, or behavior. The underlying change it documents replaced a slow database query with faster ones and removed redundant database indexes, which improves efficiency but is not a security patch.

AI review queuedscripts: fix backwards compatibility test timing issuesby ziggie · f6f60649 · Mar 4, 2026 · 5 filesMessage 95 · StrongInformational 15Details
Commit message · ziggie

scripts: fix backwards compatibility test timing issues

The backwards compatibility test was failing intermittently due to two
related timing issues in the test setup.

The issue was that Dave's `wait_graph_sync dave 3` was hanging
for up to 60 minutes. Dave's initial gossip sync with Charlie could
complete before Charlie had forwarded the alice-bob channel
announcement, leaving Dave stuck at 2 channels until lnd's historical
syncer fired at its default interval of 1 hour. After this 1-hour idle,
some routing state had become stale, causing the subsequent payment from
alice to dave to fail with FAILURE_REASON_NO_ROUTE.

This issues is now addressed by setting `--historicalsyncinterval=10s` on
all nodes. This causes nodes to periodically re-sync the full gossip
state from their peers every 10 seconds instead of every hour. Dave
therefore picks up any missed channel announcements and routing policies
within seconds, and alice's routing graph stays up-to-date throughout
the test.

Additionally, lnd debug logs from all containers are now collected
before teardown on failure and uploaded as a CI artifact, making future
failures easier to diagnose.

95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 15/100

This commit fixes a flaky test in the LND project's backwards-compatibility test suite. It changes how often test nodes re-sync gossip information from once per hour to every 10 seconds, preventing a race condition where one node would miss channel announcements and get stuck. It also adds collection of debug logs when the test fails so developers can diagnose future failures more easily. There is no security vulnerability being fixed here.

Lower-prioritysqldb: remove unused GetInvoice queryby ziggie · e751d96c · Mar 4, 2026 · 3 filesMessage 45 · ThinInformational 15Details
Commit message · ziggie

sqldb: remove unused GetInvoice query

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

This commit simply deletes an unused database query and its generated helper code. No behavior changes, no bug fixes, and no security implications.

Lower-priorityinvoices: use longer timeout for HTLC resolution in AMP testby ziggie · 7995e87b · Mar 4, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · ziggie

invoices: use longer timeout for HTLC resolution in AMP test

Under parallel Postgres test load, the event loop must complete
sequential DB writes after SetTime fires. Using testTimeout (5s)
is too tight; switch the three blocking hodlChan selects in
testFailPartialAMPPayment to testTimeoutLong (1 minute) to
match the pattern already used elsewhere for slow backends.

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 test code. It makes three timeout waits in an AMP invoice test longer so the test does not flake under slow Postgres test runners. There is no change to production code, no user-facing behavior change, and no security fix.

Lower-priorityinvoices/sql: replace catch-all GetInvoice with indexed lookupsby ziggie · 0ca69e6f · Mar 4, 2026 · 4 filesMessage 95 · StrongLow 46Details
Commit message · ziggie

invoices/sql: replace catch-all GetInvoice with indexed lookups

The GetInvoice query used an OR IS NULL pattern for each filter
parameter:

WHERE (i.hash = $1 OR $1 IS NULL)
AND (i.payment_addr = $2 OR $2 IS NULL)

SQLite's query planner decides on an execution plan at prepare time,
before seeing any parameter values. Because either condition can be
trivially true when its parameter is NULL, the planner conservatively
falls back to a full table scan rather than using the unique indexes on
hash and payment_addr. This caused every invoice lookup and update on
the hot path (HTLC settlement) to scan the entire invoices table.

Replace the single catch-all query with three dedicated queries, each
using a direct equality on a uniquely constrained column:

- GetInvoiceByHash: WHERE hash = $1
- GetInvoiceByAddr: WHERE payment_addr = $1 (new, covers AMP path)
- GetInvoiceBySetID: existing, unchanged

Update getInvoiceByRef to route to the appropriate query based on which
fields are present in the InvoiceRef. When both hash and payment address
are provided, we look up by hash and then verify the returned invoice's
payment address matches.

GetInvoice is now unused and removed from the SQLInvoiceQueries
interface.

95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
AI analysis · Low 46/100

This commit fixes a database performance bug in LND's invoice handling. The old code used a flexible query that could match by payment hash, payment address, or neither, which made the database scan the entire invoices table for every lookup. The new code uses specific, indexed queries so lookups are fast. The change also adds a check that prevents a caller from providing a payment hash and payment address that point to different invoices. There is no direct evidence in the commit that this was a security vulnerability, but the performance issue could contribute to denial-of-service under load.

AI review queuedinvoices: add TODO to change the return type of the queryby ziggie · e2dfd8f0 · Mar 4, 2026 · 3 filesMessage 30 · OpaqueInformational 15Details
Commit message · ziggie

invoices: add TODO to change the return type of the query

30/100 · OpaqueMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body! Contains work-in-progress language
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 15/100

This commit only adds code comments (TODOs) suggesting a future cleanup: a database query currently returns a list of invoices, but because of the table's primary key it can actually return at most one. No code behavior is changed, so there is no security issue in this commit itself.

Lower-prioritysqldb: drop redundant and unused invoice indexesby ziggie · 65f6d755 · Mar 4, 2026 · 3 filesMessage 68 · AdequateInformational 15Details
Commit message · ziggie

sqldb: drop redundant and unused invoice indexes

Remove four indexes from the invoices table that either duplicate existing
UNIQUE constraint indexes or are never used in WHERE clauses:

- invoices_hash_idx: redundant, UNIQUE constraint on hash already creates
an implicit index
- invoices_payment_addr_idx: redundant, UNIQUE constraint on payment_addr
already creates an implicit index
- invoices_preimage_idx: unused, preimage is NULL on all new invoices and
is never used as a query filter
- invoices_settled_at_idx: unused, settled_at is NULL on all pending
invoices and is never used as a query filter (settle_index is used
instead)

Dropping these reduces B-tree working set size, which improves page cache
utilization as the invoice table grows.

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

This commit removes four database indexes from LND's invoice table. Two are unnecessary because the same columns already have unique-constraint indexes. The other two are reportedly never used in queries. The stated goal is to reduce memory and storage overhead, not to fix a security issue. There is no indication this change introduces a vulnerability.

Lower-prioritysqldb: add benchmark for sqlite connection numberby ziggie · de06c29a · Mar 3, 2026 · 1 fileMessage 68 · AdequateInformational 15Details
Commit message · ziggie

sqldb: add benchmark for sqlite connection number

The results suggests that the default of 2 is a good conservative
approach. The higher the connection number and the higher the
workload the performance decreases in WAL mode since readers still
need coordination (WAL index shm for example).

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

This commit only adds two benchmark tests that measure how fast SQLite reads perform with different numbers of database connections. It does not change any production code, configuration defaults, or behavior of the LND software. There is no security issue here.

Lower-priorityrecord: add func for non-final om route databy Gijs van Dam · 68cdb4e3 · Mar 2, 2026 · 1 fileMessage 60 · AdequateInformational 12Details
Commit message · Gijs van Dam

record: add func for non-final om route data

Adds the NewNonFinalBlindedRouteDataOnionMessage function to create
blinded route data specifically for onion messages.

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

This commit adds a new helper function in LND's code for constructing routing data used in a privacy-preserving messaging feature called 'blinded routes' for onion messages. It is a pure code addition with no obvious security bug, no fix of a vulnerability, and no disclosed security relevance.

Lower-prioritylnwire: add OnionMessagePayloadby Gijs van Dam · 6a37f78b · Mar 2, 2026 · 3 filesMessage 58 · ThinInformational 21Details
Commit message · Gijs van Dam

lnwire: add OnionMessagePayload

The new wire message defines the OnionMessagePayload, FinalHopPayload,
ReplyPath, and related TLV encoding/decoding logic.

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
AI analysis · Informational 21/100

This commit adds new code to LND that handles a new kind of Lightning network message called an 'onion message payload.' It is a feature addition, not a fix. The code reads and writes message fields such as reply paths, encrypted recipient data, and special sub-messages for invoices. There is no direct evidence in the commit that this introduces a security vulnerability, but any new network parser can carry implementation risks.

Lower-prioritygo: update lightning-onionby Gijs van Dam · 14024fc8 · Mar 2, 2026 · 5 filesMessage 50 · ThinLow 31Details
Commit message · Gijs van Dam

go: update lightning-onion

Update lightning-onion to commit that includes onion-messaging support.

50/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides an explanatory body
AI analysis · Low 31/100

This commit updates a core Lightning Network library (lightning-onion) to a new version that adds 'onion-messaging support.' It also adjusts LND's own code to match renamed constants and functions in that library. The change is presented as a routine dependency update, but because the library handles the encrypted routing packets that every Lightning payment uses, any change there can affect payment privacy and correctness. There is no direct evidence in the commit of a security bug or fix, and no vendor statement that this update is security-related.

Lower-prioritydocs: release notes for v0.21.0by Gijs van Dam · 061b89a4 · Mar 2, 2026 · 1 fileMessage 57 · ThinInformational 15Details
Commit message · Gijs van Dam

docs: release notes for v0.21.0

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

This commit is a documentation-only edit to the release notes for LND version 0.21.0. It rewords a bullet point about a new 'onion messaging forwarding' feature and adds a link to an additional pull request. No code, configuration, or security behavior is changed.

Lower-priorityonionmessage: add LRU cache to SCID resolverby Gijs van Dam · 73e09838 · Mar 2, 2026 · 2 filesMessage 80 · StrongInformational 12Details
Commit message · Gijs van Dam

onionmessage: add LRU cache to SCID resolver

Add an LRU cache to GraphNodeResolver to avoid repeated database lookups
when resolving SCIDs to node public keys. The cache stores up to 1000
compressed pubkey entries, which is sufficient for typical onion message
forwarding scenarios.

This change also introduces a NewGraphNodeResolver constructor to
properly initialize the cache, replacing direct struct literal usage.

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

This commit adds a small in-memory cache to speed up repeated lookups of which node public key belongs to a given short channel ID (SCID). It is a performance optimization, not a security fix. There is no evidence in the commit or supplied references that it addresses a vulnerability.

AI review queuedmulti: actor-based onion message forwardingby Gijs van Dam · ba27627a · Mar 2, 2026 · 22 filesMessage 68 · AdequateLow 39Details
Commit message · Gijs van Dam

multi: actor-based onion message forwarding

Add onion message forwarding capability using the OnionPeerActor for
communication. Messages are routed through a receptionist pattern where
each peer has a dedicated OnionPeerActor for handling message sends.

The OnionEndpoint uses the sphinx router for decoding and decrypting the
onion message packet and the encrypted recipient data in the payload of
the onion messages.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
second-pass: unusually broad change
AI analysis · Low 39/100

This commit adds the ability for LND nodes to forward encrypted 'onion messages' through intermediate peers, rather than only sending them directly. It introduces new actor-based code for routing these messages, expands the RPC API response to expose more message details, and adds integration tests. There is no direct evidence in the commit that this fixes a known security bug; it appears to be a feature implementation. However, any new message-forwarding path can affect privacy, denial-of-service exposure, and correctness of cryptographic handling, so it warrants careful review.

Lower-prioritymulti: add sphinx router without replay protectionby Gijs van Dam · 50b34e96 · Mar 2, 2026 · 2 filesMessage 73 · AdequateInformational 24Details
Commit message · Gijs van Dam

multi: add sphinx router without replay protection

Initialize a sphinx router without persistent replay protection logging
for onion message processing. Onion messages don't require replay
protection since they don't involve payment routing.

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

This commit adds a separate onion-message router that deliberately skips the usual replay-protection logging used for payment routing. The change is intentional and documented: onion messages are not payments, so replay protection is considered unnecessary. There is no direct evidence in the commit of a vulnerability being fixed; it looks like feature plumbing for onion messaging support.

AI review queuedmulti: add --protocol.no-onion-messages flagby Gijs van Dam · aef47fd6 · Mar 2, 2026 · 5 filesMessage 68 · AdequateInformational 19Details
Commit message · Gijs van Dam

multi: add --protocol.no-onion-messages flag

This commit adds a configuration flag to disable onion messaging support.
When set, lnd will:
- Not advertise the onion messages feature bit (39) in init and node
announcements
- Skip creating the OnionEndpoint at server startup
- Not register an onion message handler with peers, so incoming onion
messages are not processed

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
parser or protocol pathsecond-pass: security-sensitive path
AI analysis · Informational 19/100

This commit adds a new user-configurable switch that lets an LND node operator turn off support for "onion messages" (a type of Lightning network control message). When the switch is enabled, the node stops advertising that it supports the feature, does not create the internal component that handles those messages, and ignores incoming onion messages. It is a defensive feature addition, not a fix for an active bug or vulnerability, and it does not change default behavior.

Lower-prioritymulti: OnionPeerActor for per-peer message supportby Gijs van Dam · f464fb9c · Mar 2, 2026 · 12 filesMessage 83 · StrongLow 31Details
Commit message · Gijs van Dam

multi: OnionPeerActor for per-peer message support

Introduce a fat OnionPeerActor that handles the full onion message
processing pipeline for each peer connection. The actor decodes incoming
onion messages, determines the routing action (forward or deliver),
executes the action via PeerMessageSender, and dispatches updates to
subscribers via OnionMessageUpdateDispatcher.

Key components:
- OnionRouter interface abstracting sphinx router operations
- PeerMessageSender interface for forwarding to other peers
- OnionMessageUpdateDispatcher interface for subscriber notifications
- OnionActorFactory for spawning per-peer actors with shared deps
- Full test suite calling Receive() directly with NoOpReplayLog

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

This commit adds a new subsystem for handling 'onion messages' in the LND Lightning node. Onion messages are a way to send data through the Lightning network without a payment. The change introduces a per-peer actor that decodes, routes, and forwards or delivers these messages. It is a large feature addition with new interfaces, routing logic, and tests. There is no direct evidence in the commit that this fixes a known security bug; it appears to be new functionality.

Lower-prioritydocs: add release notes for KV-to-SQL payment migrationby ziggie · 89f046a1 · Feb 27, 2026 · 1 fileMessage 62 · AdequateInformational 15Details
Commit message · ziggie

docs: add release notes for KV-to-SQL payment migration

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 line to the release notes describing an internal database migration for payment records (moving from a key-value format to SQL). It does not change any code, configuration, or security behavior. There is no security issue in this commit itself.

Security candidatepayments/migration1: freeze lnwire and record dependencyby ziggie · 6c28cc4d · Feb 27, 2026 · 33 filesMessage 85 · StrongLow 28Details
Commit message · ziggie

payments/migration1: freeze lnwire and record dependency

Also freeze the lnwire and record packages used by the migration.

Copy the minimal subset of lnwire files (16) into
payments/db/migration1/lnwire/ and all record files (6) into
payments/db/migration1/record/. Three lnwire files are trimmed to avoid
pulling in the full message-type dispatch tree — all changes are purely
subtractive and can be verified with:

diff lnwire/message.go payments/db/migration1/lnwire/message.go
diff lnwire/writer.go payments/db/migration1/lnwire/writer.go
diff lnwire/lnwire.go payments/db/migration1/lnwire/lnwire.go

All migration1 files now import only the frozen packages, removing the
live dependency on lnwire and record so future changes to those packages
cannot affect migration correctness.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing or wallet pathboot or update path
AI analysis · Low 28/100

This commit is a defensive code-hygiene change. It copies a small, frozen snapshot of two shared code packages (lnwire and record) into an old database migration folder so that future updates to the live versions of those packages cannot accidentally change how past payment data is decoded. There is no direct vulnerability being fixed; instead, the change prevents a class of future migration-correctness bugs.

AI review queuedpayments/db: normalize LegacyPayload flag in migration comparisonby ziggie · 00025ef3 · Feb 26, 2026 · 2 filesMessage 83 · StrongInformational 18Details
Commit message · ziggie

payments/db: normalize LegacyPayload flag in migration comparison

LegacyPayload was a hint used exclusively by the KV store to decide
how to serialize and deserialize the hop payload (legacy format vs
TLV). The SQL store does not serialize hop data at all — every hop
field is persisted natively in its own column — so this flag has no
meaning there and is never stored.

Clear LegacyPayload for all hops inside normalizePaymentForCompare so
that deep-equality checks between KV and SQL payments succeed even when
the KV source data carries LegacyPayload=true.

A dedicated test (TestMigrationLegacyPayloadNormalized) is added to
verify that a payment with LegacyPayload=true hops migrates and
compares correctly.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 18/100

This commit fixes a test-only comparison helper used when validating that old payment data can be moved from LND's older key-value database to the newer SQL database. The 'LegacyPayload' flag only mattered to the old database format and is not stored in SQL. The change makes the comparison ignore that flag so migrations with legacy-format hops don't falsely fail validation. It is not a runtime security fix and does not change how user funds or payment data are handled in production.

Lower-prioritypayments/db: fix silent error in duplicate payment lookupby ziggie · 9def1243 · Feb 25, 2026 · 2 filesMessage 73 · AdequateLow 42Details
Commit message · ziggie

payments/db: fix silent error in duplicate payment lookup

When duplicatePaymentSequenceKey is missing from a duplicate payment
sub-bucket, the code returned the outer function's err variable which
is nil at that point. This caused corrupted duplicate entries to be
silently treated as "not found" instead of failing loudly.

Return a new dedicated ErrNoDuplicateSequenceNumber error so malformed
data is detected immediately.

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

This commit fixes a bug in LND's payment database where a missing piece of data inside a stored duplicate payment was silently treated as 'not found' instead of reporting an error. The fix makes the database return a clear, dedicated error so corrupted or malformed payment records are detected immediately rather than ignored.