LL
← All projectsLightning Labs

LND

Go implementation of a complete Lightning Network node.

BitcoinLightning NetworkNormal
Repository coverage

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

116security candidates168second-pass queue123AI analyses
76commits · 30 days
165commits · 60 days
830commits · 180 days
1235commits · 365 days
Backfill bands
Aug 5 → Feb 6405 seen5 candidatesComplete
Feb 6 → Jun 6665 seen28 candidatesComplete
Jun 6 → Jul 689 seen4 candidatesComplete
Jul 6 → Aug 569 seen0 candidatesComplete
Commit communication

Does the history explain itself?

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

67/100 average clarity
279Strong · 80–100
559Adequate · 60–79
366Thin · 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 Osuntokun1994040274
Elle Mouton2673133067
ziggie4081520064
Erick Cestari2677070
bitromortac4655067
yyforyongyu5533065
saubyk1522070
Oli722057
Suheb322075
elnosh322071
George Tsagkarelis3211066
Gijs van Dam2611071
Analysis record

Published AI watches

Last scanned 52 minutes ago

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

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

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

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

invoices: refine update handling

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

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

bolt12: add InvoiceError onion message replies

This commit adds support in LND for a new Lightning protocol message called InvoiceError. It is used to politely tell another node why their payment invoice or invoice request was rejected, sent privately through an onion-routed message. T…

New unsigned onion message type added with no cryptographic signature or bech32 formWriter-side validation prevents empty or non-UTF-8 error strings and disallowed suggested_value without erroneous_fieldReader-side BOLT 1 must-understand rule enforced: unknown even TLVs rejected, unknown odd TLVs tolerated
e279cdf1by bitromortac+567−04 files
No security note in commit
Low 36 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

bolt12: validate Invoice messages

This commit adds validation checks for BOLT 12 invoices in the LND Lightning node software. It ensures invoices contain required fields (creation time, amount, payment hash, node ID, payment paths), match their originating invoice requests…

New validation gate added to Invoice.Encode() to reject malformed invoices before serializationReader rejects unknown even invoice TLV types and unknown even feature bitsReader enforces chain compatibility against activeChain
e0f04f17by bitromortac+1642−74 files
No security note in commit
Informational 12 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

bolt12: add Invoice struct and TLV codec

This commit adds new code to support BOLT 12 invoices in the LND Lightning node. It introduces a data structure, encoding/decoding logic, and helper functions to filter fallback addresses and blinded payment paths. There is no bug fix or s…

efbeef58by bitromortac+777−02 files
No security note in commit
Informational 15 AI analysisMessage 80 · Strong
LL Lightning LabsLND BitcoinLightning Network

ci: split issue dedupe into find and post jobs

This commit is a hardening and refactoring change to a GitHub Actions workflow that detects duplicate issues. It splits the workflow into two jobs: one that only reads issue data and uses an AI model to find duplicates, and a second that o…

Principle of least privilege: AI/model job no longer holds issues:write or id-token:writeAction dependency pinned to full commit SHA instead of mutable tagpersist-credentials: false set on checkout steps
d1ea8687by Olaoluwa Osuntokun+148−71 file
No security note in commit
Informational 15 AI analysisMessage 85 · Strong
LL Lightning LabsLND BitcoinLightning Network

ci: split PR severity workflow into classify and apply jobs

This commit is a hardening and cleanup of a GitHub Actions workflow that automatically labels pull requests by severity. It does not change any LND node code, wallet logic, or network protocol. Instead, it splits the workflow into two jobs…

Principle of least privilege: write token moved out of the model-bearing jobUntrusted input (model-generated comment) sanitized before privileged API useExternal action pinned to immutable commit SHA instead of mutable tag
05c62527by Olaoluwa Osuntokun+424−593 files
Vendor flagged security relevance
Informational 21 AI analysisMessage 68 · Adequate
LL Lightning LabsLND BitcoinLightning Network

github: bump gateway code-review to v0.5.0

This commit updates a GitHub Actions workflow for an optional code-review bot called 'gateway' from version 0.4.4 to 0.5.0. It adds support for replying to inline review comments (not just regular PR comments) and pins the new action and r…

