LND

This is a database backwards-compatibility bug fix, not a security vulnerability. A previous version of LND changed how channel feature data is stored on disk, but the new code could not read old-format data. When users upgraded from v0.19.x to v0.20.x, the node would fail to read its own graph database and log an 'unable to decode features: EOF' error. The patch adds format detection so both old and new on-disk formats are accepted. There is no attacker-controlled path or remote exploit here.

This commit only adds a release note describing a previously fixed bug in LND's gossip subsystem. The actual code fix is in a separate pull request. The bug could cause the program to hang during shutdown if certain gossip messages triggered multiple error messages, but this commit itself changes only documentation and a contributor list.

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

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