LND

This commit adds a small helper function that decides how many blockchain confirmations LND should wait before treating a channel close as final. In production it returns at least 3 confirmations, scaling up with larger channel capacities; in integration tests it always returns 1 to keep tests fast. There is no direct security bug here—it is a defensive reorg-protection measure and a code-organization change.

This commit only adds a new test file (lnwallet/confscale_test.go) with unit and property-based tests for existing confirmation-scaling helper functions. It does not change any production code, introduce new functionality, or modify security-relevant behavior. There is no indication of a security fix or vulnerability being addressed.

This commit only adds documentation to the release notes file. It describes two prior code changes: one that adjusts confirmation requirements for cooperative channel closes, and another that increases a minimum time-lock safety parameter (MinCLTVDelta) from 18 to 24 blocks. There are no code changes in this commit, so it cannot by itself introduce or fix a security bug.

This commit only adds a new helper method to a test mock and improves an error message in test code. It does not change any production code, network behavior, or security-sensitive logic. There is no security issue here.

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 tightens a safety setting in LND, the Lightning Network Daemon. It raises the minimum allowed CLTV delta—the time buffer built into Lightning invoices—from 18 to 24 blocks. The old minimum of 18 was below LND's own 19-block rejection threshold, so users could create invoices that other nodes would refuse to pay. The change prevents that mismatch but is a policy adjustment, not a fix for a code vulnerability that lets an attacker steal funds directly.

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 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 notifies wallets and user interfaces about a cooperative channel close. Previously, LND waited for a variable number of confirmations based on the channel's capacity before sending any success notification. Now it sends an initial notification after just one confirmation, then a final notification after the full required confirmations. It also adds a hidden configuration override for testing. The change is described as a UI-compatibility improvement, not a security fix.

This commit adds a new developer-only configuration option that lets tests force a specific number of blockchain confirmations for channel closes. It is gated behind integration/dev builds and does not change production behavior. There is no security issue visible in this patch.

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 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 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 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 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 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 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 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.