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 queue55AI 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 Osuntokun1943926274
Elle Mouton2673110067
ziggie408155064
Erick Cestari2677070
bitromortac4652067
yyforyongyu5531065
saubyk1520070
Oli722057
Suheb320075
elnosh320071
George Tsagkarelis3211066
Gijs van Dam2610071
Analysis record

Published AI watches

Last scanned 43 minutes ago

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 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
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
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
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
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
Informational 15 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

lnrpc: remove deprecated Send* RPC server implementations

This commit removes old, unused code paths for sending Lightning payments through the main RPC server. These RPCs (SendPayment, SendPaymentSync, SendToRoute, SendToRouteSync) were already deleted from the service definition in a prior chan…

Removal of deprecated RPC handlers and macaroon permissionsDeletion of dead payment-dispatch helper codeNo new input parsing, network exposure, or privilege changes introduced
3ff87913by Erick Cestari+0−7891 file
No security note in commit
Low 37 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

routerrpc: remove deprecated SendPayment, SendToRoute, TrackPayment impls

This commit removes three old, deprecated payment RPC methods (SendPayment, SendToRoute, and TrackPayment) from the LND Lightning node's router service. These methods were already replaced by newer V2 versions and were only thin wrappers a…

Removal of deprecated RPC surface reduces attack surfaceMacaroon permission entries for removed methods are deletedNo new code paths or logic added
c7dd0a99by Erick Cestari+0−1262 files
No security note in commit
High 76 AI analysisMessage 95 · Strong
LL Lightning LabsLND BitcoinLightning Network

peer: gate onion message ingress on having an open channel

This change closes a denial-of-service weakness in LND's onion-message forwarding. Previously, an attacker could create unlimited free peer identities and burn through the global byte-budget reserved for onion messages, starving real peers…

Adds a Sybil-resistance gate requiring funded, non-pending channels for onion message ingressChannel gate runs before per-peer and global rate limiters, preventing no-channel peers from consuming any token budgetIntroduces atomic shadow counter for O(1) hot-path checks on every incoming onion packet
c0827e8eby Olaoluwa Osuntokun+336−539 files
Vendor flagged security relevance
Informational 12 AI analysisMessage 83 · Strong
LL Lightning LabsLND BitcoinLightning Network

lnwallet: regenerate taproot test vectors with secret nonces

This commit only updates test data in a JSON file used for automated tests of Lightning's new taproot channel features. It adds secret nonce values and corrects public nonce values so the test vectors match the expected commitment transact…

No production code modifiedTest-only JSON fixture updateNonce values are part of test vectors, not live secrets
50981dfcby Olaoluwa Osuntokun+9−31 file
No security note in commit
Informational 19 AI analysisMessage 88 · Strong
LL Lightning LabsLND BitcoinLightning Network

multi: add custom nonce rand support to MuSig2 sessions

This change adds a hidden switch that lets developers plug in a custom random source when creating MuSig2 signing nonces, mainly so tests can produce exactly the same signatures every time. In normal operation the switch is left empty, so …

New optional custom random source for MuSig2 nonce generationDefault call sites explicitly pass empty option, preserving CSPRNG behaviorCode comments state the option is intended only for reproducible test vectors
08c42b19by Olaoluwa Osuntokun+44−193 files
No security note in commit
Informational 15 AI analysisMessage 83 · Strong
LL Lightning LabsLND BitcoinLightning Network

lnwallet: add taproot channel test vector generator

This commit only adds new test code and a JSON file of expected test outputs for Taproot Lightning channels. It does not change any production logic, network behavior, or wallet handling. There is no security issue in the commit itself.

38c415a9by Olaoluwa Osuntokun+1570−02 files
No security note in commit
Informational 12 AI analysisMessage 88 · Strong
LL Lightning LabsLND BitcoinLightning Network

lnwallet: add 3rd-party signature verification for taproot test vectors

This commit only adds a new test to the project's test suite. It does not change any production code, user-facing behavior, or network protocol. The new test cryptographically checks that example transactions in the project's test data car…

