LL
← All projectsLightning Labs

LND

Go implementation of a complete Lightning Network node.

BitcoinLightning NetworkNormal
Repository coverage

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

115security candidates164second-pass queue95AI analyses
70commits · 30 days
159commits · 60 days
824commits · 180 days
1229commits · 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.

66/100 average clarity
277Strong · 80–100
555Adequate · 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 Osuntokun1943935274
Elle Mouton2673126067
ziggie4081510064
Erick Cestari2677070
bitromortac4655067
yyforyongyu5532065
saubyk1520070
Oli722057
Suheb320075
elnosh322071
George Tsagkarelis3211066
Gijs van Dam2611071
Analysis record

Published AI watches

Last scanned 1 minute ago

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 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 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
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
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
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
Low 32 AI analysisMessage 88 · Strong
LL Lightning LabsLND BitcoinLightning Network

multi: upgrade to btcd v2 modules

This is a large dependency upgrade for the LND Lightning node software. It moves LND from older btcd Bitcoin library packages to new 'v2' packages and updates related wallet and network libraries. The commit is almost entirely mechanical i…

Large dependency upgrade touching core Bitcoin primitives (wire, txscript, chainhash, btcutil, psbt, address)Migration to new v2 module layout with API changes in address handlingPins new upstream releases (btcd 0.26.0, btcwallet 0.17.0, neutrino 0.18.0, lightning-onion 1.4.0) that may include undisclosed fixes
8047149cby Oli+1733−1789605 files
No security note in commit
Low 47 AI analysisMessage 85 · Strong
LL Lightning LabsLND BitcoinLightning Network

discovery: fix panic in DNS fallback SRV lookup

This commit fixes a bug in LND's DNS seed bootstrap code that could crash the node. The code assumed every record in a DNS response was an SRV record, so a non-SRV record (like a normal A or CNAME record) would cause a panic. The fix safel…

Unconditional type assertion panic in DNS fallback pathMissing bounds check on LookupHost result before array indexingMissing network deadline on manually dialed DNS TCP connection
2a3642c6by Erick Cestari+252−52 files
Vendor flagged security relevance
Informational 18 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

kvdb: remove stale xz replace

This commit removes a temporary security workaround in a Go module file. The workaround forced the use of a newer, fixed version of a compression library (xz) to avoid a known historical vulnerability. The commit message says the library i…

Removal of a dependency-level vulnerability workaroundReference to historical advisory GHSA-25xm-hr59-7c27 in deleted commentNo code changes; only go.mod cleanup
80f98a5eby ziggie+0−31 file
Vendor flagged security relevance
Informational 12 AI analysisMessage 88 · Strong
LL Lightning LabsLND BitcoinLightning Network

mod: remove stale xz replace

This commit removes an old workaround in LND's dependency file (go.mod) that pinned a safe version of the 'xz' compression library. The workaround was originally added because another dependency once pulled in a vulnerable version of xz. T…

Removal of a dependency override that was a security mitigation for CVE-2021-29482Commit explicitly references the original GHSA advisory (GHSA-25xm-hr59-7c27)No actual downgrade or re-introduction of the vulnerable module is visible in the diff
eeaa717eby ziggie+0−31 file
Vendor flagged security relevance
Informational 15 AI analysisMessage 83 · Strong
LL Lightning LabsLND BitcoinLightning Network

lint: remove redundant loop var copies in test files

This commit is a cleanup-only change that removes unnecessary loop-variable copies in Go test files. Since Go 1.22, loop variables are already scoped per-iteration, so the old `x := x` workarounds are redundant. The change affects only tes…

aca27e27by Erick Cestari+0−271137 files
No security note in commit
Informational 15 AI analysisMessage 68 · Adequate
LL Lightning LabsLND BitcoinLightning Network

mod: bump btcwallet to v0.16.18

