LL
← All projectsLightning Labs

LND

Go implementation of a complete Lightning Network node.

BitcoinLightning NetworkNormal
Repository coverage

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

141security candidates194second-pass queue1285AI analyses
78commits · 30 days
173commits · 60 days
599commits · 180 days
1237commits · 365 days
Backfill bands
Aug 5 → Feb 6405 seen5 candidatesComplete
Feb 6 → Jun 6665 seen28 candidatesComplete
Jun 6 → Jul 689 seen4 candidatesComplete
Jul 6 → Aug 569 seen0 candidatesComplete
Commit communication

Does the history explain itself?

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

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

Who is changing the project?

Public Git author strings; identities are not independently verified.

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

Published AI watches

Last scanned 29 minutes ago

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

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

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

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

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

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

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

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

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

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

zpay32: reject duplicate payment hash fields

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

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

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

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

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

itest: stop creating legacy channels

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

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

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

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

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

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

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

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

build: adopt focused golangci-lint v2.13 checks

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

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

lnrpc: regenerate protos with Go 1.27

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

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

build: fix Go 1.27 compatibility

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

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

build: bump Go language and toolchain versions

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

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

invoices: cancel only the failing AMP set on reconstruction failure

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

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

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

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

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

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

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

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

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

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

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

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

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

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

bolt12: verify invoice_request and invoice signatures on read

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

Missing cryptographic verification on parsed BOLT 12 messages replaced with BIP-340 Schnorr signature verificationReader accepted any 64-byte placeholder signature before the patchNew negative tests verify rejection of wrong-signer and tampered Merkle-root fields
aa8bd19fby bitromortac+272−723 files
Vendor flagged security relevance
Informational 15 AI analysisMessage 78 · Adequate
LL Lightning LabsLND BitcoinLightning Network

itest: cover confirmation-controlled leases

This commit only adds a new integration test for an existing feature called confirmation-controlled leases. It does not change production code, so it cannot introduce a security vulnerability or fix one directly. The test exercises how lon…

a1ab4e92by Andras Banki-Horvath+152−02 files
No security note in commit
Moderate 68 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11122 from gijswijs/websocket-proxy-hardening

This update fixes two security-related bugs in LND's REST WebSocket proxy. First, a specially crafted WebSocket protocol header could crash the proxy (a panic). Second, the proxy previously had no limit on how large an incoming WebSocket m…

panic fix in request header parsingunbounded incoming WebSocket message read now cappedincorrect header value assignment possible before fix
c662f853by Yong+227−104 files
Vendor flagged security relevance
Repository ledger

Explore captured commits

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

Security candidateMerge pull request #11132 from yyforyongyu/task-11129-pongby Olaoluwa Osuntokun · d3d1f1d0 · Sep 22, 2026 · 5 filesMessage 58 · ThinModerate 53Details
Commit message · Olaoluwa Osuntokun

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

peer: answer every valid ping

58/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
Why it was queued
authentication pathmerge-commit duplicate discount
AI analysis · Moderate 53/100

This change fixes how LND answers network 'ping' messages from other Lightning nodes. Previously, LND would sometimes silently ignore valid pings to limit reply traffic, which violates the Lightning protocol (BOLT 1) and could make a peer think the connection is dead. Now LND replies to every valid ping, while still disconnecting peers that flood too many pings. The cost of a reply is counted against a single flood budget based on how large the reply would be.

Security candidateMerge pull request #11198 from gijswijs/amp-setlocal-reconstruction-fixby Olaoluwa Osuntokun · 88959aec · Sep 19, 2026 · 4 filesMessage 73 · AdequateModerate 60Details
Commit message · Olaoluwa Osuntokun

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

invoices: cancel only the failing AMP set on reconstruction failure

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Why it was queued
boot or update pathmerge-commit duplicate discount
AI analysis · Moderate 60/100