Adds independent cryptographic signature verification for test vectorsUses txscript.NewEngine with StandardVerifyFlags to mirror on-chain validationVerifies both the commitment transaction and each HTLC resolution transaction
77da917cby Olaoluwa Osuntokun+99−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 candidatelnwallet: regenerate taproot test vectors with secret noncesby Olaoluwa Osuntokun · 50981dfc · Apr 13, 2026 · 1 fileMessage 83 · StrongInformational 12Details
Commit message · Olaoluwa Osuntokun

lnwallet: regenerate taproot test vectors with secret nonces

Regenerate the test vectors JSON to include local_sec_nonce and
remote_sec_nonce fields alongside the existing public nonces. The local
nonce fields now correctly correspond to local's verification nonce for
their own commitment transaction, matching the commitment tx stored in
the test vector.

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
defensive validationfuzzing or regression evidencenonce handlingsigning or wallet path
AI analysis · Informational 12/100

This commit only updates test data in a JSON file used for automated tests of Lightning's new taproot channel features. It adds secret nonce values and corrects public nonce values so the test vectors match the expected commitment transactions. There is no change to production wallet or network code, so it does not introduce a security vulnerability or fix one in running software.

Security candidatelnwallet: fix HTLC sig-to-transaction mapping in test vector generatorby Olaoluwa Osuntokun · b78de44d · Apr 13, 2026 · 1 fileMessage 100 · StrongInformational 24Details
Commit message · Olaoluwa Osuntokun

lnwallet: fix HTLC sig-to-transaction mapping in test vector generator

In this commit, we fix two interrelated bugs in the way HTLC signatures
are associated with their corresponding second-level transactions in the
taproot test vector generator.

