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 21 minutes 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 candidateonionmessage: use BackpressureMailbox for onion peer actorsby Gijs van Dam · e87f4bfb · Mar 28, 2026 · 3 filesMessage 78 · AdequateLow 40Details
Commit message · Gijs van Dam

onionmessage: use BackpressureMailbox for onion peer actors

This commit adds per-peer backpressure control to the onion message
actor system by introducing a BackpressureMailbox that uses Random
Early Detection (RED) to probabilistically drop messages when the
per-peer queue depth exceeds a configurable threshold.

The OnionActorFactory type now accepts variadic ActorOptions, allowing
the spawn call site (brontide) to provide per-peer mailbox configuration.
A DefaultOnionActorOpts helper provides the standard RED thresholds so
callers don't need to wire up the BackpressureMailbox manually.

Key changes:
- OnionActorFactory signature extended with ...ActorOption[*Request,
*Response] so backpressure policy is no longer baked into the factory.
- NewOnionActorFactory drops its shouldDrop parameter; it forwards opts
through to serviceKey.Spawn.
- DefaultOnionActorOpts(shouldDrop) returns the default backpressure
options (BackpressureMailbox + DefaultOnionMailboxSize).
- peer.Config gains OnionActorOpts callback for per-peer customization.
- server.go creates default opts once and returns them for every peer.

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

This commit adds a safety valve to how LND handles 'onion messages'—a type of private Lightning Network message. Before this change, a flood of onion messages from a peer could fill up an internal queue and stall the connection handler. Now, when a per-peer queue gets too full, messages are probabilistically dropped using a technique called Random Early Detection (RED), and the handler uses a timeout so it cannot block forever. The change is defensive hardening rather than a fix for a known active attack.

Security candidatelnwire: reject messages with both regular and taproot signaturesby Olaoluwa Osuntokun · d4da3502 · Mar 27, 2026 · 2 filesMessage 73 · AdequateLow 47Details
Commit message · Olaoluwa Osuntokun

lnwire: reject messages with both regular and taproot signatures

Add decode-time validation to closing_complete and closing_sig that
rejects messages containing both regular ECDSA and taproot partial
signatures. This provides defense-in-depth rather than relying solely
on state machine validation.

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 · Low 47/100

This change adds an extra safety check when LND receives certain channel-closing messages. It now rejects messages that contain both old-style ECDSA signatures and new taproot-style signatures at the same time. The developers describe this as 'defense-in-depth,' meaning it is an extra guard rail rather than a fix for a known active attack. It makes the protocol stricter so a malformed or malicious message cannot carry both signature types.

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 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 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 candidatechancloser: update RBF close documentation for taproot supportby Olaoluwa Osuntokun · 57def3bc · Mar 27, 2026 · 1 fileMessage 78 · AdequateTriage 8Details
Commit message · Olaoluwa Osuntokun

chancloser: update RBF close documentation for taproot support

In this commit we, update the RBF cooperative close documentation to
comprehensively cover the taproot channel closing flow. The documentation
now explains the JIT nonce pattern, asymmetric signature roles, and the
complete nonce exchange protocol for taproot channels.

Key additions include detailed explanations of how nonces flow through
the RBF process, the distinction between closer and closee roles, and
the specific wire message extensions for PartialSigWithNonce and
NextCloseeNonce fields. The documentation also covers validation
requirements and implementation notes specific to taproot channels.

This documentation provides a complete reference for understanding
and implementing the enhanced taproot RBF cooperative close protocol.

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 boundarysigning or wallet pathdocumentation-only discount
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 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 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 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 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 candidatelnwire+peer: ignore no-reply pingsby yyforyongyu · 08b26b61 · Mar 26, 2026 · 4 filesMessage 68 · AdequateTriage 10Details
Commit message · yyforyongyu

lnwire+peer: ignore no-reply pings

Allow pings in the BOLT 1 no-reply range to decode and be ignored
instead of disconnecting peers. This keeps reconnects compatible with
peers that pad channel_reestablish with no-reply pings.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
authentication path
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 candidatechanneldb: add type-prefix to waiting proof store recordsby Elle Mouton · e0256a7d · Mar 17, 2026 · 7 filesMessage 95 · StrongLow 26Details
Commit message · Elle Mouton

channeldb: add type-prefix to waiting proof store records

Existing waiting proof records encode a bare isRemote flag followed by a
raw AnnounceSignatures1 payload. A future gossip v2 implementation will
store AnnounceSignatures2 (taproot) proofs in the same bucket, so each
record needs a discriminator byte to select the correct decoder.

This commit:

1. Defines WaitingProofTypeV1 (= 0x00) for the current
AnnounceSignatures1-based proofs.
2. Updates WaitingProofKey to 10 bytes [proofType(1) || scid(8) ||
isRemote(1)] to avoid cross-version key collisions.
3. Adds migration 35, which rewrites every existing record to prepend
the type byte and rewrites keys to the new format.
4. Updates WaitingProof.Encode/Decode to always write/expect the prefix.

