LND

This commit only updates a documentation file (docs/db_migration_guide.md) to explain when and how SQL migration steps are automatically applied. It adds three lines of clarifying text about log messages users will see. There is no code change and no security relevance.

This commit only adds a line to the release notes document describing a bug fix that was already merged in a separate pull request. No code was changed, so this commit itself does not fix or introduce any security issue.

This commit adds a new database helper that lets LND update its own node information even when the timestamp hasn't advanced. It changes the comparison from 'newer than' to 'newer than or equal to' for the node's own record. There is no obvious security bug in the diff itself, but it slightly relaxes a consistency rule that normally prevents stale data from overwriting newer data.

This commit fixes a race condition in LND's graph database code. During startup, multiple internal routines could try to update the node's own information at the same time, using the same timestamp. The old SQL upsert required a strictly newer timestamp, so these concurrent updates sometimes failed with 'sql: no rows in result set'. The fix uses a more lenient upsert for the local node so that last-write-wins and parameter changes persist even when timestamps collide. It is a reliability/availability fix rather than a vulnerability that external attackers can exploit.

This commit only adds a new test to document an existing inconsistency between two database backends in the Lightning Network Daemon (LND). It does not change production code. The test shows that when LND updates its own node information with the same timestamp but different details, the SQL database backend rejects it with an error, while the older bbolt backend accepts it silently. The commit message says this will be fixed later. So by itself, this commit is not a security fix and does not introduce a vulnerability, but it documents a real behavioral quirk that could affect how LND stores its own node announcements.

This commit only updates the release notes document. It adds a description of a previously fixed startup bug related to TLS certificate/key files and adds a contributor name. There is no code change in this commit itself.

This commit only adds a line to the release notes document for LND 0.20.1, describing a previously merged bug fix. No actual code changes are included, so it cannot by itself introduce, fix, or exploit any security issue.

This change makes LND's routing memory (mission control) more resilient: if the database contains damaged or unreadable entries, the node now starts up anyway instead of crashing, and it cleans out the bad entries. The patch itself is defensive and does not introduce an obvious vulnerability, but it silently deletes data, which could hide underlying corruption or, in theory, allow a subtle attacker to manipulate routing history if they could already write corrupt records to the database.

This commit only adds documentation text to the release notes for an upcoming LND version. It describes a previously merged feature that improves fee estimation for Lightning Service Provider routes. There is no code change, no bug fix, and no security-related content in the diff.

This commit rewrites how the LND Lightning node's fee-estimation probing handles invoices that route through Lightning Service Providers (LSPs). It changes the LSP-detection rules, probes up to three distinct public LSPs, and returns the most expensive (worst-case) fee estimate rather than a single or cheapest estimate. The change is a defensive feature/refactor, not a clear vulnerability fix, but it alters security-relevant fee and route logic and removes an older public-channel check in favor of a graph-membership check.

This commit only updates documentation. It changes the description and a flowchart in a markdown file explaining how LND's EstimateRouteFee feature detects Lightning Service Providers (LSPs). No code, configuration, or executable behavior was changed.

This commit only adds and improves an integration test for the EstimateRouteFee feature in LND. It does not change production code, so it cannot introduce a security vulnerability or fix one directly. The test checks that route-fee estimates correctly handle public targets, multiple LSPs, and worst-case fee selection.

This commit adds a simple internal helper function called HasNode that lets other parts of the Lightning Network Daemon (LND) ask whether a given node is publicly known in the network graph. It is purely a read-only lookup and does not change any behavior, access controls, or data. There is no indication this fixes or introduces a security issue.

This commit only fixes a typo in a code comment, changing the name 'HasLightningNode' to 'HasNode' so it matches the actual function name. No code behavior was changed and there is no security impact.

This commit only adds documentation text to the release notes for LND version 0.20.1. It describes a new Postgres database configuration option but does not change any code, configuration defaults, or runtime behavior. There is no security issue in this change itself.

This commit makes a database-locking setting configurable for users running LND with a PostgreSQL backend. Previously, the wallet database always used a single-writer 'global lock' and the channel database did not. Now operators can turn each on or off via new config options. The change is framed as a temporary safety/concurrency workaround, not as a fix for an active security vulnerability.

This commit adds two new configuration options for LND's Postgres database backends that let operators choose whether to use a single global lock for channel database and wallet database access. The defaults are chosen to preserve existing behavior: channeldb does not use the global lock, while walletdb does. The commit describes this as a temporary workaround until those subsystems are migrated to native SQL. There is no direct security fix here; it is a configurability change that may help operators avoid concurrency-related bugs or data corruption, but it does not by itself patch a known vulnerability.

This small change fixes a logic bug in how LND decides whether to create its TLS certificate and private key. Previously, if either the certificate or the key file existed, the program skipped creating a new pair and tried to handle encryption settings instead. After the fix, it only skips creation when both files exist. The old behavior could leave LND running with a mismatched certificate/key pair (for example, a new certificate paired with an old key, or vice versa), which can break TLS connections to the node or, in rare cases, affect how private keys are protected on disk.

This commit only adds a new test file that reproduces a bug: when LND's TLS manager finds only one of its two TLS files (either the certificate or the private key) on disk, it wrongly assumes the other file also exists and skips generating a fresh pair. That leaves the node unable to start or serve TLS correctly. The commit does not include the actual fix, only the failing/regression test.

This commit only updates the release notes document for version 0.20.1. It adds a one-line description of an already-fixed bug about duplicate network addresses appearing in node announcements and the getinfo output. There are no code changes in this commit, so it cannot by itself introduce, fix, or enable any security issue.

This change makes sure a Lightning node's public announcement doesn't accidentally list the same network address twice. Duplicate addresses could confuse other nodes, waste resources, or in some protocol situations be misused. The fix removes duplicates right before signing the announcement.

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.