The first issue was that HtlcSigs are sorted by BIP 69 output index
(matching the commitment transaction's output ordering), but the old
code was assigning signatures using the iteration order of incoming
HTLCs followed by outgoing HTLCs. This meant timeout transaction
signatures were getting paired with success transactions and vice versa
whenever the output ordering didn't happen to match the incoming-first
iteration order. This is the root cause of the invalid HTLC-timeout
signatures that eclair reported when cross-validating.

We now collect all HTLC entries (both incoming and outgoing) into a
single slice, sort them by their commitment output index, then zip them
against the HtlcSigs array so each signature lines up with the correct
second-level transaction.

The second issue was in the HTLC-success preimage extraction path. The
old code read the witness script from index [4] (the control block) and
used a hardcoded byte offset of 69 to locate the payment hash, then
wrote the preimage into index [3] (overwriting the script). The correct
taproot witness layout is [remoteSig, localSig, preimage, script,
controlBlock], so the script lives at [3] and the preimage slot is [2].
We now use `txscript.ScriptTokenizer` to walk the script opcodes and
find OP_HASH160 followed by the 20-byte push data, which is far more
robust than relying on fragile byte offsets that break if the script
template ever changes.

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 evidencesigning or wallet path
AI analysis · Informational 24/100

This commit fixes bugs in a test-data generator used by LND, not in the live Lightning node software itself. The generator produces sample HTLC (multi-hop payment) resolution transactions and signatures that other implementations use to cross-check compatibility. The old code paired signatures with the wrong transactions when HTLC outputs were not ordered 'incoming first,' and it also read preimages from the wrong witness slot using a hardcoded byte offset. These bugs caused invalid test vectors, which another implementation (Eclair) noticed during cross-validation. The fix only changes test code, so it does not create or close a real attack path against running LND nodes.

Security candidategraph/db: convert TestLightningNodeSigVerification to versioned testby Elle Mouton · a9c9e765 · Apr 7, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Elle Mouton

graph/db: convert TestLightningNodeSigVerification to versioned test

Rename to testLightningNodeSigVerification and add it to the
versionedTests table so it runs against both v1 and v2. The signing
step is version-specific (ECDSA for v1, Schnorr for v2) while the
verification path is shared.

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

This commit only changes a test file. It renames an existing test and makes it run against two versions of the software's gossip protocol, adding Schnorr signature coverage for the newer version. There is no change to production code, so it does not introduce or fix a security vulnerability in the running software.

Security candidatelnwire: validate MuSig2 nonces in LocalNoncesData decodeby Erick Cestari · 05f04f74 · Mar 31, 2026 · 2 filesMessage 65 · AdequateModerate 59Details
Commit message · Erick Cestari

lnwire: validate MuSig2 nonces in LocalNoncesData decode

Validate each nonce in decodeLocalNoncesData with
ValidateMusig2Nonce to reject malformed entries.

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
defensive validationnonce handling
AI analysis · Moderate 59/100

This change adds a safety check when LND reads stored MuSig2 cryptographic nonces from disk or network data. Previously, a malformed or all-zero nonce could be loaded silently; now the decoder rejects it. MuSig2 nonces are used in multi-signature Bitcoin transactions for the Lightning Network, so bad nonces could in theory lead to failed channel operations or, in worst-case cryptographic scenarios, weaken security guarantees.

Security candidatelnwallet/chancloser: fix local session nonce rotation bugby Olaoluwa Osuntokun · ca60f9c3 · Mar 27, 2026 · 2 filesMessage 65 · AdequateModerate 59Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: fix local session nonce rotation bug

We weren't properly using the latest closee nonce from the remote party
when signing.

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Moderate 59/100

This commit fixes a bug in LND's cooperative channel-closing code for Taproot (MuSig2) channels. The wrong order of operations meant the wallet sometimes tried to create a closing signature before it had loaded the remote party's latest nonce, which could cause the cooperative close to fail with a 'final signature is invalid' error. The patch reorders the steps so the nonce is loaded first, and renames a helper function to make clear which nonce it is handling. A new test was added to enforce the correct order.

Security candidatemulti: wire taproot RBF support throughout the stackby Olaoluwa Osuntokun · 85adad75 · Mar 27, 2026 · 2 filesMessage 73 · AdequateLow 34Details
Commit message · Olaoluwa Osuntokun

multi: wire taproot RBF support throughout the stack

In this commit we, integrate the taproot RBF cooperative close
functionality throughout the LND stack. This includes updating
protocol configuration and peer connection handling to support
the new taproot closing flow.

The changes wire through the taproot channel detection, nonce
exchange during shutdown, and proper handling of the enhanced
wire protocol messages in the peer layer. This completes the
integration of taproot RBF cooperative close functionality,
providing a complete alternate closing path for taproot channels
that leverages MuSig2 signatures and implements proper nonce
rotation for secure RBF scenarios.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundaryparser or protocol path
AI analysis · Low 34/100

This commit enables a new, more flexible way for taproot Lightning channels to close cooperatively. Previously, taproot channels had to fall back to an older close path even when the new RBF-based cooperative close feature was enabled. The change removes that restriction and adds the necessary nonce-exchange logic so taproot channels can use the modern close flow. It is a feature-completion patch rather than a clear-cut security fix, but because it touches cryptographic state setup for channel closing, it could affect safety if the new path has latent bugs.

Security candidatelnwallet/chancloser: address lint and PR review feedbackby Olaoluwa Osuntokun · d9284abe · Mar 27, 2026 · 7 filesMessage 85 · StrongInformational 17Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: address lint and PR review feedback

Fix all lint issues across the taproot RBF coop close changes:

- Fix line length violations (ll) by wrapping long lines and adding
nolint:ll where wrapping would hurt readability.
- Fix nlreturn: add blank lines before return statements.
- Fix misspell: correct "siganture" typos.
- Fix forcetypeassert: add checked type assertions.
- Fix nonamedreturns: remove named returns from function signatures.
- Fix usetesting: replace context.Background() with t.Context().
- Fix unused: remove unused remoteSchnorrSig variable.
- Fix whitespace: add newlines after multi-line func signatures.
- Fix gocritic appendAssign warning.
- Fix gci: correct import ordering.

Also address PR review comments from @erickcestari:

- Remove nonce cache in ClosingNonce() to prevent future footguns.
- Rename extractSigAndNonce to extractSigAndNonceFromClosingSig.
- Rename extractSigAndNonceFromComplete to
extractSigAndNonceFromClosingComplete with channel type validation.
- Replace env.RemoteMusigSession \!= nil with env.IsTaproot().
- Swap manual mocks to mock.Mock in musig_nonce_order_test.go.

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

This commit is a follow-up cleanup patch for a larger feature adding RBF (Replace-By-Fee) cooperative channel closes for Taproot channels in LND. It contains no direct security fixes. The changes are almost entirely code-style fixes (line length, blank lines, spelling, import ordering), test-only refactors, and minor defensive tweaks such as adding checked type assertions and removing a nonce cache that could be a 'footgun' in the future. The one substantive behavior change—removing the nonce cache—is described by the author as preventing future mistakes rather than fixing an active vulnerability.

Security candidatelnwallet/chancloser: fix MuSig2 nonce reuse across RBF roundsby Olaoluwa Osuntokun · f4fff172 · Mar 27, 2026 · 9 filesMessage 78 · AdequateHigh 82Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: fix MuSig2 nonce reuse across RBF rounds

MusigChanCloser.ClosingNonce() cached the local nonce and returned
the same one on subsequent calls. Since each RBF round creates a new
MuSig2 session via ProposalClosingOpts() but passes the same SecNonce,
the btcd library's per-session nonce reuse guard was bypassed (fresh
Session each round). Signing different closing transactions (different
fees/sighashes) with the same secret nonce enables private key
extraction via simple linear algebra on the partial signatures.