The migration, codec changes, and tests are kept in one atomic commit so
there is no intermediate revision where the new Decode can encounter
unmigrated records.

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 boundary
AI analysis · Low 26/100

This commit is a forward-looking database format change for LND's 'waiting proof store,' which holds channel announcement proofs. It adds a one-byte type marker to each stored record and its lookup key so that a future gossip v2/Taproot version can safely store a different proof type in the same place. It also ships a database migration that rewrites all existing records to the new format. The change is defensive and structural, not a fix for an active vulnerability.

Security candidategraph,discovery: version IsZombieChannelby Elle Mouton · cb99637f · Mar 16, 2026 · 5 filesMessage 63 · AdequateLow 40Details
Commit message · Elle Mouton

graph,discovery: version IsZombieChannel

Change the IsZombieChannel / isStillZombieChannel function signature
throughout the gossip and routing stacks from
func(time.Time, time.Time) bool to func(ChannelUpdateInfo) bool.

This allows zombie detection to inspect the full channel update info—
including version and freshness type—rather than receiving two raw unix
timestamps that carry no meaning for v2 channels.

Builder.IsZombieChannel is updated to extract version-appropriate
freshness from the ChannelUpdateInfo: unix-time expiry for v1, and a
block-count expiry (derived from ChannelPruneExpiry and
avgBitcoinBlockTime) for v2. The gossipSyncer, SyncManager, and gossiper
Config fields are updated to use the new signature.

63/100 · AdequateMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Low 40/100

This commit updates how the Lightning Network Daemon (LND) decides whether a payment channel is a 'zombie'—meaning it has gone stale and should be ignored or pruned. Previously, zombie detection only looked at wall-clock timestamps, which works for older v1 gossip channels but not for newer v2 channels that use block heights to show freshness. The change lets the code inspect the full channel update information, including its version and freshness type, so v2 channels are correctly evaluated by block height rather than by time. This is a correctness improvement, not an obvious active vulnerability, but misclassifying v2 channels could affect routing reliability and graph health.

Security candidategraph/db: version FilterChannelRangeby Elle Mouton · 3c06daed · Mar 16, 2026 · 5 filesMessage 73 · AdequateLow 28Details
Commit message · Elle Mouton

graph/db: version FilterChannelRange

Add a gossip version parameter to FilterChannelRange in the Store interface,
both KV and SQL implementations, and the ChannelGraph wrapper.

KVStore guards against non-v1 versions with ErrVersionNotSupportedForKVDB.
SQLStore accepts any known gossip version, filtering the channel results by
version and using it in policy lookups. The SQL query still uses
GetPublicV1ChannelsBySCID for now (a TODO marks where a version-aware query
will be substituted in a follow-up).

VersionedGraph.FilterChannelRange shadows the ChannelGraph method with a
version-free signature, passing its baked-in version to the store. This keeps
the ChannelGraphTimeSeries interface and ChanSeries implementation unchanged.

Add TestFilterChannelRangeVersionGuard to verify that the KV store returns
ErrVersionNotSupportedForKVDB for v2 requests while the SQL store handles
them gracefully.

73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Low 28/100

This commit changes how LND's graph database filters channel ranges by adding a 'gossip version' parameter. It is a preparatory/infrastructure change: the older KV database now explicitly refuses version 2 requests, while the newer SQL database accepts them but still mostly uses the old version-1 query path (marked with a TODO for a future update). There is no obvious security vulnerability in the patch itself; it is more about making the code ready for future gossip protocol versions.

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 candidategraph/db/migration1: fix defer commit/rollback in test tx executorby ziggie · 932fbc33 · Feb 25, 2026 · 1 fileMessage 83 · StrongInformational 21Details
Commit message · ziggie

graph/db/migration1: fix defer commit/rollback in test tx executor

The defer closure checked a local err variable for commit/rollback
decisions, but err remained nil after a successful BeginTx. When
txBody failed, the error was returned directly without assigning to
err, so the defer always committed instead of rolling back.

Additionally, since err was not a named return value, the defer's
Commit error assignment was silently swallowed.

Replace the error-prone defer pattern with explicit rollback on
txBody failure and a direct Commit return.

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

This commit fixes a bug in a test helper that runs database transactions for LND's graph database migration tests. The old code accidentally committed every transaction, even when the inner test work failed, because of a subtle Go error-handling mistake. The fix makes failed transactions roll back and successful ones commit properly. This is test-only code, so it does not directly affect live Lightning nodes, but it could have caused migration tests to leave partial or incorrect data in the database instead of rolling back as intended.

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

ci: add verify-release workflow

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

90/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing boundarydefensive validationdocumentation-only discount
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.