This change fixes a bug in LND's handling of AMP (Atomic Multi-Path) payments. Previously, if one partial payment set failed to reconstruct its secret preimage, the entire invoice was canceled, including unrelated partial payment sets from other payers. Now only the failing set is canceled, and the invoice stays open so other valid sets can still complete and settle. This is a correctness/availability fix for reusable AMP invoices.

Security candidatebuild: fix Go 1.27 compatibilityby ziggie · 6b54a387 · Sep 18, 2026 · 6 filesMessage 100 · StrongInformational 20Details
Commit message · ziggie

build: fix Go 1.27 compatibility

Upgrade the custom golangci-lint from v2.4.0 to v2.13.2 because the older
version reports false type-checking errors for generic mutex code when it
runs with Go 1.27. Refresh the tools module dependencies, account for the
renamed exhaustruct_v5 linter, and disable the deprecated gomodguard while
leaving gomodguard_v2 active.

Apply Go 1.27's gofmt output to the PSBT test's composite-literal return.

Lower the consecutive-SCID zlib test boundary from 30,794 to 30,792. Go
1.27 changed compress/flate output, making 30,793 SCIDs exceed the
65,535-byte Lightning message limit while 30,792 still fit.

100/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 20/100

This commit is a routine build-and-test maintenance patch to make the LND codebase compile and pass tests with the upcoming Go 1.27 release. It upgrades the project's custom linter tool, refreshes many indirect tool dependencies, adjusts one test's formatting, and lowers a test constant that checks how many compressed channel IDs fit in a Lightning message. There is no direct security fix here; it is a compatibility and test-hygiene change.

Security candidateinvoices: cancel only the failing AMP set on reconstruction failureby Gijs van Dam · d74ab6fa · Sep 16, 2026 · 2 filesMessage 83 · StrongModerate 60Details
Commit message · Gijs van Dam

invoices: cancel only the failing AMP set on reconstruction failure

When an AMP set completes but fails preimage reconstruction, updateMpp
issued a CancelInvoiceUpdate that canceled the greater invoice. For
reusable static AMP invoices this is too broad: the failure is a
set-local condition, since only the HTLCs of the failing set can never
settle. Other sets accepted on the same invoice are unaffected by the
failure and should remain payable.

Issue a CancelHTLCsUpdate scoped to the failing set instead, keeping
the invoice open. Adds a regression test verifying that a concurrently
accepted set on the same invoice survives a failing set and can still
settle.

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
fuzzing or regression evidenceboot or update path
AI analysis · Moderate 60/100

This commit fixes a bug in LND's invoice handling for reusable AMP (Atomic Multi-Path) invoices. Previously, if one payment set failed to reconstruct its preimage, the entire invoice was canceled, even though other valid payment sets on the same invoice were unaffected. Now, only the failing set is canceled, and the invoice stays open so other payers can still complete their payments. This is a correctness and availability fix for a specific Lightning Network payment feature.

Security candidateMerge pull request #11061 from bitromortac/2604-bolt12-1fby Yong · 1049d301 · Sep 8, 2026 · 15 filesMessage 73 · AdequateLow 34Details
Commit message · Yong

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

bolt12: add Merkle tree and BIP-340 message signatures

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
signing boundarysigning or wallet pathparser or protocol pathmerge-commit duplicate discount
AI analysis · Low 34/100

This commit adds the missing cryptographic signature layer for BOLT 12 offers in LND. It builds a Merkle tree from the message fields, signs that tree with a BIP-340 Schnorr signature, and now rejects invoice requests and invoices whose signatures do not verify. It also tightens decoding so non-minimal encodings of feature bits and amounts are rejected, preventing a message from being accepted in one form but re-encoded into a different byte form that would break the signature.

Security candidatebolt12: verify invoice_request and invoice signatures on readby bitromortac · aa8bd19f · Sep 2, 2026 · 3 filesMessage 88 · StrongModerate 60Details
Commit message · bitromortac

bolt12: verify invoice_request and invoice signatures on read

