LND

This commit adds new integration tests for the Lightning Network Daemon (LND). The tests check what happens when a payment is deliberately held by an external interceptor and the underlying channel is force-closed on-chain. The commit message and comments describe two related bug paths: after a restart, an on-chain held HTLC could be accidentally dropped when a new block is mined because it lacked an auto-fail height; and without a restart, an old off-chain held entry could block settlement from reaching the on-chain resolver. The commit itself only adds tests, not fixes, so it documents and reproduces the issue rather than changing production code.

This commit adds a new data structure and serialization code for BOLT 12 invoice requests in the LND Lightning node. It is purely an implementation of a protocol message format and includes a round-trip test. There is no indication in the commit that it fixes a security bug or introduces a vulnerability.

This commit updates a GitHub Actions workflow that runs an automated code-review bot called 'gateway'. It bumps the bot's version from v0.4.3 to v0.4.4 and removes a hardcoded numeric 'installation_id'. The new version figures out the correct installation ID automatically from the app's credentials. The change is a routine dependency/maintenance update for a CI/CD automation tool, not a fix for a known vulnerability in the LND software itself.

This commit is a simple spelling cleanup. It renames a field called 'OutgoingCTLV' to the correctly spelled 'OutgoingCLTV' throughout the codebase and fixes related typos in comments. CLTV stands for 'CheckLockTimeVerify,' a Bitcoin time-lock feature. There is no functional change to how the software behaves.

This commit only edits the release notes document. It describes a previously merged code change that tightens validation of time-lock settings for Lightning payments, but the commit itself contains no code changes and therefore does not alter software behavior or fix a bug directly.

This change fixes a mismatch between how Lightning Network payment checks are done while a payment is still flowing through the network versus when the channel is forced on-chain. Previously, the on-chain resolver could settle an exit-hop HTLC even if its amount or expiry did not match the invoice's final-hop rules, because it only checked the preimage. Now the on-chain resolver applies the same final-hop validation as the regular link path, and refuses to settle invalid final HTLCs. A special hook is preserved for custom/auxiliary HTLCs so they can still use their own amount validation.

This commit adds validation checks to make sure a Lightning node's configured CLTV expiry limits and advertised channel policies stay within the same supported range. Previously, a node operator could configure settings that were internally inconsistent or advertise forwarding delays that the node was not actually willing to accept, which could lead to payment routing failures or unexpected channel behavior. The change prevents misconfiguration rather than fixing an active exploit.

This commit tightens the checks that Lightning nodes perform when they are the final recipient of a payment. It makes sure the payment's time-lock expiry is not unreasonably far in the future, matching the same limit already used when forwarding payments. It also moves the final-hop amount and time-lock checks into a shared helper so invoice creation and HTLC handling stay consistent. The change is defensive and reduces the risk of abuse involving very long-dated payment locks, but the commit message does not frame it as a security fix and no CVE or advisory is referenced.

This commit is just a documentation update adding a release note for a previously fixed bug. The actual bug was a crash (panic) in LND's DNS fallback code: when looking up network routing information, the program assumed every answer from a DNS server would be a specific record type (SRV). If a DNS server returned a different kind of record, the program would crash. The fix also handled an empty lookup result safely. This release note describes that earlier code fix; the commit itself does not change any program code.

This commit only removes a sentence from the release notes document for version 0.22.0. It does not change any program code, so it cannot by itself introduce, fix, or alter a security vulnerability. The deleted text described a previously documented bug fix (a daemon crash caused by mishandling DNS records), but the actual code change was made elsewhere and is not present in this commit.

This commit is mostly a cleanup patch: it wraps long lines caused by a recent library rename and, importantly, adds a missing error check around a call that loads a Bitcoin transaction filter. The error check prevents a silent failure where the node might continue without realizing its filter was not updated, which could affect routing/chain monitoring. There is no direct evidence this is exploitable as a security vulnerability.

This is a large dependency upgrade for the LND Lightning node software. It moves LND from older btcd Bitcoin library packages to new 'v2' packages and updates related wallet and network libraries. The commit is almost entirely mechanical import-path changes and version bumps. It does not appear to fix a specific known security bug on its own, but it pulls in newer upstream versions that may contain security fixes. Because the change touches 605 files and many core Bitcoin-handling modules, any mistake in the migration could affect transaction parsing, address handling, or cryptographic operations, so it should be reviewed and tested carefully.

