LL
← All projectsLightning Labs

LND

Go implementation of a complete Lightning Network node.

BitcoinLightning NetworkNormal
Repository coverage

1235 commits in the local evidence base

Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.

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

Does the history explain itself?

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

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

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Olaoluwa Osuntokun1994064274
Elle Mouton2673135067
ziggie4081523064
Erick Cestari26711070
bitromortac4656067
yyforyongyu5533065
saubyk1522070
Oli723057
Suheb322075
elnosh322071
George Tsagkarelis3214066
Gijs van Dam2611071
Analysis record

Published AI watches

Last scanned 47 minutes ago

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

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

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

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

invoices: refine update handling

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

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

bolt12: add InvoiceError onion message replies

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

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

bolt12: validate Invoice messages

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

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

bolt12: add Invoice struct and TLV codec

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

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

ci: split issue dedupe into find and post jobs

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

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

ci: split PR severity workflow into classify and apply jobs

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

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

github: bump gateway code-review to v0.5.0

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

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

lnwallet: use channel state open channel

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

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

funding: use channel state open channel

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

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

chanstate: use channel type in wallet rpc

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

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

chanstate: fix htlc copy

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

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

chanstate: remove store generics

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

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

channeldb: derive channel packagers

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

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

chanstate: make store channel types generic

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

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

lnwallet+walletrpc: add SubmitPackage for v3 CPFP package relay

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

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

lncli: add wallet submitpackage command

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

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

itest: add SubmitPackage integration test

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

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

bolt12: validate InvoiceRequest per BOLT 12 reader/writer requirements

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

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

bolt12: add InvoiceRequest message struct and TLV codec

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

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

Explore captured commits

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

Lower-prioritysample-conf: sync neutrino useragentversion with upstreamby ziggie · 037549d9 · May 12, 2026 · 1 fileMessage 73 · AdequateTriage 0Details
Commit message · ziggie

sample-conf: sync neutrino useragentversion with upstream

The neutrino bump updates the default UserAgentVersion from
"0.12.0-beta" to "0.16.2", which made the sample-conf check fail.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-prioritypayments/db: remap legacy zero attempt IDsby ziggie · c11a292e · May 12, 2026 · 3 filesMessage 68 · AdequateTriage 0Details
Commit message · ziggie

payments/db: remap legacy zero attempt IDs

Legacy KV payments can contain HTLC attempts with attempt ID zero. The
SQL payments schema requires payment_htlc_attempts.attempt_index to be
globally unique, so migrating multiple such attempts can fail with a
UNIQUE constraint violation.

Allocate synthetic attempt indexes for legacy zero-ID attempts from the
switch payment ID sequencer horizon. Keep nonzero attempt IDs unchanged
and advance the switch sequence once after migration validation succeeds.

This preserves the SQL uniqueness invariant and prevents future switch
IDs from colliding with migrated attempts. It also wraps HTLC insert
errors with the attempted index and payment hash so future migration
failures identify the problematic row.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI review queuedlnrpc: depend on chanstate Storeby ziggie · 186ea36f · May 12, 2026 · 4 filesMessage 68 · AdequateInformational 15Details
Commit message · ziggie

lnrpc: depend on chanstate Store

Replace concrete ChannelStateDB fields in the invoices and wallet RPC
configs with chanstate.Store, and update the subserver dependency
wiring to pass the interface. The affected RPC paths only need
channel-state store methods for hop hints and waiting-close channel
queries.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: broader security terminologysecond-pass: security-sensitive path
AI analysis · Informational 15/100

This is a small internal refactoring change. It swaps out a specific database type for a narrower interface in a few RPC configuration structs. There is no user-facing behavior change, no bug fix, and no security-relevant change visible in the diff.

Lower-priorityserver: depend on chanstate Storeby ziggie · 0376270e · May 12, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · ziggie

server: depend on chanstate Store

Store channel-state access on server as chanstate.Store instead of
*channeldb.ChannelStateDB. Keep link-node access as a separate concrete
*channeldb.LinkNodeDB field so LinkNodeDB does not leak into the
channel-state store contract.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-prioritylnd: use chanstate Store for channel restoreby ziggie · 2e7a1d8a · May 12, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · ziggie