This commit only changes a dependency version label in LND's package manifest. The underlying code (commit 70a94ea39e9c) stays exactly the same; the dependency is simply tagged as v0.16.18 instead of being referenced by a pseudo-version. T…

5b45ac81by yyforyongyu+3−32 files
No security note in commit
Low 32 AI analysisMessage 66 · Adequate
LL Lightning LabsLND BitcoinLightning Network

mod: bump kvdb to v1.5.1

This commit updates a dependency version in LND's build files. It bumps the internal 'kvdb' submodule from version 1.5.0 to 1.5.1 so that downstream projects importing kvdb directly do not pull in an older, vulnerable telemetry library (Op…

Dependency bump explicitly motivated by a known vulnerability identifier (GO-2026-4394)No source code changes in LND itself; only module metadata updatedVendor describes the root build as already unaffected, limiting direct security impact on LND
12686ac3by yyforyongyu+3−32 files
Vendor flagged security relevance
Low 34 AI analysisMessage 88 · Strong
LL Lightning LabsLND BitcoinLightning Network

multi: drop tor v2 onion production, keep wire codec faithful

This commit removes support for obsolete Tor v2 onion addresses from the Lightning Network Daemon (lnd). Tor v2 services were shut down by the Tor network in October 2021, so lnd will no longer create, accept, or dial v2 onion addresses. H…

Removal of deprecated network protocol (Tor v2) reduces attack surface and prevents futile/unsafe dials to unreachable services.Input validation added at operator boundaries (ParseAddressString, parseAddr) to reject v2 .onion addresses with a clear error.On-disk legacy key fallback now validates decrypted key type and rejects non-v3 (RSA1024) keys before passing them to Tor.
2ae1db83by Erick Cestari+780−32931 files
No security note in commit
Informational 12 AI analysisMessage 78 · Adequate
LL Lightning LabsLND BitcoinLightning Network

multi: update neutrino dep to include chainimport and header state fix

This commit simply updates a software library dependency (neutrino) used by the Lightning Network Daemon (LND). The new version is said to add a faster way to import blockchain headers and fix a bug that could stop peer-to-peer header sync…

Dependency update to a newer tagged release of neutrinoCommit message references a 'ResetHeaderState fix' for P2P sync continuation after chain importNo direct code-level security fix is visible in the supplied diff
88fff36eby Olaoluwa Osuntokun+4−43 files
No security note in commit
Low 43 AI analysisMessage 85 · Strong
LL Lightning LabsLND BitcoinLightning Network

lnwallet/rpcwallet: accept zero-value WitnessUtxo entries in remote-sign prep

This commit fixes a bug in LND's remote-signing setup where zero-value previous transaction outputs were wrongly ignored when preparing a PSBT for a remote signer. The most concrete affected use case is BIP-322 message attestation, where t…

Functional denial-of-service in remote-signer BIP-322 workflows due to PSBT rejectionIncorrect zero-value UTXO validation caused legitimate outputs to be droppedFix removes Value check while preserving non-empty PkScript sanity check
9f31668bby Olaoluwa Osuntokun+69−361 file
No security note in commit
Informational 15 AI analysisMessage 83 · Strong
LL Lightning LabsLND BitcoinLightning Network

lnwallet/rpcwallet: add unit tests for WitnessUtxo population helper

This commit only adds new unit tests for an existing helper function in LND's RPC wallet code. It does not change any production logic, so it cannot introduce a security vulnerability or directly fix one in the code being committed. The te…

6bb2c6f5by Olaoluwa Osuntokun+231−01 file
No security note in commit
Repository ledger

Explore captured commits

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

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

Security candidategraph/db: add v2 fields to ChannelEdgePolicy modelby Elle Mouton · 3fe40c65 · Feb 13, 2026 · 15 filesMessage 73 · AdequateTriage 12Details
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
Security candidatesqldb/sqlc: add IsPublicV2Node queryby Elle Mouton · a99604c7 · Feb 13, 2026 · 3 filesMessage 73 · AdequateInformational 3Details
Commit message · Elle Mouton

