LND

This commit only updates the release notes document. It adds a hyperlink to an already-merged pull request about preparing the graph database for a new gossip protocol version. No program code was changed, so it cannot by itself introduce or fix a security issue.

This commit refactors how LND deletes channel edges from the network graph so that deletions go through a new version-aware wrapper. The change is mostly a code cleanup to support multiple gossip graph versions, but it includes a TODO noting that one RPC path still only supports v1 channel deletions. There is no direct evidence in the commit of an exploitable security bug.

This commit is a routine internal refactoring to prepare the LND channel graph database for future support of multiple gossip protocol versions. It adds a version parameter to two edge-lookup functions and makes the SQL store use that parameter instead of a hardcoded version. There is no security bug being fixed here and no behavior that would let an attacker do anything harmful.

This commit extends the channel graph database so that zombie-edge lookups know which gossip protocol version (v1 or v2) they are dealing with. Previously the code only checked v1 zombie records; now it can check the matching version. It is a correctness/refactoring change rather than a fix for an active vulnerability, but it removes a version-confusion bug class that could cause routing or channel-state mistakes in a multi-version Lightning network.

This commit adds a new database query to support v2 Lightning channel proofs. It simply updates a single signature column for v2 channels, whereas the older v1 proof format required four separate signatures. There is no security issue visible in the change itself.

This commit fixes a bug in LND's Lightning Network graph database where empty channel signatures were being treated as valid proof that a channel was publicly announced. Because the code previously treated empty byte slices the same as real signatures, a node connected only by such a 'channel' could incorrectly be considered public. The fix makes the database store empty signatures as NULL and changes all public-channel checks to require a signature length greater than zero. The commit message frames this as a correctness improvement and adds regression tests, but does not label it a security vulnerability.

This commit extends a database function in the LND Lightning node so it can store both old-style (v1) and new-style (v2) channel authentication proofs. Previously, the code only accepted v1 proofs and would reject v2 proofs with an error. The change is a feature completion / bug fix for the new gossip protocol support, not a fix for an active security vulnerability. It adds the matching SQL query and tests for both versions.

This commit updates how LND decides whether a Lightning node is 'public' so that the decision respects the network's gossip protocol version. In the older v1 protocol, a node needed four signatures to be considered public; in the newer v2 protocol, one signature is enough. Previously the code always used the v1 rule, which could misclassify v2 nodes as private. The change is a correctness fix rather than an obvious remote-exploitable vulnerability, but misclassified publicity could affect routing, channel selection, or policy decisions.

This commit adds a new database query helper that checks whether a Lightning node has any 'version 2' public channels. It is purely additive and does not change any existing behavior or fix a known bug. There is no indication in the commit that this is a security patch.

This commit only updates the release notes documentation. It adds a second pull request link to an existing note about preparing the graph database for a future protocol feature (gossip v2). No code, logic, or configuration changes are present in the diff.

This commit is a pure test-code cleanup. It replaces verbose error-checking patterns in a single unit test with shorter, equivalent assertion helpers. There is no change to production code, no change to behavior, and no security relevance.

This commit adds new data fields and code to support version 2 (Taproot) Lightning channels in LND's graph database. It does not fix a bug or close a security hole; it is a feature addition that lets the software understand and store newer channel announcement formats, including optional Merkle tree commitments and MuSig2 aggregated public keys. There is no indication in the commit or supplied references that this change addresses a security vulnerability.

This commit refactors how Lightning Network channel authentication proofs are represented in the lnd codebase. It adds support for a future v2 channel announcement format (using a single Schnorr signature) while keeping v1 (four ECDSA signatures) as the only currently supported version. The change is structural and preparatory; it does not appear to fix an active security bug, nor does it introduce obvious new vulnerabilities. Both database stores explicitly reject v2 proofs for now.

This commit is a code cleanup: it moves the logic that builds a Lightning network channel announcement message into a single helper method on the channel data object. It also makes an existing function use that helper instead of duplicating the conversion code. There is no direct security fix here, but centralizing the logic reduces the chance of future bugs where different code paths build announcements differently. The helper also adds a small safety check that refuses to build an announcement if required proof data is missing.

This commit is a routine code cleanup in LND's channel graph database. It moves the logic for generating a Bitcoin funding script into a dedicated method on a data structure, replacing a few direct helper function calls. There is no security fix or vulnerability here.

This commit changes how LND deletes Lightning channel records from its graph database. It adds a 'version' parameter so the code can distinguish between older (v1) and newer (v2) channel announcement formats. Right now it mostly hard-codes v1 and explicitly rejects or errors on v2 in some paths, so it is a preparatory/refactoring change rather than a finished security fix. There is no evidence in the commit that this resolves an active vulnerability or that it was released as a security patch.

This commit extends LND's SQL graph database to store and retrieve a newer type of Lightning channel announcement (called 'v2' or 'taproot' channels). It adds support for new fields like funding scripts, Merkle root hashes, and a single signature, and it replaces hard-coded 'v1 only' checks with version-aware logic. There is no direct evidence in the commit that this fixes an active security bug; it reads as a feature-completion change to support a new protocol version.

This commit changes how Lightning Network channel announcement data is stored so that two public-key fields (BitcoinKey1Bytes and BitcoinKey2Bytes) are now optional rather than always required. This is preparation for a newer channel-announcement format (V2) where those keys may not be present. The change itself is a data-model refactor, not a fix for an active bug or vulnerability. It adds explicit error handling when those keys are unexpectedly missing in places that still require them, which is a defensive improvement.

This commit only changes test code. It extends a helper function used in unit tests so it can create both old-style (v1) and new-style (v2) fake Lightning channels for testing. No production code is modified, so it cannot directly affect real users or funds.

This commit is a code-quality and safety refactor for LND's Lightning channel graph data structures. It introduces a single, controlled constructor for creating V1 channel records, replacing many places where fields were set by hand. The change makes it harder to accidentally create an invalid or inconsistent channel record, and adds a check that any attached proof matches the channel version. It is not an obvious security fix for an active vulnerability, but it reduces the risk of future bugs in how the network graph is built and validated.

This commit is a straightforward internal code cleanup in LND's channel graph database. It swaps one Go data type for another equivalent one (route.Vertex, which is defined as exactly the same 33-byte array) when storing public keys in channel records. There is no functional change, no bug fix, and no security-relevant behavior change.

This commit adds a version field to Lightning Network channel records and makes the code reject version 2 channels for now. It is a forward-looking structural change, not a fix for an active security bug. The new validation prevents the node from accidentally storing or relaying channel announcements it does not yet understand, which reduces the risk of future misbehavior but does not by itself stop any known current attack.

This commit removes an unused internal cache field that stored a parsed cryptographic signature alongside the raw signature bytes. It is a straightforward code cleanup with no security-relevant behavior change: callers still access the raw signature bytes, and the only consumer is updated to set the field directly instead of through a helper method.

This commit updates a database query used to store Lightning Network channel announcements. It adds three new optional fields needed for newer 'v2' channel types (a single Schnorr signature, the funding output script, and a Merkle root hash). For older 'v1' channels these fields are left empty/NULL. There is no security fix or vulnerability here; it is a straightforward schema/query update to support a new channel format.

This commit only adds a test-only helper variable (isSQLDB) to three test setup files. It does not change any production code, network behavior, or security-sensitive logic. There is no security issue here.