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.
Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
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
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
This commit only updates the release notes document for version 0.21.2. It adds a bullet point describing a previously merged code change about invoice handling and adds a contributor name to the credits list. No actual code was changed, s…
This commit only moves an existing release-note entry from one version's notes (v0.22.0) to another (v0.21.2). It does not change any code, build files, configuration, or tests. The change is purely editorial documentation bookkeeping.
This change fixes a way a malicious or buggy peer could make an LND node use an unpredictable amount of memory while syncing the Lightning channel graph. Before the fix, the node only limited the size of one compressed reply message, but a…
Resource exhaustion / unbounded memory growth in gossip syncRemote peer can influence memory allocation via ReplyChannelRange streamMissing aggregate limit on decoded working set
This commit updates the release notes for LND 0.21.2 to describe a fix for a bug in the HTLC interceptor RPC. The bug caused LND to fail to forward payments in blinded routes when the next hop was identified by node ID instead of channel I…
Blinded route forwarding failure could disrupt payment routing or be used to probe path structure.Sentinel value change in RPC API could cause client misclassification of forwards if not handled.Release notes describe the change as a fix for a forwarding issue, not as a security vulnerability.
This commit only adds new integration tests for an existing feature in LND: forwarding blinded payments where the next hop is identified by node ID rather than channel ID. It does not change production code, fix a bug, or introduce any new…
This change fixes a reporting gap in LND's 'witness beacon,' a component that watches on-chain transactions and tells the HTLC interceptor where a payment should go next. Previously, when the next hop was identified by a node ID rather tha…
Missing security-critical metadata in on-chain interception pathBehavioral parity between on-chain and off-chain HTLC interceptionPotential misclassification of node-ID forwards as final receives
This commit fixes a bug in LND's payment forwarding for 'blinded routes'—a privacy feature in the Lightning Network. Previously, if the next hop was identified by node ID rather than a specific channel ID, the payment could not be forwarde…
Fixes a functional forwarding failure for blinded-route payments using node-ID next hops (issue #10937).Prevents private channel SCID leakage in failure messages for node-ID blinded hops by returning FailUnknownNextPeer instead of a channel_update.Adds circular-route filtering for node-ID next hops before non-strict forwarding selection.
This change improves how the Lightning Network Daemon (LND) reports forwarding details to external plugins that inspect HTLCs (payment packets). For a new type of blinded route where the next hop is identified by node ID rather than a spec…
Information-correctness fix for HTLC interceptor APIPrevents misclassification of node-ID forwards as exit hopsAdds explicit sentinel to disambiguate zero SCID semantics
This commit fixes a bookkeeping bug in LND's HTLC event stream. When a payment is forwarded to a 'blinded' next hop identified only by a node public key (not a channel ID), and it fails before the switch picks an outgoing channel, the even…
Event misclassification in HTLC event stream (forward reported as receive)Blinded/node-ID forwarding path introduced prior to this fixFailure and resolution packets dropped next-hop metadata before fix
This commit adds support in LND for a different way of identifying the next hop in a private ('blinded') Lightning payment route. Previously LND expected the next hop to be identified by a channel ID; now it also accepts the next node's pu…
New validation enforces BOLT 4 mutual exclusivity of short_channel_id and next_node_id in blinded route dataPreviously ambiguous or unhandled next_node_id forwarding case now explicitly decodedNo memory-safety, cryptographic, or authorization changes observed
This commit tightens a safety limit in LND's Lightning wire protocol parser. Previously, a compressed network message could decompress into an unbounded number of short channel IDs, potentially consuming far more memory than the wire messa…
Resource-limit bypass: compressed-input bound did not bound decoded outputMemory-exhaustion risk from zlib decompression of peer-supplied dataTruncated/corrupt zlib streams previously accepted as valid partial results
This commit only updates the API definition and auto-generated code for LND's HTLC interceptor. It adds a new optional field, outgoing_requested_node_id, and documents that when a blinded route uses a node ID instead of a channel ID, the e…
No runtime logic changed; only protobuf schema and generated stubsNew field is explicitly documented as unpopulated until later commitsSentinel value (MaxUint64) introduced to prevent misclassification of final receive vs node-addressed forward
This commit is a behind-the-scenes code cleanup in the LND Lightning node. It changes how the 'next hop' for forwarding payments is stored internally so that, in the future, blinded routes can identify the next hop by a node's public key i…
Refactor of core HTLC forwarding data structure (ForwardingInfo.NextHop)Preparation for blinded route next-hop identification by node public keyEncapsulation of Either type behind IsExit() and NextHopChannel() to centralize exit-hop detection
This commit fixes a routing bug in LND's Lightning payment forwarding. When a payment could take any of several parallel channels to the same next peer, the node was accidentally asking an optional 'auxiliary traffic shaper' about the chan…
Logic error: wrong channel identifier used for auxiliary policy/bandwidth checkPotential information disclosure: real SCID could leak if passed to shaper-driven wire messages; commit explicitly prevents thisParallel-channel forwarding correctness issue
This commit updates a GitHub Actions workflow that runs an optional code-review bot called 'gateway'. It only changes two pinned version numbers (SHA hashes) for the bot's action and its runtime, moving from v0.5.0 to v0.6.0. There is no c…
This patch fixes a database migration bug in LND's channel database. Some databases were created without recording their schema version number, which could cause future mandatory upgrades to be skipped. The fix detects that missing version…
Database schema version key can be absent due to an init-ordering regressionMissing version key previously caused migration selection to treat DB as latest, potentially skipping mandatory migrationsFix recovers baseline from last mandatory version before the regression (33)
This commit fixes a database migration in LND so it can safely run twice. Previously, if a certain recovery process re-ran migration 35 on a database that already had newer-format 'waiting proof' records, the migration would likely fail or…
Database migration idempotency/robustness fixPotential data corruption or node startup failure if migration re-run against mixed-format bucketNo input validation of attacker-controlled data; issue is local/state-recovery only
This commit fixes a database initialization bug in LND's channel database. Previously, creating an empty metadata bucket during setup could trick the code into thinking an old or partially-created database was already fully up-to-date, pot…
Database version detection logic flawPotential migration skip due to incorrect initialized-state detectionNew explicit error for missing DB version key
sqldb: fix error comparison and refactor sqlite bench helpers
Replace direct `err != sql.ErrNoRows` comparison with `errors.Is` and extract the repeated fetch-and-check logic into a helper to reduce duplication across the sequential and concurrent benchmarks.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
✓ Subject identifies a change✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
documentation-only discount
Lower-prioritysqldb: scope DeleteFailedAttempts query to payment's own attemptsby ziggie · c5866b97 · Mar 12, 2026 · 3 filesMessage 73 · AdequateTriage 0Details
Commit message · ziggie
sqldb: scope DeleteFailedAttempts query to payment's own attempts
The previous query used an IN subquery that scanned all failed resolutions across all payments (O(N) where N = total failed attempts globally). Replace with a correlated EXISTS subquery that only checks resolutions for the specific payment's attempts, making it O(k) where k = attempts for this payment (typically 1-5).
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Add a new omit_hops field to ListPaymentsRequest that allows clients to skip loading hop-level route data for HTLC attempts, reducing both query cost and response size. When set, the route is returned with only route-level fields (TotalTimeLock, TotalAmount, SourcePubKey) and no individual hop data or hop-level custom records.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-prioritydocs: add removal notice of deprecated hop rpc elementsby ziggie · 3e619318 · Mar 12, 2026 · 1 fileMessage 85 · StrongTriage 0Details
Commit message · ziggie
docs: add removal notice of deprecated hop rpc elements
The previous commit stopped setting the channel capacity when retrieving the route. This commit makes sure that in the next release we remove the entries from the rpc interface.
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-priorityrouterrpc: dont query for the channel capacityby ziggie · 21fa0710 · Mar 12, 2026 · 2 filesMessage 80 · StrongTriage 0Details
Commit message · ziggie
routerrpc: dont query for the channel capacity
During route retrieval don't query for the channel capacity. We default to the static incomingAmt of the route. That was already done previously when the channel was closed or private. The channel capacity has been deprecated for quite a while so it is acceptable to avoid the performance hit querying the graph db.
In the next release this field will be removed.
80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Lower-prioritysqldb: optimise payment index layout in new migration 13by ziggie · 3e7dfff0 · Mar 12, 2026 · 3 filesMessage 73 · AdequateTriage 0Details
Commit message · ziggie
sqldb: optimise payment index layout in new migration 13
Since migration 10 is already merged into master it cannot be edited. Add a new migration (000013_payments_index_improvements) that carries forward two index improvements:
- Drop idx_htlc_attempt_index on payment_htlc_attempts(attempt_index) and idx_route_hops_htlc_attempt_index on payment_route_hops(htlc_attempt_index). Both are redundant with existing UNIQUE constraints and only add write/maintenance overhead.
- Add idx_htlc_payment_id_attempt_time on payment_htlc_attempts(payment_id, attempt_time) to optimise batched attempt reads that filter by payment_id and order by attempt_time (FetchHtlcAttemptsForPayments).
- Add idx_htlc_resolutions_type_attempt_index on payment_htlc_attempt_resolutions(resolution_type, attempt_index) to optimise the failed-attempt cleanup path that filters by resolution_type before joining on attempt_index (DeleteFailedAttempts).
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The invoice tombstone acts as a system wide kv db tombstone so there is no need for a specific payment tombstone. Moreover a TODO is added to redesign the current setting of the invoice tombstone because it is also fragile to crashes after the tombstone is set and the sql transaction of the migration fails to commit.
Additionally the missing cleanup calls are added in case we return early because of an error.
input: add template vs builder byte-for-byte equivalence tests
Add regression tests that compare every ScriptTemplate-based function against the original ScriptBuilder implementations extracted from git history. This ensures the template migration produces identical script bytes for all 22 script types (segwit v0 + taproot).
The legacy builder functions are kept as private test helpers in script_utils_legacy_test.go, extracted verbatim from the pre-template commit.
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
AI analysis · Informational 15/100
This commit only adds new test code. It does not change any production code. The tests compare newly added 'ScriptTemplate' functions against older 'ScriptBuilder' versions to make sure they produce identical Bitcoin scripts byte-for-byte. It is a regression-test addition, not a security fix or vulnerability.
Lower-priorityinput: use template to unify taproot "prod script" definitionby Olaoluwa Osuntokun · 833f17fe · Mar 12, 2026 · 1 fileMessage 50 · ThinTriage 0Details
Commit message · Olaoluwa Osuntokun
input: use template to unify taproot "prod script" definition
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Lower-priorityinput: add cut out for final taproot scripts from specby Olaoluwa Osuntokun · 50639114 · Mar 12, 2026 · 1 fileMessage 73 · AdequateTriage 0Details
Commit message · Olaoluwa Osuntokun
input: add cut out for final taproot scripts from spec
In this commit, we add an initial cut out to allow us to swap in the taproot scripts (which changed slightly) once we start using the final "production" feature bit.
The changes to the scripts are pretty mechanic: we avoid using `OP_DROP` and instead use a `_VERIFY` earlier in the script to consume the stack item.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Lower-priorityinput: switch to using new txscript.ScriptTemplate functionby Olaoluwa Osuntokun · f26ad679 · Mar 11, 2026 · 2 filesMessage 73 · AdequateTriage 0Details
Commit message · Olaoluwa Osuntokun
input: switch to using new txscript.ScriptTemplate function
In this commit, we switch to using the new txscript.ScriptTemplate function. This allows us to write the script in plain text, using some hidden template operations to swap in items like keys or sigs.
This reduces in less code and boiler plate over all, the code that defines the script now reads as if it was a comment.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI review queuedci: update pinned grpc dependency to v1.79.1by Olaoluwa Osuntokun · 54688752 · Mar 10, 2026 · 1 fileMessage 80 · StrongInformational 15Details
Commit message · Olaoluwa Osuntokun
ci: update pinned grpc dependency to v1.79.1
In this commit, we update the CI workflow pinned dependency check for google.golang.org/grpc from v1.59.0 to v1.79.1. While btcwallet only requires v1.73.0, we upgrade to the latest stable release for bug fixes and improvements.
80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
This commit changes a single line in a GitHub CI workflow file, bumping the pinned version of a Google gRPC library used during automated testing from v1.59.0 to v1.79.1. It does not modify any application code, cryptographic logic, network handling, or user-facing behavior. There is no indication in the commit that this fixes a known security vulnerability.
AI review queuedlnrpc: regenerate protobuf definitions for grpc v1.79.1by Olaoluwa Osuntokun · 07f2d1aa · Mar 10, 2026 · 17 filesMessage 73 · AdequateInformational 15Details
Commit message · Olaoluwa Osuntokun
lnrpc: regenerate protobuf definitions for grpc v1.79.1
In this commit, we regenerate all protobuf Go stubs to match the updated grpc and protobuf library versions. This is a mechanical change with no functional differences; the generated code simply uses the newer protobuf runtime APIs.
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 · Informational 15/100
This commit is a routine, mechanical update of automatically generated protobuf Go code to match newer versions of the protobuf and gRPC libraries. The commit message explicitly states there are no functional differences. The visible changes are only in generated boilerplate: field ordering, removal of the `protoimpl.UnsafeEnabled` guard, use of the `unsafe` package for string-to-byte conversions of descriptor data, and newer protoc-gen-go version comments. No application logic, RPC definitions, or security behavior changed.
AI review queuedmod: bump google.golang.org/grpc to v1.79.1by Olaoluwa Osuntokun · ae286f27 · Mar 10, 2026 · 2 filesMessage 68 · AdequateLow 34Details
Commit message · Olaoluwa Osuntokun
mod: bump google.golang.org/grpc to v1.79.1
In this commit, we bump the grpc dependency from the v1.73.0 version (pulled in transitively by btcwallet) to v1.79.1 which is the latest release and includes several bug fixes. This also bumps a number of related transitive deps including google.golang.org/protobuf to v1.36.10 and several golang.org/x packages.
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 analysis · Low 34/100
This commit updates several software building blocks (dependencies) used by the Lightning Network Daemon (LND), most notably the gRPC networking library from version 1.73.0 to 1.79.1, plus related Google and Go standard-library packages. The commit message says the new versions include bug fixes, but does not say any of those bugs are security issues. Because the diff only shows version number changes and no code changes, we cannot confirm from this commit alone that a specific vulnerability is being fixed. It is best treated as a routine maintenance update that may incidentally close known bugs in upstream libraries.
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.
Lower-prioritychore: fix linter issues in brontide.goby Gijs van Dam · e8074935 · Mar 9, 2026 · 1 fileMessage 80 · StrongTriage 0Details
Commit message · Gijs van Dam
chore: fix linter issues in brontide.go
Post merge of #10089, a linter issues was introduced in `brontide.go`. This commit fixes that issue.
80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
docs: add release notes for GetDebugInfo include_log flag
62/100 · AdequateMessage clarity
✓ Specific, 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-prioritycmd/commands: add --include_log flag to getdebuginfo CLIby saubyk · 94bb6650 · Mar 7, 2026 · 1 fileMessage 73 · AdequateTriage 0Details
Commit message · saubyk
cmd/commands: add --include_log flag to getdebuginfo CLI
Add an --include_log boolean flag to the getdebuginfo and encryptdebugpackage commands. When set, the log file content is included in the response. The encryptdebugpackage command description is updated to reflect the new default behavior.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityrpcserver: skip log reading when include_log flag is not setby saubyk · 0e80b24c · Mar 7, 2026 · 1 fileMessage 73 · AdequateTriage 0Details
Commit message · saubyk
rpcserver: skip log reading when include_log flag is not set
By default, GetDebugInfo now returns only the configuration map. The log file is only read and included when the include_log flag is set to true, avoiding the cost of reading large log files when only config data is needed.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-prioritylnrpc: add include_log field to GetDebugInfoRequestby saubyk · f0e22873 · Mar 7, 2026 · 4 filesMessage 73 · AdequateTriage 0Details
Commit message · saubyk
lnrpc: add include_log field to GetDebugInfoRequest
Add an `include_log` bool field to GetDebugInfoRequest proto message. When set to true, the server will include the log file content in the response in addition to the configuration map.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
✓ Subject identifies a change✓ Uses a recognizable type or scope! No meaningful explanatory body
Lower-priorityscripts/bw-compat: use docker logs for log collectionby ziggie · 2b4dc4ea · Mar 5, 2026 · 1 fileMessage 73 · AdequateTriage 0Details
Commit message · ziggie
scripts/bw-compat: use docker logs for log collection
Switch collect_logs from docker cp to docker logs to reliably capture container output. The previous approach used docker cp to copy lnd log files from inside named volumes, which silently fails in CI — the directory gets created and the success echo prints, but no files are ever copied, causing upload-artifact to report "No files were found".
docker logs reads directly from Docker's captured stdout/stderr buffer, bypassing the volume entirely, and works as long as the container exists.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context