sqldb/sqlc: add IsPublicV2Node query

Add SQL query to determine if a node has public v2 channels. Unlike
v1 which requires all four individual signatures, v2 channels are
considered public when the single aggregated signature is present.

73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 3/100

This commit adds a new database query helper that checks whether a Lightning node has any 'version 2' public channels. It is purely additive and does not change any existing behavior or fix a known bug. There is no indication in the commit that this is a security patch.

Security candidategraph/db: add version parameter to IsPublicNodeby Elle Mouton · 971c0f6e · Feb 13, 2026 · 6 filesMessage 78 · AdequateInformational 24Details
Commit message · Elle Mouton

graph/db: add version parameter to IsPublicNode

Make IsPublicNode version-aware by routing to the appropriate SQL
query based on gossip version. V1 and v2 have different criteria for
determining node publicity (v1 requires four signatures, v2 requires
one). Convert TestNodeIsPublic to versioned test for both protocols.

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

This commit updates how LND decides whether a Lightning node is 'public' so that the decision respects the network's gossip protocol version. In the older v1 protocol, a node needed four signatures to be considered public; in the newer v2 protocol, one signature is enough. Previously the code always used the v1 rule, which could misclassify v2 nodes as private. The change is a correctness fix rather than an obvious remote-exploitable vulnerability, but misclassified publicity could affect routing, channel selection, or policy decisions.

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 candidatesqldb/sqlc: add AddV2ChannelProof queryby Elle Mouton · 315f5ed7 · Feb 13, 2026 · 3 filesMessage 73 · AdequateInformational 15Details
Commit message · Elle Mouton

sqldb/sqlc: add AddV2ChannelProof query

Add SQL query to update the signature column for v2 channel auth proofs.
Unlike v1 which requires four separate signatures, v2 channels use a
single aggregated signature.

73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 15/100

This commit adds a new database query to support v2 Lightning channel proofs. It simply updates a single signature column for v2 channels, whereas the older v1 proof format required four separate signatures. There is no security issue visible in the change itself.

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.

Security candidategraph/db: add version parameter to createEdge test helperby Elle Mouton · 6bb3bdc8 · Feb 13, 2026 · 1 fileMessage 88 · StrongInformational 15Details
Commit message · Elle Mouton

graph/db: add version parameter to createEdge test helper

Extend the createEdge test helper to accept a gossip version, enabling
creation of both v1 and v2 test channels. V2 channels include the
appropriate auth proof (single signature), merkle root hash, and
funding script fields.

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

This commit only changes test code. It extends a helper function used in unit tests so it can create both old-style (v1) and new-style (v2) fake Lightning channels for testing. No production code is modified, so it cannot directly affect real users or funds.

Security candidategraph/db: update SQLStore to read and write v2 channelsby Elle Mouton · fa24d336 · Feb 13, 2026 · 2 filesMessage 78 · AdequateLow 30Details
Commit message · Elle Mouton

graph/db: update SQLStore to read and write v2 channels

Extends the SQL store to support v2 (taproot) channel announcements:
- Add version validation in AddChannelEdge
- Store v2-specific fields: FundingPkScript, MerkleRootHash, Signature
- Update buildEdgeInfoWithBatchData to reconstruct v2 channels from DB
with optional bitcoin keys and funding script handling
- Add WithMerkleRootHash edge modifier for ChannelV2Fields

78/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Low 30/100

This commit extends LND's SQL graph database to store and retrieve a newer type of Lightning channel announcement (called 'v2' or 'taproot' channels). It adds support for new fields like funding scripts, Merkle root hashes, and a single signature, and it replaces hard-coded 'v1 only' checks with version-aware logic. There is no direct evidence in the commit that this fixes an active security bug; it reads as a feature-completion change to support a new protocol version.