lnd: use chanstate Store for channel restore

Make chanDBRestorer persist restored channel shells through
chanstate.Store instead of the concrete ChannelStateDB. The restorer
still builds channeldb channel shell values, but only needs
RestoreChannelShells from the store.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI review queuedcontractcourt: use chanstate Store in breach arbby ziggie · 8f10cf54 · May 11, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · ziggie

contractcourt: use chanstate Store in breach arb

Replace BreachConfig's concrete ChannelStateDB dependency with
chanstate.Store. The breach arbitrator only needs closed-channel reads
and MarkChanFullyClosed from the channel-state store.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
second-pass: broader security terminology
AI review queuedfunding: depend on chanstate Storeby ziggie · ae9de8d0 · May 11, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · ziggie

funding: depend on chanstate Store

Replace the funding manager's concrete *channeldb.ChannelStateDB
dependency with chanstate.Store. The manager only uses methods covered
by the store contract, including channel opening state and initial
forwarding policy persistence.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
second-pass: broader security terminology
AI review queuedpeer: depend on chanstate Storeby ziggie · d08b1b07 · May 11, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · ziggie

peer: depend on chanstate Store

Replace the peer config's concrete channel state DB dependency with
chanstate.Store. Brontide only needs channel lookups, closed-channel
lookup, and initial forwarding policy access from the channel-state
store.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
second-pass: broader security terminology
Lower-prioritychannelnotifier: depend on chanstate Storeby ziggie · 1f4a756f · May 11, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · ziggie

channelnotifier: depend on chanstate Store

Accept chanstate.Store in ChannelNotifier instead of the concrete
ChannelStateDB. The notifier only fetches open and closed channel
records to populate channel event payloads.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-prioritychanstate: introduce Store interfaceby ziggie · 96e0fd74 · May 11, 2026 · 3 filesMessage 58 · ThinTriage 0Details
Commit message · ziggie

chanstate: introduce Store interface

Add a new chanstate package containing the Store interface plus a
package logger. The interface mirrors the public surface of
*channeldb.ChannelStateDB so the compile-time assertion

var _ ChannelStore = (*channeldb.ChannelStateDB)(nil)

No consumer migrates in this commit.

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Lower-prioritychanneldb: drop unused kvdb.RTx parameter from FetchChannelByIDby ziggie · bb8eeb23 · May 11, 2026 · 4 filesMessage 73 · AdequateTriage 0Details
Commit message · ziggie

channeldb: drop unused kvdb.RTx parameter from FetchChannelByID

All four call sites pass nil for tx today (server.go, two in
channeldb/db_test.go, funding/manager_test.go). The internal
channelScanner(nil, selector) call inside FetchChannelByID is preserved
verbatim, so runtime behavior is unchanged.

This is a prerequisite for the upcoming chanstate.ChannelStore
interface: keeping the parameter would leak kvdb into a domain
interface.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-prioritydocs: release note for BOLT-02 push_msat fundee enforcementby Erick Cestari · bb8abc75 · May 11, 2026 · 1 fileMessage 85 · StrongTriage 0Details
Commit message · Erick Cestari

docs: release note for BOLT-02 push_msat fundee enforcement

Document the user-visible error string change introduced when the
fundee rejects incoming open_channel messages whose push_msat exceeds
1000 * funding_satoshis.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
documentation-only discount
AI review queuedfunding: enforce BOLT-02 push_msat bound on fundeeby Erick Cestari · d5505498 · May 11, 2026 · 3 filesMessage 73 · AdequateLow 45Details
Commit message · Erick Cestari

funding: enforce BOLT-02 push_msat bound on fundee

Reject incoming OpenChannel messages where push_msat exceeds
1000 * funding_satoshis, as required by BOLT-02. The existing RejectPush
flag only gates on push_msat > 0 and does not cover the spec bound.

