LND

This commit adds a new piece of information—the block height at which a commitment transaction was confirmed—to the data structures used when resolving Lightning Network channel closes. It does not change any security-critical logic by itself; it is a data plumbing change that makes the confirmation height available to auxiliary contract resolvers. There is no direct vulnerability visible in the diff, but it could be a prerequisite for a future fix or feature that depends on knowing this height accurately.

This commit only adds a line to the release notes document for LND version 0.20.1. It describes a bug fix where resolving certain channel outputs could take too long, but it does not change any program code, configuration, or cryptographic logic. There is no direct security relevance visible in the commit itself.

This change removes a live blockchain rescan that waited for the commitment transaction to confirm, and instead uses a previously known confirmation height stored in the resolver. The main risk is that if the stored confirmation height is wrong or stale, the resolver may compute the wrong unlock time for locked funds, potentially causing premature or delayed sweeps. There is no direct evidence in the commit message or diff that this fixes an active security bug; it appears to be a simplification/optimization.

This commit changes only a single line of code comment text in the contractcourt package. It rewords a comment to more accurately describe that a report field is being updated with a calculated maturity height, rather than a confirmation height. No executable code, logic, or data flow was modified.

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