ValidateInvoiceRequestRead and ValidateInvoiceRead now run
VerifyInvoiceRequest and VerifyInvoice as their final step, so a
decoded message whose BIP-340 signature does not verify against
invreq_payer_id or invoice_node_id is rejected instead of only
checked for presence. This satisfies the reader-side MUSTs of the
BOLT 12 invoice_request and invoice requirements, and the docstrings
now state the contract instead of deferring it to callers.

The invoice_request wiring is pinned by the spec's signed vector; no
signed invoice vector exists, so the invoice side is pinned by
round-trip tests. Reader-validation fixtures now sign with Bob's
key, and the happy-path invoice_request test reuses the shared
validInvoiceRequest fixture.

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 · Moderate 60/100

This change makes LND's BOLT 12 invoice and invoice-request reader actually check that the digital signature is valid, instead of only checking that a signature field exists. Before, an attacker could craft or modify a BOLT 12 message and include any 64-byte placeholder as a 'signature'; the reader would accept it as long as the field was present. Now the reader verifies the signature cryptographically against the claimed sender public key, rejecting forgeries and tampered messages. This is a security-hardening fix that closes a real authentication gap.

Security candidateMerge pull request #11090 from yyforyongyu/task-peer-managerby Yong · d24719e0 · Aug 28, 2026 · 15 filesMessage 73 · AdequateHigh 76Details
Commit message · Yong

Merge pull request #11090 from yyforyongyu/task-peer-manager

peer: bound peer-controlled resource growth

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Why it was queued
boot or update pathauthentication pathmerge-commit duplicate discount
AI analysis · High 76/100

This update to the LND Lightning node software fixes two security-related bugs. First, it prevents a connected peer from exhausting the node's memory or CPU by sending floods of ping messages or by forcing the node to queue too many outbound messages. Second, it fixes a signature mismatch in channel-update messages that carry inbound fees, so updates are signed exactly as they are broadcast and unknown extra data is preserved. The release notes explicitly describe both as preventing peer-controlled resource exhaustion and remote signature failures.

Security candidatedocs: note configurable WalletKit lease lifetimeby Andras Banki-Horvath · 37945535 · Aug 26, 2026 · 1 fileMessage 72 · AdequateInformational 15Details
Commit message · Andras Banki-Horvath

docs: note configurable WalletKit lease lifetime

Document the new LeaseOutput and FundPsbt confirmation-depth option in
the 0.22.0 release notes.

72/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body
Why it was queued
signing boundarydocumentation-only discount
AI analysis · Informational 15/100

This commit only adds documentation to the release notes describing a new WalletKit feature: output leases can now optionally stay active until a spending transaction reaches a chosen confirmation depth. There is no code change, no bug fix, and no security-related content in the commit itself.

Security candidatewalletrpc: expose configurable output leasesby Andras Banki-Horvath · 515ceaac · Aug 26, 2026 · 8 filesMessage 68 · AdequateInformational 24Details
Commit message · Andras Banki-Horvath

walletrpc: expose configurable output leases

Add optional confirmation-depth fields to LeaseOutput and FundPsbt. A
non-zero value selects a lease that ignores wall-clock expiry and
releases at the requested spend depth or by explicit owner release. Zero
preserves time-controlled leases.

Resolve wallet capability before acquiring inputs so unsupported
backends fail closed even when FundPsbt selects no new input. Echo the
accepted depth after installation, and expose persisted spend height
through ListLeases so clients can observe confirmation and reorg
progress.

Cover option forwarding, zero-depth compatibility, unsupported wallets,
partial acquisition rollback, and response marshalling.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 24/100

This commit adds a new optional feature to LND's wallet RPC that lets callers lock a coin (a 'UTXO lease') until the transaction spending it reaches a chosen number of confirmations, instead of relying only on a clock-time expiration. It also exposes more lease information in responses and lists. The change is defensive: it checks wallet support before locking, rejects unsupported wallets, requires a caller-chosen lock ID for the new mode, and preserves the old time-based behavior when the new option is not used. There is no direct evidence in the commit of a fixed vulnerability; it reads like a capability addition with safety checks.