An over-sized push is eventually caught downstream in reservation.go when
theirBalance = capacity - fee - push_msat goes negative and
ErrFunderBalanceDust is returned. Rejecting it up front produces a
clearer, spec-aligned error and avoids the chanacceptor and commitment
type negotiation round-trips for a channel we will refuse anyway.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 45/100

This commit tightens validation in LND when another node asks to open a Lightning channel. It now rejects requests where the proposed 'push' payment is larger than the entire channel funding, as the Lightning protocol (BOLT-02) already requires. Before this change, such oversized pushes were only caught later in the process, after extra setup work. The change is a defensive hardening fix, not an active exploit patch, and the commit message frames it as spec compliance rather than a security vulnerability.

Lower-prioritygraph/db: remove address loading from cached node iterationby Elle Mouton · bfb12b1d · May 7, 2026 · 10 filesMessage 73 · AdequateTriage 0Details
Commit message · Elle Mouton

graph/db: remove address loading from cached node iteration

ForEachNodeCached is now only used for topology-oriented traversal,
so the address-loading option forced one autopilot scoring path to
bypass the in-memory graph cache for data it did not consume. Remove
the withAddrs parameter and the associated SQL/KV address plumbing
so cached node iteration can consistently use the graph cache when
it is loaded.

Autopilot still requires peer addresses before opening channels.
That filtering remains in Agent.openChans via ForEachNode, where the
selected candidates' addresses are collected for ConnectToPeer. The
trade-off is that ForEachNodesChannels no longer excludes
addressless nodes from graph-wide scoring inputs such as median
channel size or centrality, which also feed lncli getnetworkinfo
statistics like graph diameter. In practice the only addressless
nodes our local view tends to know about are nodes with no public
channels (e.g. our own node or peers we share only private channels
with), so the impact on the reported stats should be negligible.
Active channel candidates remain address-filtered before dialing.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-prioritykvdb/sqlbase: fix non-constant format stringsby Alex Akselrod · ce65753d · May 6, 2026 · 1 fileMessage 80 · StrongTriage 0Details
Commit message · Alex Akselrod

kvdb/sqlbase: fix non-constant format strings

When updating the Go version in kvdb to >= 1.24, schema.go no
longer compiles due to non-constant format strings. This is
invisible until:
- a new version of kvdb is tagged and imported in consumers
- kvdb is redirected to the local copy

This commit fixes the bug.

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Lower-prioritydocs: release note for closed-channel tombstones on KV-SQL backendsby ziggie · 1a52e85b · May 4, 2026 · 1 fileMessage 93 · StrongTriage 0Details
Commit message · ziggie

docs: release note for closed-channel tombstones on KV-SQL backends

Document the tombstone close path that #10780 wires onto sqlite/postgres,
the operator-visible iteration-cost growth that comes from leaving closed
chanBuckets on disk, and the NumForwardingPackages divergence that the
preserved forwarding-package bucket produces in PendingChannels.

93/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
documentation-only discount
Lower-prioritymulti: enable closed-channel tombstones on KV-SQL backendsby ziggie · 95044124 · May 4, 2026 · 3 filesMessage 83 · StrongTriage 0Details
Commit message · ziggie

multi: enable closed-channel tombstones on KV-SQL backends

Wire OptionTombstoneClosedChannels for sqlite and postgres backends in
config_builder.go. bbolt keeps the synchronous one-shot close path
unchanged.

Add UsesClosedChanTombstones() to the integration test harness so
backend-symmetric tests can skip post-close assertions about deleted
forwarding-package or revocation-log state — that state is intentionally
preserved on tombstone backends until the upcoming native-SQL
channel-state migration reclaims it. Update testWipeForwardingPackages
to honor the new predicate while still exercising the close flow on
both backend families.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Lower-prioritychanneldb: tombstone closed channels without bulk deleteby ziggie · d643050d · May 4, 2026 · 2 filesMessage 83 · StrongTriage 5Details
Commit message · ziggie

channeldb: tombstone closed channels without bulk delete

Wire the tombstone close path on backends that opted in via
OptionTombstoneClosedChannels:

