LND

This update fixes a bug in how LND handles old-style punishment transactions when a channel partner tries to cheat. Previously, tiny (dust) HTLCs were left as blank placeholder entries in the punishment data, which could cause the node to crash or behave incorrectly when trying to claim funds back. The fix removes those blank entries and adds safety checks further down the line.

This change tightens how LND reads Lightning invoices (BOLT 11). Previously, if an invoice contained more than one payment hash field, LND would silently keep the first one and ignore the rest. Now it rejects the invoice entirely. The release notes frame this as an interoperability improvement rather than a security fix, but the behavior removes a potential source of confusion or invoice manipulation where a second, different payment hash could be present but ignored.

This change tightens how LND reads Lightning invoices. Previously, if an invoice contained more than one payment hash field, LND would silently keep the first valid one and ignore the rest. Now it rejects such invoices outright. This prevents an attacker from potentially tricking a wallet into interpreting a different payment hash than intended, which could lead to payments being sent to the wrong destination or failing in unexpected ways. The fix is being backported to two release branches.

This change fixes how LND answers network 'ping' messages from other Lightning nodes. Previously, LND would sometimes silently ignore valid pings to limit reply traffic, which violates the Lightning protocol (BOLT 1) and could make a peer think the connection is dead. Now LND replies to every valid ping, while still disconnecting peers that flood too many pings. The cost of a reply is counted against a single flood budget based on how large the reply would be.

This change fixes a bug in LND's handling of AMP (Atomic Multi-Path) payments. Previously, if one partial payment set failed to reconstruct its secret preimage, the entire invoice was canceled, including unrelated partial payment sets from other payers. Now only the failing set is canceled, and the invoice stays open so other valid sets can still complete and settle. This is a correctness/availability fix for reusable AMP invoices.

This commit updates the Go programming language version used to build LND from 1.25.13/1.26.6 to 1.26.8 (language version) and 1.27.1 (toolchain). It also regenerates many automatically generated RPC files and adjusts linter settings. The main security angle is that newer Go releases typically fix bugs and security vulnerabilities in the Go runtime and standard library, so staying current is good defensive hygiene. However, the commit itself does not describe any specific vulnerability being fixed, and the code changes are mostly version bumps and generated file updates rather than targeted security patches.

This commit is a routine build-maintenance change. It updates the project's Go linter configuration to a newer version and fixes the resulting style warnings: a WebSocket header spelling and several documentation comments that didn't start with the correct symbol names. There is no functional code change that affects security.

This commit is a housekeeping change that regenerates automatically generated RPC binding files using a newer Go compiler version. The only differences are in code comments (doc-comment formatting), not in actual program logic or API behavior. There is no security impact.

This commit is a routine build-and-test maintenance patch to make the LND codebase compile and pass tests with the upcoming Go 1.27 release. It upgrades the project's custom linter tool, refreshes many indirect tool dependencies, adjusts one test's formatting, and lowers a test constant that checks how many compressed channel IDs fit in a Lightning message. There is no direct security fix here; it is a compatibility and test-hygiene change.

This commit is a routine maintenance update that changes which version of the Go programming language is used to build the lnd project. It does not change any application logic, fix a bug, or address a security vulnerability. The project is simply moving its build tooling to a newer Go release and keeping the minimum required Go version current.

This commit fixes a bug in LND's invoice handling for reusable AMP (Atomic Multi-Path) invoices. Previously, if one payment set failed to reconstruct its preimage, the entire invoice was canceled, even though other valid payment sets on the same invoice were unaffected. Now, only the failing set is canceled, and the invoice stays open so other payers can still complete their payments. This is a correctness and availability fix for a specific Lightning Network payment feature.

This commit adds the missing cryptographic signature layer for BOLT 12 offers in LND. It builds a Merkle tree from the message fields, signs that tree with a BIP-340 Schnorr signature, and now rejects invoice requests and invoices whose signatures do not verify. It also tightens decoding so non-minimal encodings of feature bits and amounts are rejected, preventing a message from being accepted in one form but re-encoded into a different byte form that would break the signature.

This commit adds a new optional wallet feature to LND that lets users lock UTXOs until the transaction spending them reaches a chosen confirmation depth, instead of relying on a wall-clock timeout. It is a feature addition with safety checks (required custom lock ID, capability checks, rollback on partial failure) and is not a fix for a known exploit. The main risk is that a bug in the new reorg-aware lease logic could keep coins locked longer than intended or, in a worst case, allow double-spending of locked UTXOs, but the diff itself does not show such a vulnerability.

