LND

This commit is a simple code cleanup in LND. It removes an inline calculation that decided how many confirmations a new Lightning channel needs before being considered open, and replaces it with a call to a new helper function named FundingConfsForAmounts. The change itself does not appear to alter the security behavior; it just moves the same logic into a shared helper. There is no indication of a security fix or vulnerability.

This commit is a pure internal code cleanup in LND's contract court. It moves duplicated spend-handling logic into a single helper function without changing the actual behavior. There is no security fix or externally visible change.

This commit only adds new automated unit tests for how LND's chain watcher behaves when a cooperative channel-close transaction is affected by a Bitcoin blockchain reorganization (re-org). It does not change any production code, so by itself it cannot introduce or fix a live security vulnerability. The tests verify that if one version of a cooperative close transaction is reorganized out, the watcher can detect an alternative version and confirm the correct final spend.

This commit adds a new integration test for the Lightning Network Daemon (LND). It checks that if a cooperative channel close transaction is replaced by a higher-fee version, then a blockchain reorganization occurs, and finally the original transaction gets confirmed, the software still recognizes the channel as properly closed. It also makes two small timing fixes in an unrelated test to make it more reliable. There is no production code change and no direct security fix.

This commit only adds new automated tests for how LND's contract court handles blockchain reorganizations (re-orgs) across different channel close types. It does not change any production code, so it cannot introduce a security vulnerability or fix one directly. The tests are defensive: they verify the system eventually detects the correct final transaction after a re-org.

This commit only updates test code to match new behavior in the chain watcher component. It does not change any production code, so it cannot directly introduce a security vulnerability or fix one in running software. The tests now simulate waiting for a transaction confirmation after detecting a spend, reflecting a change made elsewhere in the codebase.

This commit only adds a new test helper file for the contractcourt package. It contains no production code changes, no bug fixes, and no security-sensitive logic. It is purely test infrastructure to make future chain-watcher tests easier to write.

This commit changes how LND watches for channel-closing transactions on the Bitcoin blockchain. Previously, the code might act immediately when it saw a spend, which could be risky if the blockchain later reorganized (a 're-org') and removed that transaction. Now it waits for a configurable number of confirmations before processing the close, and can reset cleanly if a re-org happens. This reduces the chance of LND taking wrong actions (for example, failing to punish a breach or incorrectly marking a channel closed) during temporary blockchain reorganizations.

This change adjusts how many Bitcoin block confirmations LND waits before telling users a Lightning channel is successfully closed. For cooperative closes, it now scales the wait based on the channel's size (larger channels wait more confirmations) instead of always using 1 confirmation. For force closes, it keeps 1 confirmation for user notifications because a separate internal safety mechanism handles the real security waiting. This is a defensive hardening improvement, not a fix for an active exploit.

This commit adds a new internal setting called ChannelCloseConfs that lets developers override how many blockchain confirmations LND waits for before acting on a channel close. It is explicitly marked as only for dev/integration builds and testing. There is no actual logic change in this commit—it only threads the new parameter through several configuration structs so it can be used later.

This commit adds a special fast-path in LND's channel close watcher. When only one confirmation is needed (which only happens in integration tests), it immediately processes a channel close instead of waiting for the normal multi-confirmation safety check. This is described as a test-only optimization to fix flaky tests, not a production security fix. In normal production use, the code still waits for multiple confirmations before treating a channel close as final, preserving protection against blockchain reorganizations.

This commit is a simple backward-compatibility rename. It brings back an old configuration option name ('no-experimental-endorsement') as a hidden alias for the new name ('no-experimental-accountability'), so users with the old option in their config files won't have their node fail to start after the rename. There is no security bug or behavior change beyond the alias.

This is a minor test-only code change that updates a unit test to satisfy a stricter Go compiler/static analysis rule introduced in Go 1.24. It does not change any production code, user-facing behavior, or security-sensitive logic.

This commit only updates the release notes document. It adds a description of a previously fixed bug related to the `fund_max` option when opening a Lightning channel. The actual code fix happened in an earlier pull request, so this commit does not change any program behavior or fix any vulnerability itself.

This commit only adds a new automated integration test. It does not change any production code, so it cannot introduce a runtime security vulnerability by itself. The test checks that a feature called 'fundMax' opens a channel at the protocol-level maximum size rather than a smaller user-configured limit. The commit message and code comments explain the intended behavior, but there is no patch to the actual funding logic here.

This fix corrects a bug in LND's OpenChannel RPC when the 'FundMax' option is used. Previously, the code wrongly used a configuration setting meant only for incoming channels (maxChanSize) as the upper limit for outgoing channels opened with FundMax. Now it uses the proper protocol-level maximum, which prevents users from accidentally being limited to a smaller channel size than the network actually allows. This is a correctness/availability issue rather than a direct theft-of-funds vulnerability, but it could cause unexpected channel-opening behavior or failed transactions.

This commit simply updates the minimum required Go programming language version from 1.24.9 to 1.24.11 across LND's build files and installation instructions. It is a routine maintenance change, not a security fix or vulnerability patch. There is no indication in the commit that this addresses any specific security issue.

This commit simply updates the version of the Go programming language used to build LND from 1.25.3 to 1.25.5 across CI, release, and Docker configuration files. It is a routine build/toolchain maintenance change with no direct security-relevant code modifications visible in the diff.

This commit only updates test code to satisfy a new Go linter rule. It replaces context.Background() with t.Context() inside four unit tests. There is no change to production code and no security relevance.

This commit only changes a linter configuration file. It tells the project's Go linting tool to enforce a specific style rule about test code. There is no change to the actual LND software that runs on nodes, and no security issue is present.

This commit only adds a line to the release notes describing a previously merged code change (panic recovery in the gossiper). It does not modify any program code, so it cannot by itself introduce or fix a 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 adds a safety net around the Lightning node's gossip message handling. Previously, a programming bug (panic) while processing network gossip could crash the whole goroutine or leave related tasks waiting forever. The new code catches such panics, logs them, frees resources, notifies waiting tasks, and reports an error back so the node keeps running. It is a defensive hardening change, not a fix for a known active exploit.

This change tightens validation in LND's gossip message handling. It now rejects network announcements (channel updates and node announcements) that carry a timestamp of zero, which the Lightning BOLT specification forbids for channel updates. Remote peers sending zero-timestamp channel updates will also have their 'ban score' increased, moving them closer to being disconnected. The patch is defensive and does not appear to fix an active exploit, but it closes a spec-compliance gap that could be abused to propagate invalid routing data.

This commit only updates the release notes document for LND version 0.21.0. It adds two bullet points describing new user-facing features (explicit input selection in the EstimateFee RPC and a new --utxos flag in lncli) and adds one contributor name to the credits list. There are no code changes, no bug fixes, and no security-related content.