- ChannelStateDB.CloseChannel branches on tombstoneClosedChannels.
The default path remains closeChannelSync; closeChannelTombstone
runs on tombstone-enabled backends.
- closeChannelTombstone leaves every byte of the channel's nested
state in place — chanBucket, revocation log, per-channel
forwarding-package bucket, commitment heads — and relies on the
outpointBucket flip from outpointOpen to outpointClosed (already
performed by the shared updateClosedOutpointIndex helper) as the
authoritative closed-channel marker. The historical-channel and
close-summary archival use the same archiveClosedChannel helper as
the synchronous path so closed-channel and historical readers see
uniform records regardless of backend.
- locateOpenChannel rejects already-closed chanKeys (outpointClosed
in the index) with ErrChannelNotFound so a redundant CloseChannel
is a no-op rather than a re-archive.

Open-channel-bucket readers still surface tombstoned channels — that
audit lands in the next commit. The tests added here only assert the
writer's on-disk artefacts and the redundant-close guard.

Tests:
- TestCloseChannelTombstoneWritePath: outpoint flipped, historical
record, close summary, revlog/fwd-pkgs preserved.
- TestCloseChannelTombstoneRedundantClose: second CloseChannel
returns ErrChannelNotFound.
- TestCloseChannelSync: regression test for the synchronous path —
chanBucket and fwd-pkgs gone, outpoint flipped.

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 evidence
Lower-prioritychanneldb: hide tombstoned channels from open viewsby ziggie · dc4b8514 · May 4, 2026 · 3 filesMessage 95 · StrongTriage 0Details
Commit message · ziggie

channeldb: hide tombstoned channels from open views

Wire every reader of openChannelBucket to consult isOutpointClosed
before treating a chanKey as open. Without this commit the previous one
flips the outpoint index but FetchAllChannels and friends still surface
the channel as if it were open — that intermediate state is fine for
tests because OptionTombstoneClosedChannels stays off until the multi:
commit flips it on for sqlite/postgres, but the readers must be wired
before that lands.

Audit covers all six call sites that descend into chanBucket:

- fetchChanBucket / fetchChanBucketRw — direct lookup paths used by
Refresh, MarkBorked, and the rest of OpenChannel's read/write
methods. Single-call sites; the tx.ReadBucket(outpointBucket)
lookup is inlined into the isOutpointClosed call.
- fetchNodeChannels — per-node ForEach iteration; tx threaded
through and the outpoint-bucket lookup is hoisted above the loop
so the closed-channel check is a per-iteration map probe rather
than a tx-level bucket resolve.
- FetchPermAndTempPeers — cross-node ForEach; same hoisting pattern.
The closed peer's protected status is still established by the
historical-channel second pass that runs after the open-channel
pass.
- channelScanner — single-channel-selector iteration site reached by
FetchChannel and FetchChannelByID; outpoint-bucket lookup hoisted
inside chanScan so a single visit pays the bucket-resolve cost
once.

The redundant-close guard added in the previous commit lives in
locateOpenChannel and is unchanged here.

Tests:
- TestCloseChannelTombstoneRemovesFromOpenScans: end-to-end —
FetchAllChannels, FetchOpenChannels, and FetchPermAndTempPeers all
behave as if the closed channel is gone, while the historical pass
still marks the peer as having a closed channel.
- TestClosedChannelHiddenFromFetchChannel: channelScanner path.
- TestClosedChannelHiddenFromDirectMethods: fetchChanBucket /
fetchChanBucketRw via Refresh and MarkBorked.

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
Lower-prioritychanneldb: add tombstone option and isOutpointClosed helperby ziggie · f94fba1e · May 4, 2026 · 3 filesMessage 73 · AdequateTriage 0Details
Commit message · ziggie

channeldb: add tombstone option and isOutpointClosed helper

Add the option, field, and reader helper that the tombstone close path
will consume in the next commit. Nothing is wired yet:

