LND

This commit adds new RPC endpoints to LND that allow users to send and receive 'onion messages'—a type of privacy-preserving Lightning network message. The change is a feature addition, not a bug fix. There is no indication in the commit or supplied references that this resolves a security vulnerability or was disclosed as a security issue.

This change fixes a minor responsiveness bug in LND's 'SendCustomMessage' RPC. Previously, if a caller cancelled the request, the server would still keep waiting until the peer became active, disconnected, or the whole server shut down. Now the cancellation signal is passed through and the call returns immediately when cancelled. It is a cleanup/quality improvement rather than a clear security vulnerability.

This is a routine code cleanup in the LND Lightning Network daemon. It removes unused helper methods and outdated comments from the internal graph database node model, and updates callers to use direct field assignments instead. There is no security-relevant change.

This commit adds a new gRPC API endpoint called SendOnionMessage to the LND Lightning node, along with a matching subscription stream for incoming onion messages. It only changes the protocol definition and generated code; it does not include the actual server-side implementation that would process these messages. Because the implementation is missing, the change by itself does not create or fix a security vulnerability, but it does expose a new network-facing capability that will need careful review once the backend logic lands.

This commit is a straightforward code organization change. It adds a GossipVersion() method to several existing Lightning network gossip message types and updates their interfaces to require it. There is no bug fix, behavior change, or security patch visible in the diff.

This change fixes how LND's gossip message handler keeps track of recently rejected messages. Previously, the reject cache only used the sender's public key and channel ID as its lookup key. Because Lightning now has two separate gossip protocols (versions 1 and 2), a rejection on one protocol could incorrectly block or affect the same message on the other protocol. The patch adds the gossip protocol version to the cache key so the two protocols are isolated. It also makes the recently-rejected check only apply to actual gossip messages. This is a correctness fix in protocol handling; it does not by itself appear to allow direct theft of funds, but it could let invalid or stale gossip propagate or persist longer than intended across protocol boundaries.

This commit adds a new network message type called OnionMessage to the Lightning Network Daemon (LND). It is a protocol-level feature for carrying encrypted BOLT12 messages, not a fix for a known security flaw. The change itself is straightforward wiring: it registers the message type, adds encode/decode logic, and includes tests. There is no direct evidence in the commit that this introduces a vulnerability, but any new message parser adds a small amount of attack surface.

This change fixes a display/logic bug in LND's RPC layer where ordinary custom payment data could be incorrectly labeled as 'custom channel data' when returned over the API. It only affects how information is presented to callers, not how funds are moved on the Lightning network. The patch makes the API more accurate but does not appear to be a direct funds-loss vulnerability.

This commit tightens validation in LND's payment database so that a single payment cannot mix regular (non-blinded) and blinded routing attempts. Before this change, the code already rejected MPP records inside blinded payments, but it did not explicitly reject a plain legacy attempt being registered alongside a blinded one. The commit message says such a mix was only 'theoretically possible' because other checks prevent legacy payments from being split into shards. The patch adds an explicit error and many unit tests, making the safeguard more robust but not clearly fixing an actively exploitable vulnerability.

This commit is a straightforward internal code cleanup in the LND Lightning node software. It replaces a locally-defined 'ProtocolVersion' type with an equivalent type from another package ('lnwire.GossipVersion'). The actual numeric value used (version 1) and all database behavior remain exactly the same. There is no user-facing change and no security fix.

This commit simply deletes an unneeded CI configuration file. It is a routine cleanup with no security relevance.

This commit is a routine code refactoring in the LND Lightning Network implementation. It introduces a new Go interface called NodeAnnouncement and makes the existing NodeAnnouncement1 and NodeAnnouncement2 message types implement it. There is no change to network behavior, no bug fix, and no security-related functionality added or removed.

This commit only changes the project's Makefile to add a new build step that verifies the linter configuration file is up to date. It does not modify any source code, network code, cryptography, or anything that could affect runtime security. There is no security issue here.

This commit only adds new type definitions and an interface for future use. It does not change any existing behavior, fix a bug, or alter how messages are processed. There is no security issue here.

This commit only removes obsolete linter suppression comments (like `// nolint:scopelint`, `// nolint:structcheck`, `//nolint:gomnd`) from the source code. These comments tell automated code-quality tools to ignore certain warnings. Removing them does not change how the program runs, what data it processes, or how it handles errors. There is no security impact.

This commit is a routine build/CI maintenance change. It switches how a code-formatting tool (gosimports) is invoked in the project's Makefile, using Go's newer 'go tool' mechanism instead of installing a separate binary. There is no security-relevant change to the actual Lightning Network Daemon software or its users.

This commit is a routine developer tooling update: it upgrades the project's Go linter (golangci-lint) from version 1 to version 2 and rewrites the linter configuration file to match the new format. It does not change any production code, runtime behavior, or security-sensitive settings. No security issue is present.

This commit is a routine build-tooling update. It switches the project's development tools to use a new Go 1.24 feature called the 'tool directive', replacing an older workaround file. It also updates one code-formatting helper and slightly downgrades an indirect cryptography library version. There is no indication this change fixes or introduces a security vulnerability in the actual Lightning node software.

This commit simply updates the documentation link to the project's security contact PGP key. The key itself did not change; only the URL pointing to the renewed key was refreshed. There is no code change and no vulnerability in the software.

This commit only changes a single internal version number from 0.20.0 to 0.20.99 to mark that the master development branch is ahead of the latest released version. It does not change any network, wallet, or cryptographic behavior and has no security relevance.

This commit only adds a new documentation file explaining how the project plans to manage future software releases and branches. It does not change any program code, configuration, or security behavior. There is no security issue here.

This commit simply changes a version label from 'beta.rc4' to 'beta' in a single source file. It is a routine release-versioning change with no security relevance visible in the diff or commit message.

This commit only updates the release notes document. It adds a description of an earlier code change (a gRPC status code improvement for chain notifier RPCs) and fixes a spelling typo. There are no code changes in this commit itself, so it cannot introduce or fix any security vulnerability directly.

This commit changes the error code returned when LND's ChainNotifier sub-server is still starting up. Previously, clients received a generic 'Unknown' gRPC error with a text message; now they receive a standard 'Unavailable' code, which is the normal signal to retry later. It is a reliability improvement, not a security fix.

This commit simply replaces an expired PGP public key for a person named Suheb in the project's key directory. It is a routine key rotation with no code changes and no apparent security vulnerability.