LND

This commit only updates the release notes document for version 0.21.0. It adds a short description of a payment store improvement project and adds two names to the contributor list. No program code was changed, and there is no security relevance.

This commit is purely preparatory infrastructure. It adds scaffolding for a future SQL-based payments database backend in LND, but explicitly does not implement any actual payment database methods yet. The new SQL store currently falls back to the existing key-value store implementation to satisfy build requirements. There is no security-relevant behavior change or vulnerability introduced in this patch.

This commit simply adds a new trusted PGP public key for a person named georgetsagk to the project's release-signature verification script. It is an administrative onboarding change, not a code fix or vulnerability patch. There is no security issue visible in the diff itself.

This commit only adds a new automated test for an existing invoice database query. It does not change any production code, so it cannot introduce a security vulnerability or fix one directly. The test verifies that a function called FetchPendingInvoices correctly returns invoices that are still open or accepted, and excludes settled or canceled ones.

This commit only adds a release note describing a previous performance improvement to invoice database queries. It changes documentation text only and does not modify any code, configuration, or security behavior. There is no security issue here.

This commit simply deletes an unused database query called FilterInvoices and its supporting code. The commit message says all places that used it have already been switched to newer, more targeted queries. There is no security issue visible in this change; it is routine code cleanup.

This commit is a backend cleanup of how LND searches its invoice database. It replaces one large catch-all query with several smaller, focused queries and always supplies concrete date and index bounds. The main practical effect is better database query planning and indexing, which can improve performance and reduce load. It is not a fix for an active security vulnerability, but it removes a pattern (nullable OR-based SQL fallbacks) that can sometimes hide subtle correctness or denial-of-service risks.

This commit adds new database query helpers for listing Lightning Network invoices in ways that let SQLite use indexes efficiently. It is a performance and maintainability change, not a security patch. The old catch-all query is kept so existing code still compiles, and will be removed later after callers are switched over.

This commit only updates the release notes document for version 0.21.0. It adds a bullet point describing that a feature now emits channel update events, and it adds one contributor name to the contributors list. There are no code changes, no bug fixes, and no security-related content.

This commit adds handling for a new type of channel update event in LND's RPC server. Previously, the SubscribeChannelEvents stream likely ignored or dropped ChannelUpdateEvent notifications. The change makes the RPC server emit a properly formatted CHANNEL_UPDATE message to subscribers. There is no direct security vulnerability visible in the diff; it appears to be a missing-feature/bug-fix patch that improves event completeness.

This commit adds a new integration test that checks whether users subscribed to channel events receive real-time notifications when a Lightning channel is opened, becomes active, or processes a payment. It does not change production code or fix any bug.

This commit only adds a new notification type to LND's public API definitions (protobuf files). It tells client applications that a channel's commitment state has changed, but does not change how LND processes payments, channels, or secrets. There is no security issue visible in the diff itself.

This commit adds a read-only accessor that returns a private copy of a Lightning channel's internal state. It is a defensive code change: by making a deep copy before handing data out, it prevents callers from accidentally or intentionally modifying sensitive internal state. There is no direct security vulnerability in the patch itself; it is a hardening measure.

This small change makes a Lightning payment channel component notify subscribers whenever the remote side signs a new commitment. It is a state-visibility improvement, not a direct fix for a known exploit. The commit message and diff do not describe a security vulnerability, but missing or delayed channel-state notifications could theoretically contribute to stale state in dependent subsystems.

This commit adds a new notification hook so the channel link can tell other parts of the program when a channel's state has been updated. It is purely an infrastructure/plumbing change: it wires up a new callback but does not change any existing security behavior, validation, or access control. There is no indication this fixes or introduces a vulnerability.

This commit adds a new internal notification type so that parts of the LND program can be told when a Lightning channel's state changes. It is purely an infrastructure/observability change: it adds a new event struct, a function to send the event, and a unit test. There is no change to network-facing behavior, authentication, cryptography, or money-handling logic.

This commit changes how LND tracks the newest channel ID in its network graph so the lookup can be filtered by a specific gossip protocol version. It is a structural refactoring to support multiple gossip versions, not a fix for an active security flaw. The change adds version checks that reject unsupported gossip versions, which is a defensive improvement, but the commit message and diff do not describe any vulnerability or security incident.

This commit only updates the release notes documentation by adding a link to another pull request. It does not change any code, configuration, or security behavior.

This commit is a routine code refactoring. It adds a 'gossip version' parameter to a function called FetchChanInfos so the graph database can handle both old (v1) and new (v2) Lightning network gossip formats consistently. It also updates callers and tests. There is no indication this fixes a security bug or introduces a vulnerability.

This commit fixes a bug in LND's channel graph cache where a database query forgot to fetch the 'version' field for routing policies. The code was then hardcoding an older policy version (GossipVersion1) for those cached policies. This could cause newer, extended routing policy fields to be misinterpreted or ignored when the cache is used, potentially leading to stale or incorrect routing information.

This commit only changes test code. It makes two existing graph database tests run against both v1 and v2 gossip protocol versions, and adjusts the test setup and assertions to handle differences between those versions. There is no change to production code and no security fix or vulnerability introduced.

This commit is a routine test and code-cleanup change. It removes an unused wrapper method, extends two existing tests to run against both old and new gossip protocol versions, and updates a database helper to accept both known gossip versions instead of only version 1. There is no security fix or vulnerability patch here.

This commit extends the Lightning Network Daemon's channel graph database so it can separately list disabled channels for the older gossip protocol version (v1) and the newer one (v2). Previously the disabled-channel lookup only handled v1. The change is a feature completion / correctness fix: without it, a node running with v2 gossip could either get wrong disabled-channel data or fail to prune stale channels. There is no direct evidence in the commit that this was a security vulnerability, but an incorrect disabled-channel list could affect routing and channel pruning behavior.

This commit changes how the Lightning Network Daemon (LND) looks up a compact channel identifier from a funding transaction outpoint. It adds a 'gossip version' parameter to the lookup so that the database can distinguish between different protocol versions when resolving channel IDs. The change is a structural/API update rather than a fix for an active security flaw. It does not, on its own, prevent or enable a known attack, but it is part of making the graph database version-aware, which can help avoid mismatches between how channels are stored and queried.

This commit only changes a test helper function in a test file. It makes the function able to create fake channel data in two different formats (v1 and v2) instead of only one. There is no change to production code, no bug fix, and no security issue.