LND

This commit is a straightforward database schema plumbing change for the LND Lightning node. It adds two new optional fields—block height and disable flags—to the channel policy records so that a future protocol version (v2) can store extra information. The fields are always written as NULL for now, so the change does not by itself fix or introduce any security issue. It simply prepares the data layer for later feature work.

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 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 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 only changes a test file. It converts an existing single-version test into a versioned test that runs against both v1 and v2 gossip protocol versions. There is no change to production code, no bug fix, and no security-relevant behavior change.

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 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 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 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 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 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 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 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 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 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 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 is a small, straightforward code cleanup change. It adds a 'version' parameter to an internal helper function so that future code can choose between gossip protocol versions. Right now every caller still hardcodes version 1, so behavior is unchanged. There is no security issue visible in this commit.

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 only adds and reorganizes test code. It introduces a new test helper that runs existing node database tests against both v1 and v2 gossip data formats, and refactors one existing test to use that helper. There is no change to production code, runtime behavior, or security-sensitive logic.

This commit is a straightforward internal refactoring in LND's channel graph code. It introduces a new VersionedGraph wrapper so that future support for multiple gossip protocol versions can be added cleanly. For now every call site is hard-coded to use the existing V1 gossip version, so observable behavior is unchanged. There is no security fix or vulnerability here.

This commit only changes test code. It updates helper functions in the graph database test file so they can create either version 1 or version 2 Lightning Network gossip nodes, and updates existing tests to explicitly request version 1 nodes. There is no change to production code, no bug fix, and no security-relevant behavior.

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.