Security candidatemulti: update models.ChannelAuthProof with v2 fieldby Elle Mouton · 7a260ee1 · Feb 13, 2026 · 11 filesMessage 78 · AdequateLow 32Details
Commit message · Elle Mouton

multi: update models.ChannelAuthProof with v2 field

Also update it to more closely match the persisted version which has the
v1 and v2 only fields as optional.

Refactor ChannelAuthProof to support both v1 and v2 channel
announcements:

- Add Version field to distinguish v1 from v2 proofs
- Wrap v1-specific fields (NodeSig1/2, BitcoinSig1/2) in fn.Option
since v2 doesn't use them
- Add optional Signature field for v2's single schnorr signature
- Add constructor functions NewV1ChannelAuthProof and
NewV2ChannelAuthProof to enforce correct initialization
- Add getter methods (NodeSig1(), BitcoinSig1(), etc.) that safely
unwrap options, returning empty slices when not present

The IsEmpty() check is updated to handle both versions correctly.
Both stores validate v1-only for now.

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 boundarydefensive validationauthentication path
AI analysis · Low 32/100

This commit refactors how Lightning Network channel authentication proofs are represented in the lnd codebase. It adds support for a future v2 channel announcement format (using a single Schnorr signature) while keeping v1 (four ECDSA signatures) as the only currently supported version. The change is structural and preparatory; it does not appear to fix an active security bug, nor does it introduce obvious new vulnerabilities. Both database stores explicitly reject v2 proofs for now.

Security candidatesqldb/sqlc: update graph CreateChannel query for v2by Elle Mouton · ec46480a · Feb 13, 2026 · 2 filesMessage 78 · AdequateInformational 15Details
Commit message · Elle Mouton

sqldb/sqlc: update graph CreateChannel query for v2

Add three new optional fields to the CreateChannel SQL query to
support v2 channel announcements:
- signature: single schnorr signature (replaces four ECDSA sigs)
- funding_pk_script: the funding output script
- merkle_root_hash: for taproot channels

These fields are NULL for v1 channels and populated for v2 channels.

78/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 15/100

This commit updates a database query used to store Lightning Network channel announcements. It adds three new optional fields needed for newer 'v2' channel types (a single Schnorr signature, the funding output script, and a Merkle root hash). For older 'v1' channels these fields are left empty/NULL. There is no security fix or vulnerability here; it is a straightforward schema/query update to support a new channel format.

Security candidategraph/db: remove unused sig field from ChannelEdgePolicyby Elle Mouton · 6fda2e8d · Feb 13, 2026 · 2 filesMessage 78 · AdequateInformational 15Details
Commit message · Elle Mouton

graph/db: remove unused sig field from ChannelEdgePolicy

Remove the cached parsed signature field and its lazy getter method
from ChannelEdgePolicy. This field was unused throughout the codebase
and the signature is already stored as raw bytes in SigBytes.

The SetSigBytes method is updated to remove the cache invalidation
logic.

78/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 15/100

This commit removes an unused internal cache field that stored a parsed cryptographic signature alongside the raw signature bytes. It is a straightforward code cleanup with no security-relevant behavior change: callers still access the raw signature bytes, and the only consumer is updated to set the field directly instead of through a helper method.

Security candidateactor: introduce generic Mailbox interface with iter.Seq supportby Olaoluwa Osuntokun · 30af2810 · Feb 10, 2026 · 1 fileMessage 78 · AdequateInformational 12Details
Commit message · Olaoluwa Osuntokun

actor: introduce generic Mailbox interface with iter.Seq support

This commit introduces a new Mailbox interface that abstracts the
message queue implementation for actors. Previously, actors used a
direct channel for their mailbox, which limited flexibility and made
it difficult to implement alternative mailbox strategies.

