LND

This commit only expands an existing developer helper test in the LND codebase. It adds configuration options so engineers can locally test migrating graph data between different database backends (bbolt, sqlite, postgres). The test is skipped by default and does not change any production code, network behavior, or user-facing functionality. There is no security issue here.

This commit only adds a line to the release notes document describing a previously merged database index improvement. No code changes are present, and there is no security relevance in the diff itself.

This commit adds a new documentation file explaining how SQL database schema updates should be written in LND. It contains no code changes, no configuration changes, and no fixes. It is purely a developer guide.

This commit reorganizes database migration files for the LND Lightning node software. It moves a new invoice index migration into the main production migration sequence and renumbers the graph-related migration files so they remain in chronological order. There are no code changes that fix or introduce a security vulnerability; it is purely a schema-management cleanup.

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