LND

This commit removes an expired PGP public key belonging to a former release signer from the project's install verification script. It is a routine key hygiene change: keeping an expired key in the trusted key list could cause signature verification to fail or accept stale signatures, but the commit itself does not introduce any code vulnerability.

This commit adds a database index on the 'settle_index' column of the 'invoices' table. An index is like a lookup table that makes certain database queries much faster. The commit title says it is a 'missing' index, suggesting it should have existed already. Without it, operations that look up settled invoices by their settle index could be slow, especially as the database grows. This is a performance fix, not a code change that directly prevents or enables an attack.

This commit fixes a database migration rollback script. When undoing the invoices-related database schema, the script previously tried to drop indexes that either had wrong names or did not exist, and it forgot to drop one index that actually exists. This is a cleanup/maintenance fix for a 'down' migration; it does not change normal runtime behavior or fix an active security vulnerability.

This commit simply moves two helper functions that convert time values to and from a binary format from one file to another within the same package. There is no change to what the code does, no bug fix, and no security-relevant behavior.

This commit simply renames two internal helper functions so they can be used by other parts of the codebase. It does not change what the functions do, how they work, or any user-facing behavior. There is no security issue here.

This commit changes internal database configuration values from signed integers (int/int32) to unsigned integers (uint32). It is a code-quality and type-safety cleanup, not a fix for an active security vulnerability. The change removes the theoretical possibility that a negative page or batch size could be supplied, which could cause loops or errors, but there is no evidence this was exploitable by an attacker.

This commit simply deletes a two-line TODO comment from a benchmark test file. A TODO is a developer note, not code. There is no functional change, no bug fix, and no security relevance in the diff itself.

This commit improves a database migration that moves old 'zombie' Lightning channel records into a new SQL database. It switches from checking each record one-by-one to checking them in batches, and now also verifies the two node public keys associated with each channel, not just the channel ID. This is a correctness/reliability improvement for a one-time migration, not a fix for an active security vulnerability.

This commit only adds stopwatch-style timing to log messages that already existed. It records how long database migration steps take and prints the duration in the log. There are no changes to security logic, access controls, cryptography, or data handling.

This commit is a performance optimization for LND's database migration from the older key-value store to the new SQL store. It changes how channel and routing-policy records are verified after being copied: instead of reading back each channel one at a time, the code now collects a batch and reads them together. There is no security fix here and no indication it closes a vulnerability; it is purely about reducing database round trips during an upgrade.

This commit is a performance optimization for a database migration in the Lightning Network Daemon (LND). It changes how the software verifies that closed channel identifiers were copied correctly from an older key-value database to a newer SQL database. Instead of checking each identifier one at a time, it now checks them in groups (batches). This should make the migration faster but does not change what data is stored or fix a security vulnerability.

This commit rewrites a database migration routine so it validates groups of records at once instead of one by one. The goal is to speed up the migration by reducing database round trips. There is no direct security fix here; it is a performance and reliability improvement to an internal data-migration path.

This commit changes how LND validates data copied from an older key-value database into a newer SQL database during a one-time migration. Instead of reading back each prune-log entry one at a time, it reads them back in batches. The goal is to make the migration faster, not to fix a security bug. The change still checks that every copied entry matches the original, and it still reports an error if anything does not match.

This change is a performance optimization for LND's database code. It moves a 'does this channel already exist?' check from inside a helper function to the caller, so the check is skipped during database migrations where it isn't needed. The commit message says this significantly speeds up migrations on PostgreSQL. There is no direct evidence this fixes a security vulnerability.

This commit adds input validation to LND's database configuration settings. Previously, users could set SQL batch sizes larger than the database can actually handle, which could cause database queries to fail. The change enforces safe maximums for SQLite and Postgres, preventing misconfiguration rather than fixing an active vulnerability.

This commit removes a one-size-fits-all database query configuration and replaces it with separate SQLite and PostgreSQL defaults. It also threads the correct configuration through graph migration and lookup code instead of silently using a hard-coded default. The change is primarily a correctness and maintainability improvement; it does not appear to fix an active vulnerability, but it prevents potential bugs where the wrong database backend settings could be used during graph data migration or node lookups.

This commit simply exposes two internal database tuning knobs—batch size and pagination size—for SQLite and Postgres as user-configurable options. It does not change any security behavior, fix a bug, or alter access controls. It is a routine configuration enhancement.

This commit is a performance tuning change, not a security fix. It adds a benchmark to find the best default query batch/page sizes for SQLite versus Postgres in LND's graph database code, then splits the previous single default config into separate SQLite and Postgres defaults. There is no indication it fixes a vulnerability or changes any security behavior.

This commit fixes progress logging counters in database migration code. Three migration functions were incrementing a 'count' variable but not a separate 'chunk' variable, which is likely used to decide when to print progress updates. The fix adds the missing 'chunk++' increments so progress logs are emitted at the intended intervals. There is no security relevance visible in the code change.

This commit simply removes a three-line comment (a TODO note) from a Go source file. No code behavior changed, no bug was fixed, and no security issue is present in the diff.

This commit is a simple internal rename of a variable from currPaymentSeq to currSeq. It does not change any behavior, logic, or security properties of the code. There is no security issue present.

This commit is a simple internal variable rename from 'storedPaymentSeq' to 'storedSeq' in the payments database code. It does not change any logic, behavior, or security properties of the software.

This commit simply renames an internal mutex variable from paymentSeqMx to seqMu. It is a non-functional code cleanup with no behavior change and no security relevance.

This commit is a code cleanup and refactoring change in LND's payment database. It moves the 'keep failed payment attempts' setting from the main channel database struct into the dedicated payments key-value store, and makes the payments store accept any compatible key-value backend rather than only the full ChannelState database. There is no direct security vulnerability visible in the diff; it is primarily an architectural change to prepare for future database backends.

This commit adds a new logging subsystem for the payments database package in LND. It only introduces logging infrastructure (a logger variable, subsystem name, and registration with the main logger setup) and does not change any payment-handling logic, database queries, or security behavior. There is no security issue visible in this change.