LND

This commit only adds new benchmark test files for measuring how fast the code can list currently unfinished Lightning payments from the database. It does not change any production code, user-facing behavior, or security-sensitive logic. There is nothing here that could be exploited or that weakens security.

This commit only updates the release notes document for version 0.22.0. It adds a new section heading for BOLT 12 (Offers), describes a recently merged feature that adds code for encoding and decoding BOLT 12 offers, and adds a contributor name. No program code is changed, so there is no direct security impact from this commit itself.

This commit adds input validation to BOLT 12 offers in the LND Lightning node. BOLT 12 offers are payment requests that one node can present to another. Before this change, LND could accept or re-encode malformed offers that violated the protocol rules, such as offers with no usable payment path, expired offers, invalid currency codes, or hidden unknown required fields. The new code rejects these on both reading and writing, which helps prevent nodes from acting on bad offers or producing invalid ones.

This commit adds two small helper functions for working with optional data fields in Lightning Network messages. It is purely additive and contains no security fix or behavior change to existing code. There is no indication it addresses a vulnerability.

This commit adds a new, self-contained code module for encoding and decoding 'blinded paths' used in the Lightning Network protocol. It does not change any existing code paths or callers. The new code is designed defensively: it rejects malformed input, limits memory allocations, and validates cryptographic points before use. There is no indication this commit fixes a known vulnerability or introduces one.

This commit adds a new data type for handling lists of blockchain identifiers in BOLT 12 offers and invoices. The main security-relevant detail is that the decoder now limits how many chain hashes can be requested at once, preventing a malformed message from tricking the software into allocating excessive memory. It is a defensive, forward-looking change rather than a fix for an active bug.

This commit adds new code for encoding and decoding BOLT 12 'offers' in the LND Lightning node. It is a feature-introduction commit with no bug fix or security patch. There is no direct evidence in the commit or supplied references that this change fixes a vulnerability or introduces one.

This commit fixes how LND reads the 'reply path' inside onion messages. Previously, the code only accepted reply paths whose first hop was a full 33-byte public key, and silently ignored a valid shorter format allowed by the Lightning spec (a 9-byte short-channel-id plus direction). The change switches to a shared lnwire.BlindedPath type that correctly handles both formats, so onion messages with the shorter reply-path form are no longer dropped or mishandled.

This commit is a code cleanup and generalization in LND's TLV (Type-Length-Value) message handling. It introduces flexible helper functions so that future protocols like BOLT 12 can define which message fields are covered by a digital signature, instead of hardcoding only the BOLT 7 v2 rules. The existing behavior is preserved by default. There is no direct security fix or vulnerability patch in this change.

This is a routine Go module version bump in a build configuration file (go.mod). It changes the declared dependency version for an internal sub-module so that downstream projects compiling against lnd fetch a matching tagged release. The commit explicitly states there is no behavioral change in lnd itself, because a local replace directive still forces lnd to use its own in-tree copy of the code. There is no indication of a security fix or vulnerability.

This commit only changes a dependency version label in LND's package manifest. The underlying code (commit 70a94ea39e9c) stays exactly the same; the dependency is simply tagged as v0.16.18 instead of being referenced by a pseudo-version. There is no functional or security change visible in this commit.

This commit updates a dependency version in LND's build files. It bumps the internal 'kvdb' submodule from version 1.5.0 to 1.5.1 so that downstream projects importing kvdb directly do not pull in an older, vulnerable telemetry library (OpenTelemetry SDK). The commit message says the main LND module already uses the newer versions, so this change is mostly a relabel for consumers of the kvdb submodule and has no direct code change in LND itself.

This commit is a routine dependency housekeeping change. It swaps two internal LND submodules (queue and kvdb) from being loaded from local folders to being loaded from their newly published version tags. The commit message explicitly states the tagged versions contain the exact same code as the local copies, so nothing in the built program changes. There is no security fix or vulnerability patch here.