This commit only adds a release note describing a previously fixed bug in LND's DNS fallback code. The actual code fix is not shown in this commit. The bug could crash the LND daemon (a panic) if a DNS response contained unexpected record types during a special service-location lookup, or if a host lookup returned no results. Because this is just documentation, the immediate code risk is low, but the described underlying issue was a real crash bug.

This commit fixes a bug in LND's DNS seed bootstrap code that could crash the node. The code assumed every record in a DNS response was an SRV record, so a non-SRV record (like a normal A or CNAME record) would cause a panic. The fix safely skips non-SRV records and also handles cases where the DNS lookup returns no addresses at all. The commit message says the bug is hard to exploit because it requires a malicious DNS server or a network attacker, and such attackers already have easier ways to disrupt a node.

This change is mostly documentation and a small code cleanup for LND's onion message streaming API. It clarifies that one field (the 'introduction_node' in a reply path) can arrive in two different formats: a regular 33-byte public key, or a compact 9-byte 'short channel ID + direction' form. The commit also refactors the code so that when no reply path exists, the API returns a true null instead of an empty placeholder struct. There is no direct security fix here, but the documentation reduces the chance that API consumers will misinterpret the data and build broken or unsafe replies.

This commit fixes a bug in how LND's Tor controller shuts down. Previously, during startup cleanup, the controller would try to delete an onion service that might never have been created, which could hide the real reason why creating the onion service failed. The fix only deletes the onion service if it was actually created, and makes shutdown more robust by always closing the Tor control connection and reporting both cleanup errors clearly.

This commit adds a safety net around LND's RPC handlers so that if a handler crashes (panics), the entire lnd process is no longer taken down. Instead, the crash is caught, logged with a stack trace, and the caller receives a generic 'internal server error.' This is a defensive hardening change that improves availability and makes it harder to turn a bug into a denial-of-service attack.

This commit adds a new optional GitHub Actions workflow that lets maintainers trigger an automated code-review bot by typing '/gateway review' on a pull request. It is purely an infrastructure/configuration change and does not alter any LND node code, cryptography, or network behavior. The workflow is comment-triggered only, uses pinned commit references, and minimizes token permissions, which are defensive design choices rather than fixes for any known vulnerability.

This commit only adds a new release notes document for version 0.21.1. It contains no code changes. The document itself describes a prior bug fix about Tor onion service key types, but the commit under review is purely documentation.

This commit only bumps the version of an internal Tor-related Go module from v1.1.6 to v1.1.7 in the project's dependency files. No actual code changes are included, and the commit message does not say what changed in the new module version or whether it fixes a security issue. On its own, this patch is just a routine dependency update with no visible security impact.

This change only modifies the developer Dockerfile to use Docker BuildKit cache mounts for Go build caches, making image rebuilds faster. It is a build-performance improvement with no security relevance.

This commit only adds a release note describing a previously fixed bug. The actual code fix is in a separate pull request. The bug caused LND's ListChannels report to incorrectly show 100% uptime for peers that were actually offline, because the channel fitness store wrongly assumed peers were online when it first started tracking them. The release note explains uptime is now seeded from the peer's real connection state. There is no new code change here, so this commit itself does not introduce or fix a security vulnerability.

This commit fixes a bug in LND's channel-fitness subsystem that made offline peers falsely appear to have 100% uptime. The fix seeds the initial uptime state from the peer's real connection status instead of always assuming online. It is a correctness/telemetry bug, not an exploitable security vulnerability.

This commit updates the software's dependency list for the Tor-related sub-package, bumping the btcd library from version 0.24.2 to a newer pre-release (0.26.0-beta.rc1) along with several supporting libraries. There are no actual code changes shown—only the files that record which library versions are used. Because the commit message says only 'use latest btcd' and no security issue is described, this looks like a routine dependency refresh rather than a confirmed security fix. However, dependency updates can sometimes include security patches from the upstream libraries, so it is worth monitoring the release notes for btcd and the related Go packages.

This is a routine dependency update for a small internal module of the LND Lightning node software. It switches from an older monolithic btcd package to newer, versioned submodules and updates a few related libraries. There is no indication in the commit that this fixes or introduces any security problem; it appears to be ordinary maintenance to keep dependencies current.