LND

This commit is a small API enhancement for LND's internal transaction notification system. It changes the 'Updates' progress channel so that, instead of only reporting how many confirmations are still needed, it also reports the block height where the transaction was included. There is no indication this fixes a security bug; it appears to be a feature improvement to give callers more information.

This change fixes a notification bug in LND's transaction confirmation tracker. Previously, if a transaction had been seen in a block but had not yet reached the required number of confirmations, and then that block was reorged (removed from the chain), subscribers were not told about the reorg. Now they are notified earlier, so downstream logic can react to the lost confirmation instead of waiting for a confirmation that may never come.

This commit is a massive repository import or initial commit adding the entire LND codebase plus CI, docs, and tooling. The PR title mentions relaxing a feature-bit check for peer features, but the supplied diff does not show any code changes related to that title—it only shows newly added files. There is no visible security patch or vulnerability fix in the provided materials.

This commit updates how LND validates a new style of Lightning channel announcement (ChannelAnnouncement2) so it correctly handles both older P2WSH-style channels and newer P2TR (Taproot) channels. Before this change, the validation logic appears to have assumed P2TR channels, which could have caused LND to reject valid announcements for older P2WSH channels or, in the worst case, accept invalid ones. The change also switches the gossiper from using a raw chain hash to carrying full chain parameters, which is needed to interpret on-chain scripts correctly.

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