LND

This commit refactors how a Lightning network message (ChannelUpdate2) is encoded and decoded. Previously, the digital signature was a separate fixed field; now it is treated as just another TLV (Type-Length-Value) record inside the message. The change also preserves unknown fields that fall within the signed portion of the message so that signatures can still be validated correctly. There is no direct evidence in the commit that this fixes an active security bug, but it is a protocol-correctness change that could prevent signature-validation failures or message-malleability issues when future unknown fields are present.

This commit is a small internal code cleanup in the LND lightning node software. It changes several functions so they receive a short channel identifier (SCID) directly by value instead of by pointer. There is no user-facing behavior change, no bug fix, and no security-relevant change visible in the diff.

This commit refactors how one Lightning network message type (AnnounceSignatures2) is encoded and decoded, switching it from a fixed-field format to a more flexible Type-Length-Value (TLV) format. The change is primarily a code modernization and protocol-alignment refactor. There is no direct evidence in the commit or supplied references that this fixes an active security vulnerability.

This commit refactors how a new Lightning network message type (ChannelAnnouncement2) is encoded and decoded. Previously the message had a fixed signature field followed by a block of TLV data. Now the signature itself is placed inside the TLV stream, and the code distinguishes between fields that are covered by the signature and those that are not. The change is a protocol-structure update rather than a clear-cut bug fix, but it touches signature coverage and message parsing, which are security-sensitive areas.

This commit adds a small plumbing feature that lets a ChannelID be packaged as a TLV record. It is a straightforward, additive code change with no visible security relevance on its own.

This commit adds a new internal framework called PureTLVMessage to the Lightning Network wire protocol code. It is purely a code addition (no existing behavior is changed) and is designed to make future message formats more forward-compatible. There is no indication this commit fixes a security bug or introduces a vulnerability.

This commit only adds a second run of an existing database migration inside a test, to verify the migration can be safely repeated without changing results. It is a test-only change and does not alter production code.

This commit is a performance optimization for a database migration in the Lightning Network Daemon (LND). It removes an unnecessary database lookup during the migration of channel policies and changes an 'insert-only' operation into an 'upsert' (insert-or-update) for extra policy data. There is no security-relevant change here; it only makes the migration faster and more retry-safe.

This commit fixes a database migration in LND so that if the migration is interrupted and run again, it won't fail when it sees channel policies that were already copied over. It replaces a strict 'only update if newer' insert with an 'insert or update regardless of timestamp' version used only during migration. This is a reliability improvement, not a security fix, and it does not introduce a new vulnerability.

This commit fixes a database migration bug in LND's move to a SQL-backed channel graph. Previously, if the migration was interrupted and retried, re-inserting a channel that had already been migrated would cause a duplicate-key error and abort the upgrade. The patch makes the channel-insert step idempotent: re-inserting the same channel now updates the existing row instead of failing, and re-adding features or extra TLV fields is also handled gracefully. It is a robustness fix for a one-time upgrade path, not a remotely exploitable vulnerability.

This commit is a performance and reliability cleanup for a database migration in the Lightning Network Daemon (LND). It changes how node information is copied into a new SQL database format so that if the migration is interrupted and restarted, it can safely skip re-inserting data that is already present. There is no indication this fixes an active security vulnerability or introduces a new attack path.

This commit fixes a reliability bug in LND's database migration process. When LND upgrades and moves old node data into a new SQL database, the migration could fail if it had to be restarted part-way through and tried to re-insert a node it had already inserted. The normal database logic rejects re-inserting the same node unless the timestamp is newer, but migration data doesn't always meet that rule. The fix adds a migration-only insert that safely ignores exact duplicates and resets progress counters so the migration can be retried cleanly. It is a robustness improvement, not a remote attack vector.

This commit only changes a test file. It updates the graph database migration test to check whether running the migration twice (a retry) succeeds or fails. The commit message says the actual migration code is not yet retry-safe, and this test change is preparation for a future fix. No production code is changed, so this is not a fix for a live vulnerability by itself.

This commit only adds a new test case to an existing database migration test file. It does not change any production code, fix a bug, or alter behavior. The test verifies that migrating channels without routing policies works correctly. There is no security issue visible in this change.

This change is a code cleanup in LND's database migration logic. It threads 'reset' callbacks through helper functions that iterate over old-style database entries, so that batch-processing variables can be properly reset on retries. The commit message frames it as preparation for future retry handling on the source database side. There is no direct security fix here; it is defensive maintenance that could prevent data-integrity issues during migrations if retries occur.

This is a small test-only change that adds a field to a helper function used in database migration tests. It does not change any production code, network behavior, or user-facing functionality. There is no security issue here.

This commit is a routine maintenance update to the project's automated build and test system. It upgrades the version of a commonly used GitHub-provided action (actions/checkout) from version 4 to version 5 in the project's CI workflow file. There is no indication of a security fix or vulnerability being addressed in the code itself.

This commit only adds documentation comments to a Go interface describing payment routing behavior. No code logic, function signatures, or security controls were changed.

This commit only adds a clarifying comment to existing code. It does not change any program logic, behavior, or security properties. The comment explains that deleting failed payment attempts may be a no-op depending on database options.

This commit is a straightforward code cleanup: it moves an existing interface definition (DBMPPayment) from the routing package to the payments/db package and updates all references. There is no functional change to how the software behaves, and no security issue is introduced or fixed.

This commit only fixes code style issues flagged by a linter. It adds punctuation to comments and reformats a test function call to fit line-length rules. There are no changes to program logic, security behavior, or how payments are processed.

This commit only renames a test helper function from `assertPaymentstatus` to `assertDBPaymentstatus` and updates all call sites in test files. It makes no changes to production code, user-facing behavior, or security logic. There is no security relevance.

This commit is a simple rename of a Go type and its constructor from KVPaymentsDB/NewKVPaymentsDB to KVStore/NewKVStore across five files. It changes no logic, no behavior, and no security-sensitive code. It is purely a code-style/consistency refactor to match naming already used elsewhere in the project.

This commit simply moves four existing helper functions (two for serializing and two for deserializing HTLC settlement/failure details) from one source file to another within the payments database package. No logic, behavior, or security properties of the code are changed.

This commit only adds missing documentation comments to helper functions in a test file. It does not change any executable code, behavior, or security logic.