Fix by adding ClearNonce() to the MusigSession interface and calling
it after each signing round completes, forcing fresh nonce generation
on every RBF iteration. Also fix a rebase issue where
updateAndValidateCloseTerms was not extracting NextCloseeNonce from
ClosingSig messages for subsequent RBF rounds.

lnwallet/chancloser: fix MuSig2 nonce reuse across RBF rounds

MusigChanCloser.ClosingNonce() cached the secret nonce and returned
the same one across RBF rounds. Since each round creates a new
MuSig2 session via ProposalClosingOpts() but passes the same
SecNonce, signing different closing transactions with different
sighashes enables private key extraction.

Fix this by:

1. Storing the full MusigPartialSig from LocalCloseStart in the
LocalOfferSent state, eliminating the second CreateCloseProposal
call in prepareClosingSignatures. This was also flagged in PR
review as wasteful.

2. Adding InvalidateNonce() to the MusigSession interface. After
the closer round completes (CompleteCooperativeClose), the closer
nonce is invalidated so the next RBF round generates fresh. For
the closee, the nonce is invalidated before generating the next
closee nonce in createClosingSigMessage.

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
secret or key materialsigning boundarydefensive validationnonce handlingsigning or wallet path
AI analysis · High 82/100

This patch fixes a critical cryptographic bug in LND's taproot cooperative channel close feature. During RBF (fee-bump) rounds, the same secret random number (nonce) was being reused to sign different closing transactions. In MuSig2/taproot signing, reusing a secret nonce with different messages lets an attacker who sees the partial signatures recover your private key. The fix forces a fresh nonce for every RBF round and also stores the partial signature so it isn't regenerated (which would also reuse the nonce).

Security candidatelnwallet/chancloser: move nonce rotation to LocalOfferSentby Olaoluwa Osuntokun · d7302cfc · Mar 27, 2026 · 2 filesMessage 88 · StrongInformational 12Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: move nonce rotation to LocalOfferSent

Move the RemoteCloseeNonce update from updateAndValidateCloseTerms to
LocalOfferSent.ProcessEvent. This keeps updateAndValidateCloseTerms
focused on close term validation, and makes the nonce rotation point
explicit in the state machine — it happens when processing the
LocalSigReceived event, alongside signature extraction.

Update TestNextCloseeNonceStorageFromClosingSig to verify that
updateAndValidateCloseTerms no longer modifies RemoteCloseeNonce.