The new Mailbox interface provides methods for sending, receiving, and
draining messages, with full context support for cancellation. The
Receive method leverages Go 1.23's iter.Seq pattern, providing a clean
iterator-based API that allows natural for-range loops over messages.

The ChannelMailbox implementation maintains the existing channel-based
behavior while conforming to the new interface. It stores the actor's
context internally, ensuring both caller and actor contexts are
properly respected during send and receive operations. This simplifies
context handling compared to complex context merging approaches.

This abstraction enables future implementations such as priority
mailboxes, persistent mailboxes, or bounded mailboxes with overflow
strategies, without requiring changes to the actor implementation.

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
memory safety
AI analysis · Informational 12/100

This commit adds a new internal message-queue abstraction for LND's actor system. It is purely a refactoring/new-code change: it introduces a generic Mailbox interface and a channel-based implementation, with no existing callers shown and no obvious security bug. The code is defensive (uses mutexes and atomic flags to avoid send-on-closed-channel panics) and does not change any externally reachable behavior.

Security candidatebtcwallet: support combined tweak to private keyby George Tsagkarelis · 8125286d · Jan 30, 2026 · 1 fileMessage 73 · AdequateLow 28Details
Commit message · George Tsagkarelis

btcwallet: support combined tweak to private key

Previously we'd define either a single or a double tweak for the sign
descriptor. We introduce the option to apply both consecutively (double
tweak first, single tweak second) if both tweak parameters are set. For
callers who define only one of the two parameters we maintain the old
behavior.

73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
secret or key materialsigning or wallet path
AI analysis · Low 28/100

This commit adds a new option in LND's Bitcoin wallet signer that lets two different key tweaks be applied one after another to a private key, instead of only allowing one at a time. A tweak is a cryptographic adjustment used in Lightning for things like revocation keys and HTLC indexes. The change is additive and preserves old behavior when only one tweak is provided. There is no direct evidence in the commit that this fixes an active security vulnerability.

Security candidateworkflows/pr-severity: allow non-write users for classificationby Olaoluwa Osuntokun · a77b9d9b · Jan 29, 2026 · 1 fileMessage 85 · StrongTriage 0Details
Commit message · Olaoluwa Osuntokun

workflows/pr-severity: allow non-write users for classification

The PR severity classifier was failing for external contributors because
the claude-code-action checks that the actor has write permissions. Since
this workflow only reads PR metadata via the API and doesn't execute any
code from the PR (and has restricted tool permissions), it's safe to allow
any user to trigger classification.

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
credential or privilege statedocumentation-only discount
Security candidatediscovery: add panic recovery for serial announce signatures processingby Olaoluwa Osuntokun · bcb65f5a · Jan 13, 2026 · 1 fileMessage 73 · AdequateModerate 57Details
Commit message · Olaoluwa Osuntokun

discovery: add panic recovery for serial announce signatures processing

In this commit, we extend the panic recovery mechanism to cover the
serial processing path for AnnounceSignatures1 messages. Unlike other
gossip messages which are processed in parallel goroutines, announcement
signatures are processed serially in the main networkHandler loop.

A panic during this serial processing would previously crash the entire
gossiper. This change wraps the processing in an anonymous function with
a deferred panic recovery, ensuring resilience without changing the
serial processing semantics.

Since AnnounceSignatures bypass the validation barrier, we pass nil for
the jobID parameter.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundary
AI analysis · Moderate 57/100

This update adds a safety net around a specific message-handling path in LND's gossip subsystem. Previously, a crash while handling an AnnounceSignatures1 message could bring down the whole gossip component; now the code catches such crashes and keeps running. The change is defensive hardening rather than a fix for a known active attack.

Security candidateserver: remove accountability signal experiment periodby elnosh · 6f49bea5 · Jan 6, 2026 · 7 filesMessage 73 · AdequateInformational 21Details
Commit message · elnosh

server: remove accountability signal experiment period