Security candidatebuild: pin configurable btcwallet output leasesby Andras Banki-Horvath · 6f73d73d · Aug 26, 2026 · 3 filesMessage 80 · StrongModerate 60Details
Commit message · Andras Banki-Horvath

build: pin configurable btcwallet output leases

Pin btcwallet and wtxmgr to the canonical upstream commit that
merged the configurable-lease API and its wall-clock expiry fix.

Without the follow-up fix, a slowly confirming spend can outlive its
timed lease before wtxmgr records the spend height. A later shallow
reorg can then expose the input to coin selection.

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
access control
AI analysis · Moderate 60/100

This commit updates LND's dependency versions for btcwallet and wtxmgr to a newer upstream version that fixes a timing issue with 'output leases.' In plain terms, when LND temporarily reserves a coin (UTXO) for a transaction, it sets an expiration time. The bug being fixed is that a slow-to-confirm spend could have its reservation expire before the wallet records that the coin was actually spent. If a shallow blockchain reorganization then happens, the wallet might mistakenly think the coin is still available and select it again for a new transaction. This could lead to double-spending attempts or channel failures. The commit itself only changes version pins and linter settings; the actual code fix lives in the upstream btcwallet/wtxmgr libraries.

Security candidatelnwire: preserve channel update extrasby yyforyongyu · 7afea2bd · Aug 26, 2026 · 4 filesMessage 83 · StrongModerate 59Details
Commit message · yyforyongyu

lnwire: preserve channel update extras

Canonicalize channel update TLV data without mutating the message during
encoding. This keeps unknown records intact, reconciles legacy duplicate
inbound fee representations, and makes signing match the emitted bytes.

Cover receiver immutability, legacy encoding shapes, concurrent
encoding, and signature verification across a wire round trip.

83/100 · StrongMessage clarity
✓ 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 validationboot or update path
AI analysis · Moderate 59/100

This change fixes how Lightning channel-update messages handle optional extra data. Previously, encoding could silently rewrite the message's internal byte slice, which could cause signature mismatches, lost unknown fields, and race conditions when the same message was encoded from multiple threads. The patch now builds a fresh canonical copy of the extra data for each encoding/signing operation without changing the original message. The tests explicitly verify that signatures still verify after a full encode-decode round trip, that unknown fields survive, and that concurrent encoders no longer race.

Security candidatepeer: test outgoing queue costsby yyforyongyu · 64645cc5 · Aug 25, 2026 · 1 fileMessage 78 · AdequateInformational 15Details
Commit message · yyforyongyu

peer: test outgoing queue costs

Cover each non-serializing queue cost rule with declarative message
shapes. Pin the retained opaque data charged for all active v1 bulk
gossip messages.

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

This commit only adds a new automated test file. It does not change any production code, so it cannot introduce a security vulnerability or fix one directly. The test verifies how the outgoing message queue calculates the memory cost of different network messages, helping ensure future code changes do not accidentally under-count or over-count queue memory usage.

Security candidateMerge pull request #11008 from LNBIG-COM/fix/psbt-funding-lock-orderby Yong · a912dd69 · Aug 24, 2026 · 3 filesMessage 73 · AdequateModerate 66Details
Commit message · Yong

Merge pull request #11008 from LNBIG-COM/fix/psbt-funding-lock-order

lnwallet: fix limboMtx/intentMtx lock order inversion in PsbtFundingVerify

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
signing boundarysigning or wallet pathmerge-commit duplicate discount
AI analysis · Moderate 66/100

This commit fixes a classic multi-threading bug in LND's wallet code. Two functions were acquiring the same two locks in opposite orders, which could cause a deadlock. When triggered, the wallet's single request-handler goroutine would freeze, permanently stopping all channel opening on the node and preventing newly confirmed channels from being announced. Only a restart would recover. The fix reorders the lock acquisition so both functions now take the locks in the same order.

