LND

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 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 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 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 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 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 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 simply deletes an unneeded CI configuration file. It is a routine cleanup with no security relevance.

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.

This commit updates an OpenPGP public key file stored in the repository. The underlying cryptographic key material did not change; only the key's metadata (specifically its self-signatures and expiry dates) was refreshed to extend the key's validity period. There is no code change and no direct security vulnerability in the commit itself.

This commit only changes a single version string from 'beta.rc3' to 'beta.rc4' in the LND software. It is a routine release-candidate version bump with no functional code changes and no security relevance.

This commit only adds a line to the release notes document describing a bug fix from another pull request. It does not change any program code, so by itself it cannot introduce or fix a security issue. The actual bug fix happened elsewhere.

This commit only adds new test code to the LND repository. It does not change any production code, so it cannot introduce a security vulnerability or fix one directly. The tests verify that certain error-handling paths in the gossip syncer exit cleanly rather than looping forever. Because the commit is purely tests, its immediate security risk is none, though it may increase confidence that prior fixes work as intended.