In the previous iteration with endorsement
signaling, the recommendation was for the sender to
set it to 1 and that could have had privacy concerns
when first deploying given that the default was to
downgrade the signal to 0. In the latest proposal
the recommended default for both sending and
forwarding nodes is to set `accountable` to 0.
As a result, the dates have been removed given
that there are no privacy risks associated
with relaying the signal with zero values.

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

This commit removes a time-limited 'experiment period' for a new Lightning network signaling feature called 'accountable' (previously 'endorsement signal'). Previously, nodes would only relay this signal until a fixed date in 2026, after which they would stop. Now, because the latest protocol proposal says the default should be to send a zero/'unaccountable' value, there is no longer a privacy risk from relaying it, so the experiment end date is removed. The signal is now relayed whenever the feature is enabled, regardless of date. This is a protocol behavior change, not a fix for an exploitable security bug.

Security candidatemulti: rename experimental endorsement signal to accountableby elnosh · 34329c68 · Jan 6, 2026 · 21 filesMessage 73 · AdequateInformational 19Details
Commit message · elnosh

multi: rename experimental endorsement signal to accountable

Renames the endorsement signal to accountable to
match the latest proposal https://github.com/lightning/blips/pull/67

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Why it was queued
boot or update pathparser or protocol path
AI analysis · Informational 19/100

This commit is a pure rename of an experimental Lightning Network feature from 'endorsement' to 'accountable/accountability' to match a community proposal update. No security vulnerability is introduced or fixed; the underlying behavior, feature bits, TLV type, and experiment end date remain unchanged. It is a terminology and identifier refactor across 21 files.

Security candidatechanneldb: fix race condition in link node pruningby ziggie · 51f3c6f5 · Jan 6, 2026 · 1 fileMessage 100 · StrongModerate 68Details
Commit message · ziggie

channeldb: fix race condition in link node pruning

This commit fixes a critical race condition in MarkChanFullyClosed and
pruneLinkNode where link nodes could be incorrectly deleted despite
having pending or open channels.

The race occurred because the check for open channels and the link node
deletion happened in separate database transactions:

Thread A: TX1 checks open channels → [] (empty)
Thread A: TX1 commits
Thread B: Opens new channel with same peer
Thread A: TX2 deletes link node (using stale data)
Result: Link node deleted despite pending channel existing

This creates a TOCTOU (time-of-check to time-of-use) vulnerability where
database state changes between reading the channel count and deleting
the node.

Fix for MarkChanFullyClosed:
- Move link node deletion into the same transaction as the channel
closing check, making the check-and-delete operation atomic

Fix for pruneLinkNode:
- Add double-check within the write transaction to verify no channels
were opened since the caller's initial check
- Maintains performance by keeping early return for common case
- Prevents deletion if channels exist at delete time

This ensures the invariant: "link node exists iff channels exist"
is never violated, preventing database corruption and potential
connection 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
explicit security language
AI analysis · Moderate 68/100

This commit fixes a database race condition in LND (a Bitcoin Lightning Network implementation). When a channel closed, the software could incorrectly delete stored peer information ('link node') even though a new channel with that same peer had just been opened. The fix moves the 'check for open channels' and 'delete peer info' steps into the same database transaction, so they happen atomically and cannot be interrupted by another operation.

Security candidatedocs: add release notes for combined nonce RPC methodsby Elle Mouton · a7b61f3e · Dec 10, 2025 · 1 fileMessage 85 · StrongTriage 0Details
Commit message · Elle Mouton

docs: add release notes for combined nonce RPC methods

Document the new MuSig2RegisterCombinedNonce and MuSig2GetCombinedNonce RPC
methods in the v0.21.0 release notes. These methods enable coordinator-based
signing patterns as an alternative to the standard MuSig2RegisterNonces
workflow.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
signing boundarydocumentation-only discount
Security candidateitest+lntest: add coordinator pattern test for combined nonceby Elle Mouton · fb48697f · Dec 10, 2025 · 2 filesMessage 95 · StrongInformational 15Details
Commit message · Elle Mouton