Workflow-only change with no modifications to LND application codeAction and runtime pinned to immutable commit SHAs (supply-chain mitigation)New pull_request_review_comment trigger added; commit message asserts same fork-PR secret safety as issue_comment
447703a4by saubyk+20−61 file
No security note in commit
Informational 15 AI analysisMessage 78 · Adequate
LL Lightning LabsLND BitcoinLightning Network

lnwallet: use channel state open channel

This commit is a straightforward internal code cleanup: it changes the lnwallet package to use the OpenChannel type from a dedicated chanstate package instead of getting it indirectly through the channeldb package. There is no change to us…

fa31c564by ziggie+59−469 files
No security note in commit
Informational 15 AI analysisMessage 68 · Adequate
LL Lightning LabsLND BitcoinLightning Network

funding: use channel state open channel

This commit is a straightforward internal code cleanup in LND's channel-opening machinery. It swaps one internal type name (channeldb.OpenChannel) for another (chanstate.OpenChannel) across function signatures in the funding manager and it…

03daaad4by ziggie+28−272 files
No security note in commit
Informational 15 AI analysisMessage 68 · Adequate
LL Lightning LabsLND BitcoinLightning Network

chanstate: use channel type in wallet rpc

This is a small internal code cleanup in LND's wallet RPC server. It changes one helper function to use a newer internal package type (chanstate.OpenChannel) instead of an older compatibility alias (channeldb.OpenChannel). There is no user…

8a215d9eby ziggie+3−21 file
No security note in commit
Low 46 AI analysisMessage 56 · Thin
LL Lightning LabsLND BitcoinLightning Network

chanstate: fix htlc copy

This commit fixes a bug in how the Lightning Network Daemon (LND) copies payment channel data. When the program made a copy of an HTLC (a pending payment in a Lightning channel), it failed to copy several important fields and did not prope…

Incomplete deep copy of security-relevant channel stateMissing fields in HTLC clone (RHash, OnionBlob, HtlcIndex, LogIndex)Nil-slice copy bug for Signature and ExtraData
b720fd5cby ziggie+88−42 files
No security note in commit
Informational 15 AI analysisMessage 58 · Thin
LL Lightning LabsLND BitcoinLightning Network

chanstate: remove store generics

This commit is a routine internal code cleanup in the LND Lightning node software. It removes temporary generic type parameters from channel-state database interfaces and replaces them with direct references to the concrete OpenChannel typ…

68ad283dby ziggie+88−8915 files
No security note in commit
Informational 18 AI analysisMessage 58 · Thin
LL Lightning LabsLND BitcoinLightning Network

channeldb: derive channel packagers

This commit is a code cleanup: it removes a forwarding-package helper object from the in-memory channel state and instead creates it on demand inside database methods. There is no direct security fix or vulnerability being patched. It main…

No security-relevant keywords in commit title or messageNo changes to cryptographic operations, authentication, or network parsingRefactoring only: field removal and localized object construction
0229e0adby ziggie+47−989 files
No security note in commit
Informational 15 AI analysisMessage 68 · Adequate
LL Lightning LabsLND BitcoinLightning Network

chanstate: make store channel types generic

This commit is a pure internal code reorganization. It moves several small channel-related data types (like channel configuration, status flags, close summaries, and helper types) from the channeldb package into a new chanstate package, th…

f53d615cby ziggie+473−36518 files
No security note in commit
Low 30 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

lnwallet+walletrpc: add SubmitPackage for v3 CPFP package relay

This commit adds a new RPC called SubmitPackage to LND's WalletKit. It lets users submit a group of related Bitcoin transactions together so a zero-fee parent can be accepted because a later child transaction pays its fee. This is a featur…

New RPC endpoint gated by onchain:write macaroon permissionPackage size bounded to 25 transactions to limit deserialization workFee-rate ceiling passed through to backend; explicit 0 disables limit
f55c0565by Elle Mouton+1019−21517 files
No security note in commit
Informational 15 AI analysisMessage 68 · Adequate
LL Lightning LabsLND BitcoinLightning Network

lncli: add wallet submitpackage command

This commit adds a new command-line tool called `lncli wallet submitpackage` that lets users hand one or more raw Bitcoin transactions to LND's wallet service so they can be submitted to the network as a group (a "package"). The change onl…

No security-relevant signals present in the diff or commit message.New CLI command is a thin wrapper around an existing RPC.No changes to validation, authentication, authorization, or network handling.
ea88a268by Elle Mouton+72−01 file
No security note in commit
Informational 15 AI analysisMessage 78 · Adequate
LL Lightning LabsLND BitcoinLightning Network

