LND

This commit is a simple variable rename from broadcastHeight to confirmHeight, plus updated comments, in the Lightning Network Daemon (LND) contract court code. It does not change any program logic, behavior, or security properties. The rename makes the code easier to understand because the value actually stores the block height at which the commitment transaction was confirmed, not the height it was broadcast.

This commit simply deletes unused code in the lncli command-line tool. A variable named chanPoints was being built up from channel backup data but never read or used afterward. Removing it has no functional or security effect.

This commit only adds a regression test for a previously fixed bug in LND's routing graph cache. The bug caused channels whose two routing policies were initially disabled to be left out of an in-memory cache. Later, if one policy became enabled, the cache could not be updated, so the channel stayed invisible for routing. The test documents the bug and verifies the fix, but does not itself change production code.

This commit only adds a new release notes document for version 0.20.1. It contains no code changes and does not alter how the software behaves. The document is mostly a template with empty sections and one bug-fix note describing a routing issue that was fixed in a separate pull request.

This commit fixes a bug in LND's routing graph cache. Previously, if a Lightning channel had both routing policies disabled when the node started up, the channel was never loaded into the in-memory routing cache. Later, if a policy update re-enabled one direction, the database would record the change but the cache would stay out of sync, so the channel could not actually be used for routing. The fix always loads the channel structure into the cache and only skips attaching the disabled policies, allowing later updates to enable it correctly.

This commit adds a missing helper method that reports how many bytes an onion message occupies when serialized. It is a small interface-compliance change with no direct security fix visible in the diff. Any security relevance would come from how downstream code uses this size information, but that behavior is not shown here.

This commit only reorganizes documentation. It moves a release note about a chain notifier RPC behavior change from the 0.20.0 release notes file to the 0.21.0 release notes file. No code was changed, and no security issue is introduced or fixed by this commit itself.

This commit only adds a release note describing a previously merged feature. It does not change any code, configuration defaults, or security behavior. There is no security issue in this documentation update.

This commit adds a new optional configuration setting, upfront-shutdown-address, to the Lightning Network Daemon (LND). When set, it tells LND to send cooperative channel-closing funds to a specific address by default. It only takes effect if the other peer also supports the upfront shutdown feature; otherwise channel opens fail. The change is a feature addition, not a fix for an active vulnerability, and it does not appear to introduce a security flaw on its own.

This commit only adds a new integration test to the LND project. It checks that when two users set an 'upfront shutdown address' before opening a Lightning channel, their funds correctly go to those addresses when the channel closes. There is no change to production code, no bug fix, and no security patch.

This commit is a code-maintenance refactor for LND's graph database migration. It copies a set of auto-generated SQL query helpers from the main SQL package into the migration1 package and updates imports so the migration uses its own frozen copy. The goal is to prevent future changes to the main SQL queries from accidentally breaking the one-time graph-to-SQL migration. There is no direct security fix or vulnerability being patched in the diff itself.

This commit only updates the release notes document. It adds a bullet point describing a previous code change that froze a database migration, and it adds a contributor's name. There is no actual code change, no bug fix, and no security-related content.

This commit is a routine build-file change. It tells the Go build system to use a local copy of an internal database package (sqldb) instead of fetching a published version from the internet. The commit message explicitly frames this as a temporary workaround for an upcoming feature (gossip V2 sqldb changes). There is no indication of a security fix, vulnerability, or behavior change in the compiled program.

This commit simply deletes a developer-only helper test that was used to manually test a database migration before it was released. The removed code was never run by default, never shipped to users, and did not change any production logic. It is not a security fix and has no security relevance.

This commit only deletes a four-line code comment in a single file. No program logic, data handling, or security behavior changed. It is a documentation cleanup with no security relevance.

This commit is a routine internal cleanup in LND's channel graph database code. It removes unused cached signature and public-key fields and their accessor methods, and switches some functions from returning structs by value to returning pointers. There is no change to security-sensitive behavior, no bug fix, and no externally reported issue.

This commit is a large internal refactoring of the Lightning Network Daemon (LND) database migration code. It copies existing graph database migration logic into a new, separate package called 'migration1' so future changes to the main graph code won't accidentally alter how old data is migrated. The change itself does not add a new user-facing feature or fix a known security bug; it is preparation work to make future database upgrades safer and easier to maintain.

This commit is a large internal refactoring of how Lightning Network node records are created in the LND codebase. It introduces a version field and a new constructor for node objects, then updates many tests and internal callers to use that constructor. There is no direct security fix or vulnerability being patched; it is structural preparation for future gossip protocol versions.

This commit is a routine code cleanup: it removes an unused Go interface called DB from the graph package and replaces its one remaining use with a direct pointer to the concrete ChannelGraph type. There is no change to program logic, data handling, or security behavior.

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 only updates release notes documentation. It adds a description of a new feature (onion messaging forwarding) to the 0.21.0 release notes file. No code changes are present, so there is no direct security impact from this patch itself.

This commit removes a redundant flag called HaveNodeAnnouncement from LND's internal node records and replaces it with a simple rule: if a node has a stored signature, it has an announcement. It is a code-quality/refactoring change that eliminates two conflicting ways of answering the same question. There is no direct evidence in the commit that this fixes an active security vulnerability, but inconsistent state can historically lead to subtle bugs in how node information is stored, forwarded, or validated.

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 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 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.