This commit is a large internal code reorganization for the LND Lightning node. It moves channel state storage logic from the `channeldb` package into a new `chanstate` package, while keeping the same database keys, serialization formats, and public behavior. There is no new feature or obvious security fix in the visible diff; it is primarily a refactoring to separate concerns.

This change fixes a data-handling bug in LND's channel-opening code. When opening a Lightning channel using an optional 'auxiliary funding controller' (used for custom channel types such as Taproot Assets), the funding manager was previously passing an incomplete channel state object that lacked the negotiated local and remote channel settings. The patch adds a new method that builds a complete view including both sides' agreed configuration, and updates the funding manager to use it. There is no direct evidence this is exploitable as a security vulnerability; it appears to be a correctness fix that could prevent misbehavior or failures in custom channel flows.

This change makes LND's BOLT 12 invoice and invoice-request reader actually check that the digital signature is valid, instead of only checking that a signature field exists. Before, an attacker could craft or modify a BOLT 12 message and include any 64-byte placeholder as a 'signature'; the reader would accept it as long as the field was present. Now the reader verifies the signature cryptographically against the claimed sender public key, rejecting forgeries and tampered messages. This is a security-hardening fix that closes a real authentication gap.

This commit only adds a new integration test for an existing feature called confirmation-controlled leases. It does not change production code, so it cannot introduce a security vulnerability or fix one directly. The test exercises how long a wallet lease stays locked under various conditions (time passing, blockchain reorganization, node restart, and multiple confirmations).

This update fixes two security-related bugs in LND's REST WebSocket proxy. First, a specially crafted WebSocket protocol header could crash the proxy (a panic). Second, the proxy previously had no limit on how large an incoming WebSocket message it would accept, which could let an attacker exhaust server memory. The patch caps incoming message sizes and correctly parses the protocol header as a comma-separated list.

This commit adds release notes for two fixes in LND's REST WebSocket proxy: one that could crash the proxy with a malformed header, and another that limits how large incoming WebSocket messages can be. The actual code changes happened in a different pull request; this commit only documents them.

This commit adds release notes for two fixes in LND's REST WebSocket proxy. One fix prevents a server crash (panic) triggered by a malformed WebSocket protocol header. The other fix limits how large incoming WebSocket messages can be, rejecting oversized frames early. Both are defensive hardening changes, but the commit itself only documents them; the actual code changes are in a different pull request.

This patch fixes a bug in LND's cooperative channel-closing logic where extra 'auxiliary' outputs (used by custom/taproot channel types) were not counted when the initial closing fee was first estimated. If the fee was too low, the resulting close transaction could be rejected by the Bitcoin network's mempool. The fix adds a new 'shape' query so the closer knows the size of these extra outputs up front, includes them in the fee calculation, and then verifies that the final outputs match the declared shape before signing.

This update to the LND Lightning node software fixes two security-related bugs. First, it prevents a connected peer from exhausting the node's memory or CPU by sending floods of ping messages or by forcing the node to queue too many outbound messages. Second, it fixes a signature mismatch in channel-update messages that carry inbound fees, so updates are signed exactly as they are broadcast and unknown extra data is preserved. The release notes explicitly describe both as preventing peer-controlled resource exhaustion and remote signature failures.

This commit only adds documentation to the release notes describing a new WalletKit feature: output leases can now optionally stay active until a spending transaction reaches a chosen confirmation depth. There is no code change, no bug fix, and no security-related content in the commit itself.

This change fixes a bug in LND's wallet RPC code that handles locking multiple bitcoin inputs at once. Previously, if locking one input failed after earlier inputs were already locked, the rollback tried to unlock the earlier inputs using LND's internal lock ID instead of the caller's actual lock ID. That meant the earlier locks might not get released, leaving funds stuck or unavailable. The patch makes the rollback use the real lock ID recorded for each acquired lease, and also rolls back on metadata lookup failures, not just lease failures.

This commit adds a new optional feature to LND's wallet RPC that lets callers lock a coin (a 'UTXO lease') until the transaction spending it reaches a chosen number of confirmations, instead of relying only on a clock-time expiration. It also exposes more lease information in responses and lists. The change is defensive: it checks wallet support before locking, rejects unsupported wallets, requires a caller-chosen lock ID for the new mode, and preserves the old time-based behavior when the new option is not used. There is no direct evidence in the commit of a fixed vulnerability; it reads like a capability addition with safety checks.