itest: add SubmitPackage integration test

This commit only adds a new integration test for an existing LND WalletKit RPC called SubmitPackage. It does not change production code, wallet logic, or network behavior. The test verifies that a zero-fee Bitcoin transaction can be accept…

47661ceaby Elle Mouton+226−03 files
No security note in commit
Low 49 AI analysisMessage 88 · Strong
LL Lightning LabsLND BitcoinLightning Network

bolt12: validate InvoiceRequest per BOLT 12 reader/writer requirements

This commit adds validation checks for BOLT 12 invoice requests in the LND Lightning node. It ensures that invoice requests follow protocol rules when being created (written) and received (read), rejecting malformed or non-compliant reques…

New input validation functions added for protocol messagesValidation now runs before encoding, preventing malformed outbound messagesOverflow guard added for amount*quantity calculation
8b4587b0by bitromortac+1703−53 files
No security note in commit
Informational 12 AI analysisMessage 78 · Adequate
LL Lightning LabsLND BitcoinLightning Network

bolt12: add InvoiceRequest message struct and TLV codec

This commit adds a new data structure and serialization code for BOLT 12 invoice requests in the LND Lightning node. It is purely an implementation of a protocol message format and includes a round-trip test. There is no indication in the …

6bb9c7e8by bitromortac+282−02 files
No security note in commit
Repository ledger

Explore captured commits

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

AI review queuedlnwallet: expose channel stateby bitromortac · 19860bb9 · Feb 20, 2026 · 2 filesMessage 58 · ThinTriage 12Details
Commit message · bitromortac

lnwallet: expose channel state

We create a deep copy of the channel state as we want to later expose
the data structure to the rpc, which already has helper methods to
marshal this representation to the rpc representation.

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI review queuedgraph/db: update policy builders to support v2 fieldsby Elle Mouton · 40e3ac96 · Feb 13, 2026 · 3 filesMessage 73 · AdequateTriage 0Details
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 review queuedmulti: add version to models.ChannelEdgeInfoby Elle Mouton · 4480352d · Feb 13, 2026 · 18 filesMessage 68 · AdequateTriage 8Details
Commit message · Elle Mouton

multi: add version to models.ChannelEdgeInfo

And set it to V1 version everywhere.

Add a Version field to ChannelEdgeInfo to distinguish between v1 and
v2 channel announcements. Set it to GossipVersion1 for all existing
channels.

Both KV and SQL stores now validate that only v1 channels are
currently supported, returning an error for v2 channels. The KV store
automatically sets version to v1 when deserializing (since all
persisted channels in KV format are v1).

This versioning is essential for handling the different field
requirements and validation logic between v1 and v2 channels.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
defensive validationsecond-pass: broader security terminology
AI review queueddevrpc: fix commentby Elle Mouton · 2e58c075 · Feb 13, 2026 · 1 fileMessage 28 · OpaqueTriage 0Details
Commit message · Elle Mouton

devrpc: fix comment

28/100 · OpaqueMessage clarity
✓ Subject identifies a change! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI review queueditest: add wallet_synced field integration testby Slyghtning · b8693bea · Feb 5, 2026 · 2 filesMessage 78 · AdequateTriage 12Details
Commit message · Slyghtning

itest: add wallet_synced field integration test

In this commit, we add an integration test that verifies the
wallet_synced field in GetInfoResponse correctly reflects the wallet's
sync state.

The test creates a node, verifies wallet_synced becomes true after
initial sync, then stops the node and mines blocks while it's offline.
After restart, the test polls GetInfo to observe the wallet catching up,
ideally capturing the transition from wallet_synced=false to true.

The test is registered in the "wallet sync" test case group.

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 review queuedlncli unlock: wait until daemon can unlockby Boris Nagaev · e865552c · Feb 4, 2026 · 1 fileMessage 76 · AdequateTriage 12Details
Commit message · Boris Nagaev

lncli unlock: wait until daemon can unlock

Use the StateService stream to wait for LOCKED before sending the unlock
request, then wait for UNLOCKED/RPC_ACTIVE before reporting success.
If the state shows the wallet is already unlocked, skip sending the
unlock request and return an error immediately.

This avoids lost unlocks during slow startup.
Fix https://github.com/lightningnetwork/lnd/issues/7749