88/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarydefensive validationsigning or wallet path
AI analysis · Informational 12/100

This is a small internal code cleanup in LND's cooperative channel-closing logic. It moves where a cryptographic nonce is updated from one function to another within the same state machine, with no indication of a security bug or user-facing behavior change. The change is framed by the author as improving code organization, not fixing a vulnerability.

Security candidatemulti: fix nonce handling bugby Olaoluwa Osuntokun · 34a86ca8 · Mar 27, 2026 · 3 filesMessage 95 · StrongModerate 59Details
Commit message · Olaoluwa Osuntokun

multi: fix nonce handling bug

In this commit, we fix a nonce handling bug. The bug was unnoticed until
interop testing due to some inadvertent mutation. Before this commit, in
peer/brontide.go, we used the _same_ instance of the musig2 chan closer,
which masked the bug.

The issue was that we would attempt to generate a siganture for the
remote party _before_ we had applied their JIT nonce to our remote (used
to sign their close txn) musig session.

We first created a new test to confirm the issue (in peer, as it needed
to be in order to avoid a circular dep test). Without these changes, the
test fails.

The fix is two fold:
1. Create two independent musig2 chan closers.
2. Update the ordering to apply their nonce before we generate a
signature.

95/100 · StrongMessage clarity
✓ 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 boundarysigning or wallet path
AI analysis · Moderate 59/100

This commit fixes a bug in LND's cooperative channel-closing code for Taproot channels. When two parties try to close a Lightning channel together, the code accidentally used the same internal helper for both sides and tried to create a signature before the other side's one-time 'nonce' had been applied. The fix creates two separate helpers and reorders the steps so the nonce is applied before signing. The commit message and new test say the bug was hidden in normal use because a shared object masked the ordering problem, and it only surfaced during interoperability testing.

Security candidatelnwallet/chancloser: remove dead code and wrap errorsby Olaoluwa Osuntokun · ed1e5411 · Mar 27, 2026 · 1 fileMessage 73 · AdequateInformational 17Details
Commit message · Olaoluwa Osuntokun

lnwallet/chancloser: remove dead code and wrap errors

Remove the redundant `remoteMusig \!= nil` check inside the
`IsTaproot()` guard in sendShutdownEvents. Since IsTaproot() requires
both LocalMusigSession AND RemoteMusigSession to be non-nil, the nested
nil check can never be false.

Also wrap bare `return nil, err` with context in LocalOfferSent and
RemoteCloseStart ProcessEvent methods for prepareClosingSignatures,
CompleteCooperativeClose, and createLocalCloseeSignature calls.

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

This is a small code cleanup in LND's cooperative channel-closing logic. It removes a redundant safety check that could never fail and adds more descriptive error messages when closing a Lightning channel. There is no direct security vulnerability being fixed, and no exploit path is introduced or removed.

Security candidatelnwire: add taproot signatures support to closing_complete messageby Olaoluwa Osuntokun · 0ce026af · Mar 27, 2026 · 9 filesMessage 88 · StrongLow 46Details
Commit message · Olaoluwa Osuntokun

lnwire: add taproot signatures support to closing_complete message

In this commit we, add support for taproot partial signatures with
nonces to the ClosingComplete message. This is the foundation for
taproot RBF cooperative channel closing, implementing the JIT nonce
pattern required for the modern taproot closing flow.

The changes include a new TaprootClosingSigs struct that mirrors the
existing ClosingSigs but uses PartialSigWithNonce for taproot channels.
The decoding and encoding functions are updated to handle both regular
ECDSA signatures and taproot partial signatures. For taproot channels,
the TaprootClosingSigs field is populated while ClosingSigs remains
empty, maintaining backward compatibility.

We also fix a minor typo in the comment for CloserNoClosee field
(clsoee -> closee).

lnwire: add taproot partial signatures support to closing_sig message

In this commit we, extend the ClosingSig message to support taproot
partial signatures for the RBF cooperative close flow. The ClosingSig
message is sent by the closee in response to a ClosingComplete message.