This commit updates the OpenTelemetry (OTel) software library used by the Lightning Network Daemon (LND) from a version with a known security flaw to a fixed version. It is a dependency-only change affecting build files, not LND's own code. The commit message explicitly says it fixes GO-2026-4394, a published vulnerability database entry, but the exact attack details are not shown in the diff itself.

This commit updates dependency versions inside a small sub-module (kvdb) of the Lightning Network Daemon (LND) project. The main change is raising the minimum version of the gRPC networking library and several related packages. It does not change any application code, only the list of external libraries used. The commit message does not say it fixes a security bug, and no security advisory was supplied. It is best treated as a routine maintenance update that may incidentally include bug fixes from newer dependency versions.

This commit rewrites a database query that lists unfinished Lightning payments. The old query first built a temporary list of all matching payment IDs, which could become huge and consume excessive memory or CPU. The new query checks the same conditions directly while scanning payments in small paginated chunks, avoiding that large intermediate result. It is a performance and robustness improvement rather than a fix for a clear security vulnerability.

This commit only updates a documentation file describing how maintainers should create release tags. It replaces manual git tag commands with references to a helper script. There is no code change, no bug fix, and no security issue in the commit itself.

This commit only updates a documentation file (docs/db_migration_guide.md). It refreshes the roadmap table, a flowchart, and guidance text to reflect that the payments relational backend is now available in v0.21 and that btcwallet/channel state work is targeted for v0.22. No code, configuration, or cryptographic behavior changed.

This commit updates the Go compiler/toolchain version used to build the LND Lightning node from Go 1.25.5 to Go 1.26.3, and bumps the minimum Go language version declared in module files from 1.25.5 to 1.25.10. It also swaps one Windows release target from 32-bit ARM to 64-bit ARM. There is no code change to LND itself. The main security relevance is that newer Go patch releases typically fix bugs and security vulnerabilities in the Go runtime and standard library, so staying current is good defensive hygiene. However, the commit message does not say this is a security fix, and no specific vulnerability is named.

This commit adds a new automated security scanner to the project's continuous integration pipeline. It does not change any actual LND code, fix a bug, or patch a vulnerability. Instead, it introduces a weekly GitHub Actions workflow that builds the lnd and lncli release binaries and runs Google's govulncheck tool against them to detect known vulnerable Go dependencies. Findings are currently treated as warnings only (exit code 3 is advisory) while the team works through any existing baseline issues.

This change tightens a release safety check. Previously, the automated release pipeline skipped a version comparison between the Git tag and the software's internal version number, so a release could accidentally be built and published with mismatched version labels. Now the check runs normally, preventing that mismatch. It is a supply-chain/process fix, not a fix for an exploitable code bug in running LND nodes.

This commit only updates user-facing documentation. It replaces hardcoded block heights with a new 'latest' shortcut URL for a third-party header-import service and removes an outdated warning about a broken testnet3 file. No code was changed, and there is no security issue in the commit itself.

This commit adds a new internal helper script for LND maintainers to safely create release tags. It does not change any production code, network behavior, or wallet logic. The script only adds checks to prevent human release-process mistakes, such as tagging the wrong commit or a version that does not match the source code. There is no security vulnerability here.

This commit simply updates the project's dependency on the gRPC networking library from version 1.79.1 to 1.79.3. It changes three files: the main module definition, the checksum file, and a CI workflow that pins this dependency. The commit message does not say why the update is needed, and no security advisory or researcher credit is included in the materials provided. Patch-level version bumps in dependencies often include bug or security fixes, but we cannot confirm that from the diff alone.

This commit only adds documentation to the 0.21.0 release notes. It describes how LND now rejects old-style Tor v2 onion addresses at configuration and command boundaries, filters them from several internal persisted-state paths, and preserves wire-faithful handling of peer-signed v2 announcements. There is no code change in this commit, so it does not itself fix or introduce a vulnerability.