76/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI review queuedlncli unlock: add unit testsby Boris Nagaev · 6cd785c7 · Feb 4, 2026 · 2 filesMessage 70 · AdequateTriage 12Details
Commit message · Boris Nagaev

lncli unlock: add unit tests

Add table-driven unit tests for unlock() that exercise success and error paths,
cover flag and arg handling.

70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI review queuedgraphdb: fix backwards-compat for channel edge feature deserializationby Olaoluwa Osuntokun · 56a7f45b · Feb 3, 2026 · 3 filesMessage 93 · StrongTriage 0Details
Commit message · Olaoluwa Osuntokun

graphdb: fix backwards-compat for channel edge feature deserialization

This commit fixes a backwards compatibility issue that prevented nodes
from upgrading from v0.19.x to v0.20.x.

In v0.19.x, channel edge features were serialized as raw feature bytes
without a length prefix. In v0.20.x (commit 2f2845dfc), the serialization
changed to use Features.Encode() which adds a 2-byte big-endian length
prefix before the feature bits. The deserialization code was updated to
use Features.Decode() which expects this length prefix.

When v0.20.x reads a database created by v0.19.x, Decode() tries to read
a length prefix that doesn't exist, causing an EOF error:

unable to decode features: EOF

The fix adds a deserializeChanEdgeFeatures() helper that detects which
format is being read and decodes accordingly:

- New format (v0.20+): First 2 bytes encode the length of the remaining
bytes. Detected when uint16(bytes[0:2]) == len(bytes)-2.

- Legacy format (pre-v0.20): Raw feature bits without length prefix.
Uses DecodeBase256 with the known length.

The format detection is safe because in the legacy format, the first byte
always has at least one bit set (the serialization uses minimum bytes),
so the first two bytes can never encode a value equal to len-2.

Fixes #10528.

93/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
Why it was queued
second-pass: broader security terminology
AI review queuedbtcwallet: add test coverage for maybeTweakPrivKeyby George Tsagkarelis · e532d4e4 · Jan 30, 2026 · 1 fileMessage 60 · AdequateTriage 12Details
Commit message · George Tsagkarelis

btcwallet: add test coverage for maybeTweakPrivKey

60/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI review queued"Claude PR Assistant workflow"by Olaoluwa Osuntokun · c0004781 · Jan 27, 2026 · 1 fileMessage 35 · OpaqueTriage 0Details
Commit message · Olaoluwa Osuntokun

"Claude PR Assistant workflow"

35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body
Why it was queued
documentation-only discountsecond-pass: opaque commit message
AI review queuedlnwallet: define helper func to coop close conf scalingby Olaoluwa Osuntokun · 09c813a6 · Jan 16, 2026 · 2 filesMessage 65 · AdequateTriage 12Details
Commit message · Olaoluwa Osuntokun

lnwallet: define helper func to coop close conf scaling

We have two versions: for itests, we just use one conf, but in prod,
we'll scale the number of confirmations.

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI review queuedlnwallet: add tests for new conf scaling helper funcsby Olaoluwa Osuntokun · 4f43717d · Jan 16, 2026 · 1 fileMessage 60 · AdequateTriage 12Details
Commit message · Olaoluwa Osuntokun

lnwallet: add tests for new conf scaling helper funcs

60/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI review queuedcontractcourt: add sync dispatch fast-path for single confirmation closesby Olaoluwa Osuntokun · ebefe63f · Jan 16, 2026 · 2 filesMessage 95 · StrongTriage 0Details
Commit message · Olaoluwa Osuntokun

contractcourt: add sync dispatch fast-path for single confirmation closes

In this commit, we add a fast-path optimization to the chain watcher's
closeObserver that immediately dispatches close events when only a single
confirmation is required (numConfs == 1). This addresses a timing issue
with integration tests that were designed around the old synchronous
blockbeat behavior, where close events were dispatched immediately upon
spend detection.

The recent async confirmation architecture (introduced in commit f6f716ab7)
properly handles reorgs by waiting for N confirmations before dispatching
close events. However, this created a race condition in integration tests
that mine blocks synchronously and expect immediate close notifications.
With the build tag setting numConfs to 1 for itests, the async confirmation
notification could arrive after the test already started waiting for the
close event, causing timeouts.