For taproot channels, we add TaprootPartialSigs which contains partial
signatures without nonces since the remote party already knows our
nonce from the previous ClosingComplete message. We also add a
NextCloseeNonce field for RBF iterations, allowing the closee to
provide a new nonce for the next potential RBF round.

The decoding and encoding functions are updated to handle both regular
signatures and taproot partial signatures, maintaining backward
compatibility with existing non-taproot channels while enabling the
advanced taproot RBF flow.

lnwire: add shutdown nonce support for taproot channels

In this commit we, add support for closee nonces in the Shutdown
message to enable taproot RBF cooperative channel closing. The
ShutdownNonce field allows taproot channels to exchange the initial
nonces required for the MuSig2 signing process during cooperative
closure.

This nonce represents the closee nonce that the remote party will use
when they act as the closer in the RBF flow. The nonce is transmitted
as part of the shutdown flow and is essential for the JIT nonce pattern
used in the modern taproot closing protocol.

The changes maintain backward compatibility as the ShutdownNonce field
is optional and only used for taproot channels that support the
enhanced RBF flow.

lnwire: update test message with taproot signature fields

In this commit we, update the test message utilities to include the new
taproot signature fields added to ClosingComplete and ClosingSig
messages. This ensures the wire protocol tests properly exercise the
new taproot partial signature functionality.

chancloser: add taproot channel infrastructure and nonce state management

In this commit we, add the fundamental infrastructure for taproot RBF
cooperative channel closing. This includes adding taproot channel
detection, MuSig2 session management, and nonce state tracking
throughout the closing state machine.

Key additions include the IsTaproot method on Environment to detect
taproot channels based on the presence of MuSig sessions, and
LocalMusigSession/RemoteMusigSession fields for managing the different
signing contexts. We add NonceState tracking to maintain closee nonces
exchanged during the shutdown phase.

The SendShutdown and ShutdownReceived events are extended to carry
closee nonces for taproot channels, and we add proper error handling
for missing nonces in taproot shutdown messages. These changes provide
the foundation for the taproot-specific state transitions while
maintaining compatibility with existing non-taproot channels.

chancloser: implement taproot cooperative close state transitions

In this commit we, implement the complete taproot RBF cooperative close
state machine transitions. This is a comprehensive change that adds all
the necessary components for taproot channel closing support.

The implementation includes several key areas:

First, we add nonce management helpers including initLocalMusigCloseeNonce
and initRemoteMusigCloseeNonce for properly initializing MuSig2 sessions
with the appropriate closee nonces during the RBF flow.

Second, we implement signature extraction and validation helpers including
partialSigToWireSig for converting partial signatures to wire format, and
extractTaprootSigAndNonce, extractSigAndNonce, and validateAndExtractSigAndNonce
for handling both taproot and regular signatures with proper validation.

Third, we add comprehensive signature encoding logic with encodeClosingSignatures
that creates appropriate signature structures for both channel types, and helper
functions like processRemoteTaprootSig, createLocalCloseeSignature, and
createClosingSigMessage for managing the complex taproot signing flow.

Fourth, we extend the shutdown validation logic to require nonces for
taproot channels and update all state transitions to properly handle
nonce exchange, MuSig2 session initialization, and the dual signature
paths for taproot vs non-taproot channels.

Finally, we add signature preparation logic with prepareClosingSignatures
and extraction helpers like extractSigAndNonceFromComplete that handle
the complex musig signature combination required for taproot channels
while maintaining compatibility with existing ECDSA signatures.

The changes maintain backward compatibility with existing non-taproot
channels while enabling the full taproot RBF cooperative close flow
with proper nonce rotation and signature handling.

chancloser: add taproot test infrastructure and test cases

In this commit we, extend the RBF cooperative close test suite to
support taproot channels. This includes adding schnorr signature
test constants, taproot channel test helpers, and comprehensive
test coverage for the taproot RBF flow.