itest+lntest: add coordinator pattern test for combined nonce

Add integration test for MuSig2RegisterCombinedNonce and
MuSig2GetCombinedNonce RPCs to verify the coordinator pattern workflow.

The test:
- Creates three signing sessions without initial nonce exchange
- Manually aggregates nonces using the coordinator pattern (btcec musig2)
- Tests v0.4.0 returns unsupported errors (as expected)
- Tests v1.0.0rc2 successfully registers and retrieves combined nonces
- Verifies mutual exclusivity (error: already have all nonces)
- Completes a full signing flow to ensure signatures are valid

Also adds the required RPC harness wrapper methods to lntest/rpc/signer.go for
the new RPCs and adds MuSig2RegisterNoncesErr wrapper for error testing.

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
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This commit only adds new integration tests and test helper wrappers for the MuSig2 'coordinator pattern' RPCs. It does not change any production code, wallet logic, or consensus behavior. There is no security vulnerability here.

Security candidatesignrpc: implement combined nonce RPC server handlersby Elle Mouton · 16b9192d · Dec 10, 2025 · 1 fileMessage 73 · AdequateInformational 21Details
Commit message · Elle Mouton

signrpc: implement combined nonce RPC server handlers

Add server-side RPC handlers for MuSig2RegisterCombinedNonce and
MuSig2GetCombinedNonce.

The handlers:
- Delegate to the Signer interface methods
- Validate input (session ID format, combined nonce length)
- Include macaroon permissions (generate for register, read for get)

These handlers complete the server-side RPC implementation.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
defensive validationcredential or privilege statesigning or wallet path
AI analysis · Informational 21/100

This commit adds two new server-side RPC handlers for an advanced multi-signature signing feature called MuSig2. The handlers let a caller register a pre-aggregated combined nonce and retrieve the combined nonce for a signing session. The code delegates to existing signer logic, checks the session ID format, validates the nonce length, and assigns macaroon permissions. There is no direct evidence in the commit of a security vulnerability; it appears to be a normal feature-completion change.

Security candidategraph/db: simplify auth proof and edge infoby Elle Mouton · edc021f7 · Nov 12, 2025 · 4 filesMessage 65 · AdequateTriage 10Details
Commit message · Elle Mouton

graph/db: simplify auth proof and edge info

Remove various unused fields and methods.

65/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Names security-relevant behavior explicitly
Why it was queued
authentication path
Security candidatemulti: freeze graph SQL migration logicby Elle Mouton · 125325f6 · Nov 12, 2025 · 17 filesMessage 68 · AdequateTriage 10Details
Commit message · Elle Mouton

multi: freeze graph SQL migration logic

Copy over all the code that the graph SQL migration needs to a
separate folder. This will let us advance the main graph SQL CRUD code
without worrying about changing the sql migration code. It will also let
us change the SQL queries without changing the migration. In this
commit, only the migration logic is "frozen" but in an upcoming commit,
the sqlc queries & models will be frozen too.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
authentication path
Security candidatemulti: remove HaveNodeAnnouncement field from Nodeby Elle Mouton · 8f205e2d · Nov 12, 2025 · 15 filesMessage 70 · AdequateLow 28Details
Commit message · Elle Mouton

multi: remove HaveNodeAnnouncement field from Node

Remove the 2 sources of truth here. If we have a signature for the
node, then we have the announcement.

70/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Low 28/100

This commit removes a redundant flag called HaveNodeAnnouncement from LND's internal node records and replaces it with a simple rule: if a node has a stored signature, it has an announcement. It is a code-quality/refactoring change that eliminates two conflicting ways of answering the same question. There is no direct evidence in the commit that this fixes an active security vulnerability, but inconsistent state can historically lead to subtle bugs in how node information is stored, forwarded, or validated.