Security candidatepeer: rate limit inbound pingsby yyforyongyu · b9388cca · Aug 21, 2026 · 2 filesMessage 68 · AdequateModerate 65Details
Commit message · yyforyongyu

peer: rate limit inbound pings

Bound Pong replies with separate reply and flood token buckets.
Count every decoded Ping before generic routing. Disconnect peers that
exhaust the flood budget through a stable sentinel error.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
authentication path
AI analysis · Moderate 65/100

This commit adds rate limits on incoming ping messages in LND's peer connection handler. Without these limits, a malicious or misconfigured peer could send a flood of ping messages, forcing the node to waste CPU, memory, and bandwidth processing them and sending pong replies. The fix counts every incoming ping and disconnects peers that exceed a flood threshold, while also limiting how often pong replies are sent. This is a defensive hardening change against a potential denial-of-service attack.

Security candidatepeer: test outgoing queue boundsby yyforyongyu · d65c97cf · Aug 19, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · yyforyongyu

peer: test outgoing queue bounds

Exercise prospective admission through the direct queue and public
sending API. Pin inclusive count and byte limits and preserve the
overflow cause across synchronous batches.

83/100 · StrongMessage clarity
✓ 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
access controlmemory safety
AI analysis · Informational 15/100

This commit only adds new unit tests for the outgoing message queue in LND's peer connection code. It does not change any production logic, fix a bug, or alter behavior that an attacker could exploit. The tests verify that queue size limits are enforced correctly.

Security candidateMerge pull request #11075 from ziggie1984/agent/fix-transaction-pagination-overflowby ziggieXXX · cfde18d9 · Aug 14, 2026 · 4 filesMessage 78 · AdequateLow 44Details
Commit message · ziggieXXX

Merge pull request #11075 from ziggie1984/agent/fix-transaction-pagination-overflow

lnwallet: prevent transaction pagination overflow

78/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
memory safetysigning or wallet pathmerge-commit duplicate discount
AI analysis · Low 44/100

This update fixes a crash bug in LND's transaction history viewer. When a user or program asked for transactions using very large offset and limit numbers, the old code could add those numbers together in a way that wrapped around to a tiny value, then try to slice a list with that bad value and panic. The new code checks the bounds safely before slicing, preventing the crash. It is a denial-of-service-style bug rather than a theft or remote-code-execution issue.

Security candidatelnwallet: prevent transaction pagination overflowby Ziggie · 62aeca57 · Aug 14, 2026 · 2 filesMessage 50 · ThinLow 40Details
Commit message · Ziggie

lnwallet: prevent transaction pagination overflow

50/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Names security-relevant behavior explicitly! No meaningful explanatory body
Why it was queued
memory safetysigning or wallet path
AI analysis · Low 40/100

This commit fixes a pagination bug in LND's wallet transaction listing. Previously, adding a user-controlled 'offset' and 'limit' together as 32-bit unsigned integers could wrap around to a tiny number, causing the code to slice transaction data using an unexpectedly small 'end' index and potentially return wrong results or behave inconsistently. The fix performs pagination using 64-bit arithmetic and compares the limit against the remaining items before deciding where to stop, preventing the overflow.

Security candidatedocs: update release notesby bitromortac · 9cfd5a66 · Aug 11, 2026 · 1 fileMessage 67 · AdequateInformational 15Details
Commit message · bitromortac

docs: update release notes

Add changes for the Merkle tree and BIP-340 signature work in bolt12.

67/100 · AdequateMessage clarity
✓ Descriptive subject✓ Uses a recognizable type or scope✓ Provides an explanatory body✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarydocumentation-only discount
AI analysis · Informational 15/100

This commit only updates the release notes document. It adds two bullet points describing earlier work on BOLT 12 Merkle trees and BIP-340 signatures, plus related test vectors. No code, logic, or configuration was changed, so it cannot introduce or fix a security issue by itself.