The changes add localSchnorrSig and remoteSchnorrSig test constants
to mirror the existing ECDSA signatures, and include proper imports
for musig2, chainhash, and lnwallet to support the taproot testing
infrastructure.

The test modifications ensure that both taproot and non-taproot
channels are properly tested throughout the RBF cooperative close
state machine, validating the dual signature handling paths and
nonce management logic introduced in the main implementation.

chancloser: update test utilities and message mapping for taproot

In this commit we, update the chancloser test utilities and message
mapping functions to properly handle the new taproot-specific fields
in the RBF cooperative close flow.

The changes ensure that test harnesses and message mapping functions
are aware of the taproot signature fields and nonce handling required
for the extended wire protocol support. This maintains test coverage
for both existing non-taproot functionality and the new taproot
capabilities.

88/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarydefensive validationsigning or wallet path
AI analysis · Low 46/100

This commit adds support for taproot (MuSig2) cooperative channel closing in LND's RBF close protocol. It introduces new wire message fields for taproot partial signatures and nonces, updates the state machine to handle both ECDSA and taproot paths, and adds tests. There is no direct evidence in the commit message or diff that this fixes a known security vulnerability; it appears to be a feature implementation for taproot channel compatibility.

Security candidatelnwire: add LocalNonces TLV structure and testsby Olaoluwa Osuntokun · df29787d · Mar 25, 2026 · 2 filesMessage 78 · AdequateInformational 15Details
Commit message · Olaoluwa Osuntokun

lnwire: add LocalNonces TLV structure and tests

This commit introduces a new TLV structure LocalNoncesData that contains
a map of transaction IDs to MuSig2 nonces. This structure enables
coordinating multiple nonces for different purposes (e.g., channel
commits, splice operations) within a single wire message.

This is a prep for upcoming spec changes to allow a party that has
in-prorgess splices to tell the remote party which nonces to use for
which splice.

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

This commit adds a new data structure and wire format for exchanging groups of cryptographic nonces used in multi-signature Lightning transactions. It is purely preparatory code: it defines how to pack and unpack the data and includes unit tests. There is no actual use of this structure in message handling yet, and nothing in the commit suggests a security bug or fix.

Security candidatelncli: add `sign` subcommand to `lncli wallet psbt`by Oli · 99712e1c · Mar 24, 2026 · 1 fileMessage 65 · AdequateInformational 18Details
Commit message · Oli

lncli: add `sign` subcommand to `lncli wallet psbt`

Adds a new sub command `lncli wallet psbt sign` to `lncli` that calls
the wallet RPC's `SignPsbt` method.

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 18/100

This commit adds a new command-line option to LND's wallet tool that lets users sign partially-built Bitcoin transactions (PSBTs). It is a feature addition that exposes an already-existing wallet RPC through the lncli interface. There is no indication in the commit that it fixes a bug or addresses a security vulnerability.

Security candidatelnwire: validate MuSig2 nonce points on wire decodeby Erick Cestari · 7517295e · Mar 19, 2026 · 6 filesMessage 73 · AdequateModerate 62Details
Commit message · Erick Cestari

lnwire: validate MuSig2 nonce points on wire decode

Add point-on-curve validation for MuSig2 public nonces at the TLV
decode layer. A MuSig2 nonce is 66 bytes (two 33-byte compressed
secp256k1 public keys). Previously, nonce bytes were accepted without
validation, with invalid points only failing later during MuSig2
session creation deep in the signing flow. Now, malformed nonces from
a peer are rejected immediately at decode time with clear errors.

This hardens all nonce-carrying messages: ClosingComplete (JIT closer
nonces in PartialSigWithNonce), ClosingSig (NextCloseeNonce), Shutdown,
ChannelReestablish, CommitSig, and others.

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

This change tightens input checking for a special type of cryptographic value (a MuSig2 nonce) that peers send to each other in Lightning Network messages. Before, a peer could send bytes that looked like a nonce but were not valid points on the Bitcoin curve; those invalid values would only be caught later, deep inside the signing code. Now they are rejected immediately when the message is first decoded. This is a defensive hardening fix: it makes the protocol more robust against malformed or malicious peer input and prevents potential crashes or unexpected behavior in the signing flow.

