LND

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

This change tightens validation in LND's gossip message handling. It now rejects network announcements (channel updates and node announcements) that carry a timestamp of zero, which the Lightning BOLT specification forbids for channel updates. Remote peers sending zero-timestamp channel updates will also have their 'ban score' increased, moving them closer to being disconnected. The patch is defensive and does not appear to fix an active exploit, but it closes a spec-compliance gap that could be abused to propagate invalid routing data.

This commit only updates the release notes document for LND version 0.21.0. It adds two bullet points describing new user-facing features (explicit input selection in the EstimateFee RPC and a new --utxos flag in lncli) and adds one contributor name to the credits list. There are no code changes, no bug fixes, and no security-related content.

This commit only adds new integration tests for the EstimateFee RPC. It does not change any production code, wallet logic, or RPC behavior. There is no security issue here.

This commit adds a new command-line option to the `lncli estimatefee` command, allowing users to specify exact UTXOs (unspent transaction outputs) to use when estimating a transaction fee. Previously, the fee estimation relied on automatic coin selection. This is a feature addition that exposes an existing backend capability in the command-line tool; it does not, on its own, appear to fix or introduce a security vulnerability.

This commit simply moves a set of helper types and functions used for formatting Bitcoin transaction data from one internal package to another. It does not change what the code does, only where it lives in the project. There is no user-facing change and no security impact.

This commit updates the EstimateFee RPC in LND so that callers can optionally specify which wallet inputs (UTXOs) to use for the fee estimate, and the response now lists the inputs that were actually selected. It is a feature/enhancement change. There is no direct evidence in the commit that this fixes a security vulnerability; it mainly improves transparency and control for API users.

This commit only changes the API definition files (protobuf, generated Go code, and swagger JSON) for LND's EstimateFee RPC. It adds an optional 'inputs' field so callers can specify which transaction inputs to use when estimating fees, and the server can echo back the selected inputs. There is no server-side logic shown in this commit, and nothing in the commit message or diff indicates a security fix or vulnerability.

This commit removes a time-limited 'experiment period' for a new Lightning network signaling feature called 'accountable' (previously 'endorsement signal'). Previously, nodes would only relay this signal until a fixed date in 2026, after which they would stop. Now, because the latest protocol proposal says the default should be to send a zero/'unaccountable' value, there is no longer a privacy risk from relaying it, so the experiment end date is removed. The signal is now relayed whenever the feature is enabled, regardless of date. This is a protocol behavior change, not a fix for an exploitable security bug.

This commit is a pure rename of an experimental Lightning Network feature from 'endorsement' to 'accountable/accountability' to match a community proposal update. No security vulnerability is introduced or fixed; the underlying behavior, feature bits, TLV type, and experiment end date remain unchanged. It is a terminology and identifier refactor across 21 files.

This commit adds a startup repair routine for the LND Lightning node database. It fixes cases where a previous bug could delete 'link node' records even though the node still had open payment channels. On startup, LND now scans for missing link nodes and recreates them so the database stays consistent. The commit itself is a repair/cleanup patch, not an active vulnerability fix, but it addresses the after-effects of a prior race-condition bug.

This commit fixes a database race condition in LND (a Bitcoin Lightning Network implementation). When a channel closed, the software could incorrectly delete stored peer information ('link node') even though a new channel with that same peer had just been opened. The fix moves the 'check for open channels' and 'delete peer info' steps into the same database transaction, so they happen atomically and cannot be interrupted by another operation.

This commit fixes a logic bug in a small helper function called FlatMap used inside the LND codebase. FlatMap is supposed to transform a successful value and pass through failures unchanged. The old code did the opposite: it left successes alone and tried to transform failures, which could cause errors to be silently mishandled or successful values to be lost. The commit also adds unit tests to prevent the bug from returning.

This commit only updates integration tests to account for an experimental feature's activation window expiring. It does not change production code behavior or fix any security vulnerability. The new helper checks whether the endorsement experiment is still active and adjusts test expectations accordingly.

This commit only edits the release notes document for version 0.21.0. It describes a previously merged fix that makes certain data-parsing routines stricter about record sizes, and it adds a contributor name. The commit itself changes no program code, so it cannot directly introduce or fix a security issue.

This commit tightens validation for a message-encoding format (TLV) used inside the Lightning Network daemon lnd. Previously, several decoders would accept a record whose declared length did not match the fixed size they expected, which could let malformed or corrupted data be silently processed. The patch now rejects wrong-length records and adds tests to prove it. It is a defensive hardening change rather than a fix for a publicly disclosed exploit.

This commit fixes a minor logging issue in LND's peer connection code. Previously, the software would always print a debug message saying it was waiting for a peer to finish starting up, even when that wasn't true. The change makes the log message appear only in the actual waiting case. There is no security impact.

This commit only adds a line to the release notes describing a previous performance improvement. It does not change any code, configuration, or behavior. There is no security issue here.

This commit only adds a new performance benchmark test for an existing database query. It does not change any production code, fix any bug, or alter any behavior that users or attackers could interact with.

This commit rewrites a single database query so that it checks two possible relationships as separate sub-queries combined with UNION ALL, instead of using OR inside one JOIN condition. The goal is to make SQLite run the query faster by using its indexes better. The result returned to the application is unchanged, so this is a performance fix, not a security fix.

This commit fixes a timing bug in LND's internal test helper. The helper previously returned too early when sending test payments, before all payment commitments were fully recorded on the channel. This caused occasional flaky test failures because tests captured channel state at the wrong moment. The fix makes the helper wait until every sent payment appears as a pending HTLC. There is no indication this affects real user funds or production code paths.

This commit only changes an integration test to accept either of two valid failure reasons for a payment, fixing a flaky test. It does not change production code or fix a security vulnerability.

This commit only edits the release notes document for LND 0.20.1. It adds a description of a previously merged bug fix (PR #10449) that could cause startup failures due to timestamp comparison issues. The commit itself does not change any executable code, so it cannot directly introduce or fix a security vulnerability. It is purely documentation.

This commit fixes a bug in the LND Lightning node where it compared only the seconds part of timestamps (e.g., the :30 in 12:00:30) instead of the full Unix timestamp when deciding whether to update its own network announcement. Because of this, a node could try to save an announcement with an older timestamp than what was already in its database, which the database rejected with a 'no rows in result set' error. The fix makes the comparison use the full timestamp, preventing restart failures and ensuring the node can rejoin the network properly.