Security candidateMerge pull request #11023 from ellemouton/update-fee-logby Yong · 7f56541d · Aug 7, 2026 · 8 filesMessage 73 · AdequateModerate 59Details
Commit message · Yong

Merge pull request #11023 from ellemouton/update-fee-log

lnwallet+htlcswitch: align update_fee handling with BOLT 2

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
signing or wallet pathboot or update pathmerge-commit duplicate discount
AI analysis · Moderate 59/100

This commit hardens how LND handles Lightning channel fee updates and mailbox message admission. It enforces the protocol rule that only the channel opener can send fee updates, prevents uncommitted fee updates from piling up in the update log, limits how many queued messages a peer can stuff into a channel's mailbox, and makes the link disconnect if the mailbox is full so messages are not silently dropped. These changes reduce ways a misbehaving or buggy peer could disrupt a channel or waste resources.

Security candidatebolt12: add BIP-340 message signaturesby bitromortac · dfdcd507 · Aug 6, 2026 · 3 filesMessage 83 · StrongInformational 14Details
Commit message · bitromortac

bolt12: add BIP-340 message signatures

SignMessage and VerifySignature wrap btcec's Schnorr API around the
Merkle root with the spec's tagged-hash domain separator. Typed
helpers bind the construction to invoice requests and invoices, so
callers sign and verify messages rather than raw roots.

The signed vectors in signature-test.json verify the construction
against the spec, and a tamper matrix pins rejection of modified
roots, signatures, keys, and tags.

83/100 · StrongMessage clarity
✓ 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 · Informational 14/100

This commit adds new code for creating and checking digital signatures on BOLT 12 lightning invoices and invoice requests. It is a feature addition with extensive tests, not a fix for a known security bug. There is no evidence in the commit or supplied references that it addresses a vulnerability.

Security candidatecontractcourt: match second-level outputsby yyforyongyu · dd24c85c · Aug 6, 2026 · 2 filesMessage 73 · AdequateModerate 57Details
Commit message · yyforyongyu

contractcourt: match second-level outputs

A re-signed success transaction can move its committed output to another
index while preserving the HTLC input signature.

Match the indexed output against the sweep descriptor and return the
confirmed outpoint. Keep malformed resolver and notifier state distinct
from complete non-matches.

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

This commit adds logic to LND's contract court so that when an incoming HTLC is claimed on-chain via a re-signed success transaction, the resolver correctly identifies which output of that transaction it should sweep next. Previously, the code may have relied on a fixed output index; now it checks the actual output at the same index as the HTLC input and verifies it matches the expected sweep descriptor. The change is defensive and includes tests, but the commit message frames it as fixing a real correctness issue that could affect fund recovery.

Security candidateMerge pull request #11024 from ziggie1984/invoices-update-validationby ziggieXXX · 61f3b5a7 · Aug 5, 2026 · 4 filesMessage 58 · ThinModerate 63Details
Commit message · ziggieXXX

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

invoices: refine update handling

58/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
Why it was queued
boot or update pathmerge-commit duplicate discount
AI analysis · Moderate 63/100

This commit tightens how LND processes invoice payments, especially for newer multi-path (MPP) and AMP invoices, keysend payments, and replayed payments. It adds checks that ensure the right payment preimage is used for each invoice type and that AMP invoices cannot be processed through the older legacy path. The changes are defensive hardening rather than a single obvious exploit fix, but they close several paths where an attacker might trick LND into settling an invoice incorrectly or using the wrong secret.

Security candidateinvoices: refine update handlingby ziggie · 6be6350e · Aug 5, 2026 · 3 filesMessage 35 · OpaqueModerate 59Details
Commit message · ziggie

invoices: refine update handling

35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body! Opaque security-relevant change
Why it was queued
boot or update path
AI analysis · Moderate 59/100

This commit tightens how LND handles invoice payment updates, especially for newer 'AMP' invoices and old-style 'keysend' payments. It adds checks so that the wrong kind of payment cannot be processed against the wrong kind of invoice, and it verifies that stored payment secrets actually match the expected hash. The changes are defensive: they reject mismatched or malformed payments instead of allowing them to proceed. The commit does not say it fixes a known exploit, but the new checks close paths where a payment might have been accepted incorrectly.