Security candidatechanneldb: add V2 (taproot) waiting proof codec supportby Elle Mouton · fd239c18 · Mar 17, 2026 · 4 filesMessage 73 · AdequateInformational 18Details
Commit message · Elle Mouton

channeldb: add V2 (taproot) waiting proof codec support

Introduce the WaitingProofInner interface and two concrete
implementations — V1WaitingProof (AnnounceSignatures1) and
V2WaitingProof (AnnounceSignatures2 + optional aggregate MuSig2 nonce).

WaitingProof.Encode/Decode now dispatch on the type prefix byte added
in the previous commit, so the store can transparently persist either
proof variant.

The gossiper is updated with a V1 type assertion to maintain existing
behaviour; full V2 gossiper integration will follow when taproot channel
announcements are wired up.

No live code path creates V2 waiting proofs yet — this commit only
lands the codec and storage readiness so the schema is in place before
new writers are introduced.

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

This commit adds database support for a new kind of channel-announcement proof used by upcoming taproot channels. It does not change any live network behavior; it only prepares the code so future taproot features can store their proofs safely. Existing V1 proofs keep working exactly as before, and the gossiper is explicitly restricted to V1 proofs only.

Security candidatemod+multi: bump neutrino to v0.16.2, btcwallet to 70a94ea39e9cby Olaoluwa Osuntokun · 641ff68c · Mar 10, 2026 · 12 filesMessage 88 · StrongLow 32Details
Commit message · Olaoluwa Osuntokun

mod+multi: bump neutrino to v0.16.2, btcwallet to 70a94ea39e9c

In this commit, we update our two core chain backend dependencies:
neutrino is bumped from v0.16.1 to v0.16.2, and btcwallet is updated
to commit 70a94ea39e9c (a pre-release past v0.16.17).

The updated btcwallet changes the `chain.Interface` `Start` method
signature from `Start() error` to `Start(context.Context) error`. The
same change was made to neutrino's `ChainService.Start`. We update all
call sites and interface implementations across the codebase to pass a
`context.Background()` at non-test call sites, and `t.Context()` in
tests.

The affected packages are: chainntnfs/bitcoindnotify, chainreg,
config_builder, lnmock, lntest/unittest, lnwallet/btcwallet,
lnwallet/test, and routing/chainview.

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 boundarysigning or wallet path
AI analysis · Low 32/100

This commit updates two core software building blocks (neutrino and btcwallet) used by the Lightning Network Daemon (LND). The main visible change is that the 'Start' method of these building blocks now requires a context parameter, so the LND code is adjusted to pass one. The commit also pulls in newer versions of many supporting libraries. There is no direct evidence in the commit message or diff that this fixes a specific security vulnerability; it looks like a routine dependency and API-signature update. However, because it bumps chain-backend and cryptographic libraries, it could indirectly include security fixes from those upstream projects.

Security candidateMerge pull request #9637 from Roasbeef/chan-type-requiredby Olaoluwa Osuntokun · cd755cda · Mar 5, 2026 · 2090 filesMessage 73 · AdequateInformational 15Details
Commit message · Olaoluwa Osuntokun

Merge pull request #9637 from Roasbeef/chan-type-required

feature: start to set the require bit for channel_type

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
cryptography-sensitive pathseed or entropy pathsigning or wallet pathboot or update pathauthentication pathparser or protocol pathmerge-commit duplicate discount
AI analysis · Informational 15/100

This commit is a massive repository import or rebase that adds the entire LND codebase plus many new GitHub workflow, documentation, and configuration files. The stated title refers to a Lightning protocol feature ('start to set the require bit for channel_type'), but the supplied diff does not show any code changes related to channel_type; it only shows newly added repository scaffolding. There is no evidence in the provided materials of a security vulnerability or a security-relevant code change.

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.

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

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

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

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

88/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarydefensive validation
AI analysis · Low 29/100

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

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