We introduce a new handleSpendDispatch method that checks if numConfs == 1
and, if so, immediately calls handleCommitSpend to dispatch the close event
synchronously, then returns true to skip the async state machine. This
preserves the old behavior for integration tests while maintaining the full
async reorg protection for production (where numConfs >= 3).

The implementation adds the fast-path check in both spend detection paths
(blockbeat and spend notification) to ensure consistent behavior regardless
of which detects the spend first. We also update the affected unit tests to
remove their expectation of confirmation registration, since the fast-path
bypasses that step entirely.

This approach optimizes for the integration test scenario without compromising
production safety, as the fast-path only activates when a single confirmation
is sufficient - a configuration that only exists in the controlled test
environment.

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 review queuedlnwallet: add new helper functions to scale confirmations based on amtby Olaoluwa Osuntokun · 9e749161 · Jan 16, 2026 · 1 fileMessage 50 · ThinTriage 12Details
Commit message · Olaoluwa Osuntokun

lnwallet: add new helper functions to scale confirmations based on amt

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI review queuedlncfg: add deprecated no-experimental-endorsement config optionby ziggie · 04dab619 · Jan 14, 2026 · 3 filesMessage 73 · AdequateTriage 7Details
Commit message · ziggie

lncfg: add deprecated no-experimental-endorsement config option

Re-adds the old no-experimental-endorsement config option as a hidden,
deprecated alias for no-experimental-accountability. This ensures
backward compatibility for users who have the old option in their
config files after the rename it.

73/100 · AdequateMessage clarity
✓ Specific, 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 review queueddiscovery: add panic recovery for gossip message processingby Olaoluwa Osuntokun · caf4850f · Jan 13, 2026 · 2 filesMessage 73 · AdequateTriage 0Details
Commit message · Olaoluwa Osuntokun

discovery: add panic recovery for gossip message processing

In this commit, we add a centralized panic recovery mechanism for gossip
goroutines. This increases the robustness of message processing in the
gossiper, as now we are able to keep on trucking in the face of logic
errors that may lead to panics.

We ensure that any deps are freed and we log the panic trace to help
catch bugs in the future.

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 review queuedcmd: make types.go accessible in lnd packageby Slyghtning · e5456d39 · Jan 7, 2026 · 5 filesMessage 45 · ThinTriage 12Details
Commit message · Slyghtning

cmd: make types.go accessible in lnd package

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI review queueditest: accept NO_ROUTE or TIMEOUT in testLocalClaimOutgoingHTLCby ziggie · c493f7d9 · Dec 18, 2025 · 2 filesMessage 95 · StrongTriage 0Details
Commit message · ziggie

itest: accept NO_ROUTE or TIMEOUT in testLocalClaimOutgoingHTLC

Fix flaky test due to race between channel closure propagation and
payment timeout. Both failure reasons are correct depending on timing.

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 review queuedchancloser: stabilize remote RBF coop testsby Boris Nagaev · d47d86ce · Dec 14, 2025 · 1 fileMessage 98 · StrongTriage 12Details
Commit message · Boris Nagaev

chancloser: stabilize remote RBF coop tests

