LND

This commit adds a GitHub Actions automation script that helps developers copy approved code changes from the main development branch to older release branches. It is purely a process improvement for maintainers and does not change any wallet, networking, or cryptographic code in the LND application itself.

This commit only updates the release notes document. It adds a one-line description of a previously merged bug fix (PR #10410) about graph database edges for a node's own channels. There are no code changes in this commit, so it cannot by itself introduce, fix, or enable any security issue.

This commit fixes a bug where Lightning Network channel edges created from a node's own channels were missing the 'funding script'—the on-chain Bitcoin script that locks funds in the channel. Without it, the routing graph builder could not properly track the channel's on-chain state (its ChainView), which could lead to stale routing data, incorrect channel visibility, or edge cases in pathfinding. The fix ensures the same helper used when opening real channels is used for these reconstructed edges.

This commit simply renames an internal helper function from lowercase `makeFundingScript` to uppercase `MakeFundingScript` so it can be used by other parts of the codebase. It is a routine code-refactoring change with no visible security relevance.

This commit fixes a timing bug in the LND Lightning node software that affected zero-confirmation channels. When a channel became publicly announced after six confirmations, the node would tell the network about the new channel ID before its own internal payment forwarding switch was ready to use that ID. On slow database backends, this created a brief window where payments routed through that channel could fail with an 'UnknownNextPeer' error. The fix simply reorders two internal steps so the switch is updated before the channel is announced to the network. It is a reliability fix rather than a vulnerability that allows theft or loss of funds.

This commit only adds a line to the release notes document for LND 0.20.1. It describes a previous bug fix (pull request 10439) that ensures a fee-estimation API includes required payment details when probing invoices. The commit itself changes no program code, configuration, or data handling—only documentation.

This commit fixes a bug in LND's router RPC code where a payment address was not being properly copied before use. The original code called `copy()` on a slice that had not been created yet, so nothing was actually copied. As a result, the payment address could be left empty when it should have contained a required 32-byte value. This could cause payment probes or related routing operations to behave incorrectly, potentially leading to failed payments or unexpected routing behavior.

This commit only adds documentation to the release notes describing two new MuSig2 RPC methods. It does not change any code, cryptographic logic, or API behavior. There is no security issue in the commit itself.

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 new experimental API methods to LND's MuSig2 multi-signature signing system, allowing a coordinator to register an already-aggregated combined nonce instead of each participant registering individual nonces. It is a feature addition, not a fix for a known security bug. The new RPCs are marked highly experimental and only work with the newer MuSig2 v1.0.0rc2 version; the legacy v0.4.0 implementation rejects them.

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 simply bumps a dependency version in LND's module files (go.mod and go.sum) from btcec v2.3.4 to v2.3.6. The commit message says the new version lets MuSig2 sessions register an aggregate nonce rather than individual nonces. There is no code change in LND itself, and no security relevance is stated by the project. Without inspecting the actual changes inside the btcec library, we cannot determine whether this update fixes a security bug or is just a routine feature/API improvement.

This commit is a build-system performance improvement, not a security fix. It changes how the project's linter Docker container stores its cache: on local developer machines it switches from slow folder-sharing (bind mounts) to faster internal Docker storage volumes, while in GitHub Actions CI it keeps using host paths so existing caching still works. There is no change to LND's runtime code, network behavior, or cryptographic handling.

This commit only adds a line to the release notes document for LND 0.20.1, describing a previously fixed SQL transaction exhaustion issue. No code was changed, so this commit itself does not introduce, fix, or alter any security-relevant behavior in the software.

This commit fixes a deadlock risk in LND's channel graph database code. Previously, the code could acquire a database transaction first and then try to lock a cache mutex. Other code paths lock the cache mutex first and then take a database transaction. When two different parts of the program follow opposite lock ordering, they can get stuck waiting on each other forever (a deadlock). The fix makes both paths acquire the cache mutex before starting the database transaction, ensuring consistent ordering and preventing the deadlock. The commit title calls this 'potential sql tx exhaustion,' which suggests the deadlock could eventually exhaust available database transactions and freeze the service.

This commit only adds a documentation note to the upcoming 0.21 release notes. It warns users that the old --sat_per_byte fee option will be removed in version 0.22 and tells them to switch to --sat_per_vbyte. No code was changed, so there is no direct security issue in this commit itself.

This commit only adds two new automated test jobs to GitHub Actions. It runs existing unit tests with a race-condition detector enabled for SQLite and PostgreSQL database backends. There is no code change to the LND application itself, no bug fix, and no security patch.

This commit only adds release notes describing previously fixed race conditions in LND's channel graph database. Race conditions can cause crashes or inconsistent data when multiple parts of the program access the same information simultaneously, but the actual code fixes are in a separate pull request referenced here. The commit itself does not change any program code.

This commit fixes a concurrency bug in LND's channel graph database. When disconnecting a block, the code was removing entries from internal caches without holding the proper lock, while other code paths correctly lock the same caches. This can cause data races, potentially leading to corrupted cache state, inconsistent channel graph views, or crashes under concurrent load.

This commit fixes a race condition in LND's graph database model. Two methods that return public keys for channel partners were caching parsed keys in struct fields without any synchronization. If multiple goroutines called these methods at the same time, they could write to the same memory field simultaneously, leading to undefined behavior or crashes. The fix removes the caching entirely and simply parses the key each time, because parsing is cheap and the cache wasn't worth the risk.

This commit fixes a subtle multi-threading bug in how LND retrieves a node's public key. Multiple parts of the program could call the same method at the same time, and because the method cached the parsed key in a shared field, several threads could try to write that cache simultaneously. That kind of race can corrupt memory or cause crashes in Go. The fix removes the cache entirely and simply parses the key on demand, which is fast enough that caching isn't worth the risk.

This is a small, ordinary code change that wires up a new optional component (an 'aux closer') to the chain arbitrator during server startup. It only adds plumbing: importing a package under a shorter alias and passing one more optional field into a configuration struct. There is no indication of a security bug, fix, or vulnerability in the diff or commit message.

This commit moves a finalization step for special auxiliary channel closes from the interactive negotiation phase to the point where the closing transaction is confirmed on-chain. The goal is to make the process more reliable by not depending on the remote party staying online and sending a message. The change itself is a refactor of when and where finalization happens, not a fix for a known exploit.

This commit adds a new optional hook (AuxChanCloser) that lets external code finalize cooperative channel closes. It is purely an infrastructure/plumbing change: it defines an interface, adds a config field, and passes that field into the chain watcher. There is no actual implementation of the closer logic, no change to existing security behavior, and no bug fix or vulnerability patch visible in the diff.

This commit is a straightforward internal code reorganization. It moves some data type definitions related to channel closing from one package to a new shared package so other parts of the program can use them without creating circular imports. No behavior changes, bug fixes, or security-sensitive logic changes are visible in the diff.