LND

This commit fixes a deadlock bug in LND's gossip message handler. When a malformed channel announcement was processed, two error messages could be sent on a channel that only had room for one. Because some callers never read from that channel, the second send would block forever. This prevented LND from shutting down cleanly. The fix simply increases the channel buffer from 1 to 2. The bug was found during fuzz testing and is not described by the vendor as a security vulnerability.

This commit simply updates a version number in a test configuration file so that LND's backwards-compatibility test checks against a newer release (v0.20.0-beta instead of v0.18.5-beta). There is no code change that affects how LND runs in production, and nothing in the commit suggests a security fix or vulnerability.

This commit only updates the release notes document to describe a previously fixed bug. The actual code fix (adding validation for the TrickleDelay setting to prevent a panic) is in a different pull request referenced by the notes. By itself, this documentation change does not alter any running software or introduce any security risk.

This commit changes LND's configuration validation so that if a user sets the 'TrickleDelay' option to zero or a negative number, it is automatically reset to 1 millisecond. TrickleDelay controls how long the node waits before sending out batched gossip messages to peers. A zero or negative delay could break the trickle timer, likely causing messages to be sent continuously or the timer logic to fail. The fix is defensive: it prevents a misconfiguration from disabling or overloading the gossip trickle mechanism.

This change only affects test code. It adds cleanup steps to close temporary test databases after unit tests finish. There is no effect on the production LND software or its users, and no security vulnerability is being fixed.

A bug in LND's cooperative channel close tracking caused the software to always label the close transaction as 'locally initiated', even when the other peer initiated it. This is a bookkeeping error in how close events are recorded, not a direct theft-of-funds bug, but it could mislead downstream logic that relies on accurate close-initiator information.

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 commit only adds new test code for an existing private-key tweaking helper in LND's Bitcoin wallet signer. It does not change any production code, fix a bug, or alter behavior. There is no security issue in the commit itself.

This commit loosens a GitHub workflow permission check so that external contributors—not just people with write access—can trigger an automated PR severity classifier. The workflow only reads pull request metadata and posts labels/comments using restricted GitHub CLI commands; it does not run code from the PR. The change is a deliberate relaxation of a guard that was causing false failures, not a fix for a code vulnerability in LND itself.

This is a small GitHub Actions workflow fix that changes how pull-request branches are checked out before running an automated 'Claude Code' review step. Previously, branches from forked repositories could not be found; the fix uses GitHub's 'gh pr checkout' command, which automatically adds the fork as a remote and fetches the correct branch. It is a CI/CD plumbing change, not a patch for a product vulnerability.

This commit changes a GitHub Actions workflow so it can run on pull requests submitted from outside forks. The change is intentional and the commit message explains why it is considered safe: the workflow only reads information about the pull request (like labels and changed files) and never downloads or runs code from the contributor's fork. There is no vulnerability in the diff itself.

This commit adds a new GitHub Actions workflow that automatically labels pull requests by severity based on which files they change. It is purely a repository automation/CI change and does not modify any of the actual Lightning node code that handles money, networking, or cryptography. There is no security vulnerability in this commit.

This commit adds a GitHub Actions workflow that lets people summon an AI assistant named Claude by mentioning '@claude' in issue or pull-request comments. It only reads repository contents, issues, pull requests, and CI results; it does not modify code or have dangerous permissions. There is no direct security vulnerability visible in the change itself.

This change adds new, more specific error labels to the router RPC so that subscribers watching payment events can see exactly why an invoice or AMP payment failed, instead of getting a vague 'UNKNOWN' result. It does not change how payments are validated or how funds are handled; it only improves the information reported over the API.

This commit only changes two log messages from warning level to debug level. It does not alter program logic, fix a bug, or change any security behavior. It is a cosmetic/logging-only change with no security relevance.

This commit increases several minimum CLTV (CheckLockTimeVerify) delta values in the LND Lightning node from 18 to 24 blocks. In the Lightning Network, these deltas are safety margins that give nodes enough time to react if a payment or channel state needs to be enforced on-chain. A larger delta makes certain timing-based attacks harder by extending the reaction window, but the commit itself does not fix a specific bug or add new checks. It is a policy hardening change rather than a patch for an active vulnerability.

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 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 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 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 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 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 new helper file that calculates how many Bitcoin confirmations LND should wait before treating a channel funding transaction as settled. The number of required confirmations now scales between 1 and 6 based on the channel size and any 'pushed' amount. There is no bug fix, vulnerability patch, or security-relevant behavior change visible in the diff; it appears to be a new feature or policy refinement.