CI started panicking in TestRbfChannelFlushingTransitions/early_offer /
TestRbfCloseClosingNegotiationRemote (see GitHub Actions run
https://github.com/lightningnetwork/lnd/actions/runs/19155841408/job/54756127218?pr=10352)
because the cached remote offer could fire before the test harness
registered its mock CloseSigner expectations. When that happened,
the mock complained that CreateCloseProposal was unexpected:

panic:
assert: mock: I don't know what to return because the method call was unexpected.

Fix this by having assertSingleRemoteRbfIteration take a sendEvent callback
that receives the context and initial offer, so tests can install expectations
first and then fire the event via SendEvent (or the early-offer test's custom
flush sender).

Reproduction (on master)
------------------------
1. Modify lnwallet/chancloser/rbf_coop_test.go
Add time.Sleep(10 * time.Millisecond) before the first call of
closeHarness.assertSingleRemoteRbfIteration (in function
TestRbfChannelFlushingTransitions).

2. go test ./lnwallet/chancloser -run TestRbfChannelFlushingTransitions/early_offer

3. The panic reproduces immediately.

98/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathsecond-pass: broader security terminologysecond-pass: security-sensitive path
AI review queuedfunding: fix race in itest for zero-conf fundingby ziggie · fe9a3e10 · Dec 10, 2025 · 2 filesMessage 90 · StrongTriage 0Details
Commit message · ziggie

funding: fix race in itest for zero-conf funding

Fix a race condition where forwarding through a public zero-conf channel
could fail with UnknownNextPeer when using the confirmed SCID. The issue
occurred because ReportShortChanID (which updates the switch's baseIndex
to handle the confirmed SCID) was called AFTER addToGraph (which announces
the confirmed SCID to the network).

With slow backends like postgres, addToGraph takes significant time,
creating a window where other nodes learn about the confirmed SCID from
gossip and attempt to route through it, but the receiving node's switch
hasn't been updated yet to handle forwards using the confirmed SCID.

The fix reorders operations to call ReportShortChanID before addToGraph,
ensuring the switch is ready to handle the confirmed SCID before it's
announced to the network. Forwards using either the alias or confirmed
SCID will work since getLinkByMapping uses baseIndex to map both to the
same link in forwardingIndex.

Fixes flaky test: zero_conf-channel_policy_update_public_zero_conf

90/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
second-pass: broader security terminology
AI review queuedinput+signrpc+lnwallet+multi: implement combined nonce supportby Elle Mouton · c945f674 · Dec 10, 2025 · 15 filesMessage 73 · AdequateTriage 12Details
Commit message · Elle Mouton

input+signrpc+lnwallet+multi: implement combined nonce support

Add CombinedNonce() and RegisterCombinedNonce() methods with full implementation
stack.

Interface and core implementation:
- input/musig2.go: Added methods to MuSig2Session and MuSig2Signer interfaces
- input/musig2_session_manager.go: MusigSessionManager implementation using
HaveAllNonces flag for state tracking (simplified, no extra fields)
- internal/musig2v040: Stub implementations returning ErrUnsupportedMethod
- Mock implementations (MockInputSigner, MockSigner, DummySigner)

RPC layer:
- lnrpc/signrpc/signer.proto: RPC method definitions and messages
- lnrpc/signrpc/signer.yaml: REST API endpoint mappings
- Generated protobuf code (all .pb.go files)
- lnwallet/rpcwallet/rpcwallet.go: RPCKeyRing client implementation

The proto types and RPCKeyRing are added together since RPCKeyRing implements
the Signer interface and requires proto types to fulfill the contract.

For v0.4.0, these methods return ErrUnsupportedMethod. Use MuSig2Version100RC2
to access these features.

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: broader security terminologysecond-pass: security-sensitive path
AI review queuedgo.mod: update btcec depby Elle Mouton · cbcb6a4d · Dec 10, 2025 · 2 filesMessage 61 · AdequateTriage 0Details
Commit message · Elle Mouton

go.mod: update btcec dep

To include the update to the musig2 Session which allows the aggregate
nonce for the session to be registered instead of requiring the
individual nonces to be registered.

61/100 · AdequateMessage clarity
✓ Subject identifies a change✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
second-pass: broader security terminology
AI review queueddocs: add release notes for race condition fixesby Elle Mouton · e68bf6c5 · Dec 8, 2025 · 1 fileMessage 57 · ThinTriage 0Details
Commit message · Elle Mouton

docs: add release notes for race condition fixes

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 discountsecond-pass: broader security terminology
AI review queuedgraph/db/models: fix race conditions in ChannelEdgeInfoby Elle Mouton · 31b3e742 · Dec 8, 2025 · 1 fileMessage 73 · AdequateTriage 0Details
Commit message · Elle Mouton

graph/db/models: fix race conditions in ChannelEdgeInfo

Both NodeKey1 and NodeKey2 methods had the same race condition as the
Node.PubKey method, where concurrent calls could race to write to the
cached fields.

Remove the caching for the same reasons: parsing overhead is minimal
and doesn't justify the complexity and race risk.

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 review queuedgraph/db/models: fix race condition in Node.PubKeyby Elle Mouton · 9906e617 · Dec 8, 2025 · 1 fileMessage 73 · AdequateTriage 0Details
Commit message · Elle Mouton

graph/db/models: fix race condition in Node.PubKey

The PubKey method had a race condition where concurrent calls could
all pass the nil check and race to write to the cached pubKey field.
This is a classic check-then-act race.

Remove the caching entirely to fix the race. The overhead of parsing
a public key is minimal and doesn't justify the added complexity and
race risk of caching.

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