- OptionTombstoneClosedChannels — option modifier that sets the new
Options.tombstoneClosedChannels field. Defaults to off.
- ChannelStateDB.tombstoneClosedChannels — the decision-bit, set at
construction from the option.
- isOutpointClosed(opBucket, chanKey) — decodes the indexStatus TLV
stored under outpointBucket and reports true for entries flipped to
outpointClosed by updateClosedOutpointIndex (called from both close
paths). The helper accepts the bucket directly so loop-style
callers can hoist the tx.ReadBucket(outpointBucket) lookup out of
the inner loop and pay it once per iteration set.

Reusing outpointBucket as the "logically closed" signal avoids a
dedicated tombstone bucket. The flip from outpointOpen to outpointClosed
is already performed by the existing close path, so the signal exists on
both backends — readers just need to consult it.

Behavior is unchanged. The option and helper have no callers yet; the
close-path branch and reader audit land in the next two commits.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-prioritychanneldb: extract close-channel helpersby ziggie · 4815ed2b · Apr 30, 2026 · 1 fileMessage 68 · AdequateTriage 0Details
Commit message · ziggie

channeldb: extract close-channel helpers

Move the body of OpenChannel.CloseChannel into ChannelStateDB.CloseChannel
(which dispatches to a new closeChannelSync method), and split the close
logic into three free helpers:

- locateOpenChannel: descends the open-channel bucket tree and returns the
chain bucket, channel bucket, and serialized chanKey for an OpenChannel.
- updateClosedOutpointIndex: flips the outpoint index entry for a chanKey
from open to closed.
- archiveClosedChannel: writes the historical-channel record and the close
summary that survive the close.

Behavior is preserved: closeChannelSync runs the same sequence of mutations
(packager wipe, chanBucket delete, log-bucket delete, outpoint flip,
historical archive, close summary) that the inline body did, just composed
out of the new helpers. No callers, options, or readers change.

This is preparation for adding a tombstone close strategy on KV-SQL
backends; the helpers will be shared between the synchronous and tombstone
paths so historical and closed-channel records remain identical across
backends.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityonionmessage: add BFS pathfinding for onion messagesby Abdullahi Yunus · fd25ba98 · Apr 29, 2026 · 3 filesMessage 95 · StrongTriage 0Details
Commit message · Abdullahi Yunus

onionmessage: add BFS pathfinding for onion messages

In this commit we add FindPath, a BFS-based shsortest-path
algorithm that finds routes through the channel graph for
onion messages. The search filters nodes by the
OnionMessage feature bits (38/39).

We also add a unit tests covering: direct neighbor routing,
multi-hop paths, feature-bit filtering, missing destination
nodes, destination without onion support, max hop limits,
cycle handling, and shortest-path selection.
choice of BFS is because there isn't any weight involve.

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
Lower-prioritydocs: add release not for pathfindingby Abdullahi Yunus · 72873f62 · Apr 29, 2026 · 1 fileMessage 57 · ThinTriage 0Details
Commit message · Abdullahi Yunus

docs: add release not for pathfinding

57/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
documentation-only discount
Lower-prioritydocs: fix Contributors TOC anchor in v0.21.0 release notesby ziggie · c0b417c7 · Apr 28, 2026 · 1 fileMessage 85 · StrongTriage 0Details
Commit message · ziggie

docs: fix Contributors TOC anchor in v0.21.0 release notes

The TOC link for the Contributors section pointed to `#contributors`,
but GitHub generates the anchor for `# Contributors (Alphabetical
Order)` as `#contributors-alphabetical-order`, leaving the link
broken when the rendered file is viewed on GitHub. Update the TOC
to use the working anchor (matching the form already used in
release-notes-0.18.0.md).

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
documentation-only discount
Lower-prioritydocs: add empty release notes for v0.22.0by ziggie · fa588eaf · Apr 28, 2026 · 1 fileMessage 80 · StrongTriage 0Details
Commit message · ziggie

docs: add empty release notes for v0.22.0

Scaffold release-notes-0.22.0.md with the same section structure as
the 0.21.0 file so contributors have a place to land entries during
the v0.22 cycle.

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
documentation-only discount