Security candidatepeer+lnwallet/chancloser: advance the legacy closer from one goroutineby Olaoluwa Osuntokun · e5e134dd · Aug 4, 2026 · 4 filesMessage 88 · StrongModerate 60Details
Commit message · Olaoluwa Osuntokun

peer+lnwallet/chancloser: advance the legacy closer from one goroutine

In this commit, we give the legacy ChanCloser a single owner, rather than
letting two goroutines advance it. The peer's channelManager drives the state
machine for the Shutdown and ClosingSigned messages that come off the wire, and
for local close requests. The link drives it as well: while we wait for the
channel to drain we register a flush hook, and the link invokes that hook from
its own goroutine, where it called BeginNegotiation directly. Nothing kept the
two apart, so the state field, the priorFeeOffers map, and the signing step
could all be touched at once. Under `go test -race` this shows up as a data race
on the state field.

Rather than reach for a lock, we route the flush through the channelManager. The
hook now only reports the channel ID over a new chanCloseFlushed channel, and
handleChanFlushed picks it up next to the close messages. Every transition, the
cached offer processing, the fee map, and the signing then happen on the one
goroutine, so the closer needs no synchronization of its own. We spell that out
on the type, since it's an invariant a new caller can break from the outside.

The report goes out from a fresh goroutine, which matters more than it looks.
The link may well be holding its own lock while it invokes the hook, and
channelManager reaches for that same lock in DisableAdds, so blocking on the
handoff would trade the race for a deadlock. The `go` in front of RemoveLink
just above it is there for the same reason.

We look the closer up with a plain map load rather than through
fetchActiveChanCloser, as that one builds a fresh closer when it doesn't find
an existing one, and a flush that lands after the negotiation was torn down has
no business starting a new negotiation.

One behavior change falls out of the move: the flush path now runs the same
finalization tail as the message path. It skipped that before, so a responder
that drained a cached offer would reach closeFinished and broadcast, but nothing
ran finalizeChanClosure until the next close message showed up, and having
already sent its final signature, there may not be one. The link == nil path
already ran the tail, so this makes all three paths agree.

The new test drives a close with a link that hands us the flush hook instead of
running it inline, so we can check that negotiation waits on the report, and
that a report for a channel we have no closer for is dropped.

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 · Moderate 60/100

This commit fixes a concurrency bug in how LND negotiates cooperative channel closures. Previously, two different goroutines could update the same channel-closing state machine at the same time, which could corrupt internal data or cause a crash. The fix routes all updates through a single goroutine and adds a test to confirm the behavior.

Security candidatehtlcswitch: bound peer-controlled channel ingressby Elle Mouton · ef24f2c5 · Aug 4, 2026 · 4 filesMessage 68 · AdequateHigh 72Details
Commit message · Elle Mouton

htlcswitch: bound peer-controlled channel ingress

In this commit, we bound the channel mailbox by message count and by the
encoded size of non-commitment control messages. Commitment updates retain
their full custom-record allowance and remain protected by the count bound.
If either budget fills, we disconnect the peer instead of silently dropping
an ordered channel message.

We also reject unauthorized fee updates before fee-exposure evaluation,
return the exposure error used to fail the link, and emit peer-controlled
warning classes only once per link lifetime.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
boot or update path
AI analysis · High 72/100

This commit hardens LND's channel message handling against a peer that tries to overwhelm the node. It adds limits on how many ordered messages and how much data a peer can queue up for a channel, and it disconnects the peer if either limit is exceeded instead of silently dropping messages. It also fixes a protocol rule: only the channel initiator is allowed to send fee updates, so the node now rejects fee updates from the wrong side before doing any math on them. Finally, it reduces log spam by recording certain peer warnings and unknown messages only once per channel lifetime.