LND

This commit adds a new option in LND's Bitcoin wallet signer that lets two different key tweaks be applied one after another to a private key, instead of only allowing one at a time. A tweak is a cryptographic adjustment used in Lightning for things like revocation keys and HTLC indexes. The change is additive and preserves old behavior when only one tweak is provided. There is no direct evidence in the commit that this fixes an active security vulnerability.

This update adds a safety net around a specific message-handling path in LND's gossip subsystem. Previously, a crash while handling an AnnounceSignatures1 message could bring down the whole gossip component; now the code catches such crashes and keeps running. The change is defensive hardening rather than a fix for a known active attack.

This commit removes a time-limited 'experiment period' for a new Lightning network signaling feature called 'accountable' (previously 'endorsement signal'). Previously, nodes would only relay this signal until a fixed date in 2026, after which they would stop. Now, because the latest protocol proposal says the default should be to send a zero/'unaccountable' value, there is no longer a privacy risk from relaying it, so the experiment end date is removed. The signal is now relayed whenever the feature is enabled, regardless of date. This is a protocol behavior change, not a fix for an exploitable security bug.

This commit is a pure rename of an experimental Lightning Network feature from 'endorsement' to 'accountable/accountability' to match a community proposal update. No security vulnerability is introduced or fixed; the underlying behavior, feature bits, TLV type, and experiment end date remain unchanged. It is a terminology and identifier refactor across 21 files.

This commit fixes a database race condition in LND (a Bitcoin Lightning Network implementation). When a channel closed, the software could incorrectly delete stored peer information ('link node') even though a new channel with that same peer had just been opened. The fix moves the 'check for open channels' and 'delete peer info' steps into the same database transaction, so they happen atomically and cannot be interrupted by another operation.

This commit only adds new integration tests and test helper wrappers for the MuSig2 'coordinator pattern' RPCs. It does not change any production code, wallet logic, or consensus behavior. There is no security vulnerability here.

This commit adds two new server-side RPC handlers for an advanced multi-signature signing feature called MuSig2. The handlers let a caller register a pre-aggregated combined nonce and retrieve the combined nonce for a signing session. The code delegates to existing signer logic, checks the session ID format, validates the nonce length, and assigns macaroon permissions. There is no direct evidence in the commit of a security vulnerability; it appears to be a normal feature-completion change.

This commit removes a redundant flag called HaveNodeAnnouncement from LND's internal node records and replaces it with a simple rule: if a node has a stored signature, it has an announcement. It is a code-quality/refactoring change that eliminates two conflicting ways of answering the same question. There is no direct evidence in the commit that this fixes an active security vulnerability, but inconsistent state can historically lead to subtle bugs in how node information is stored, forwarded, or validated.

This commit is a straightforward code organization change. It adds a GossipVersion() method to several existing Lightning network gossip message types and updates their interfaces to require it. There is no bug fix, behavior change, or security patch visible in the diff.

This commit updates an OpenPGP public key file stored in the repository. The underlying cryptographic key material did not change; only the key's metadata (specifically its self-signatures and expiry dates) was refreshed to extend the key's validity period. There is no code change and no direct security vulnerability in the commit itself.

This commit simply refreshes an expired PGP public key file used to verify software releases. The same cryptographic key is kept, but its expiration date is extended. There is no code change and no security vulnerability.

This commit is a routine build-maintenance change. It updates the version of the Go programming language used by the project's automated tests, release builds, Docker images, and documentation from Go 1.25.2 to Go 1.25.3 (and the minimum required Go version from 1.24.8 to 1.24.9). There are no code logic changes, no bug fixes, and no security patches in the project itself.

This commit is a routine build-maintenance change. It updates the Go compiler version used in CI, release pipelines, Docker images, and documentation from Go 1.24.6 to Go 1.25.2, and bumps the minimum Go version declared in go.mod files from 1.24.6 to 1.24.8. There are no code logic changes and no security fix or vulnerability patch is visible in the diff.

This commit refactors an internal LND gossip method to return a lazy iterator instead of a fully built list of network messages. The goal is to reduce memory use when syncing large amounts of routing gossip. It is a code-quality/performance change, not a fix for an active security bug. There is no evidence in the commit or supplied references that it addresses a disclosed vulnerability.

This commit fixes three places in the LND (Lightning Network Daemon) code where a map was being reset by assigning it to nil. The fix uses Go's `clear()` function instead, which empties the map while keeping the underlying map object. This is a code-correctness fix that prevents potential runtime panics if the same map variable is later used after a reset callback runs, but it is not a clear-cut exploitable security vulnerability based on the diff alone.

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 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 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 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 swaps out one PGP public key for another in LND's release verification script. The old key belonged to the same person (ffranr/Robyn Ffrancon) and is no longer used; the new key is the current release signing key. There is no code vulnerability here—it's a routine key rotation. However, if someone could silently replace the key with an attacker's key, they could trick users into trusting fake LND releases. The commit itself appears legitimate and matches the stated purpose.