LND

This commit only cleans up comments and adds more descriptive error messages in the cooperative channel-closing code. It does not change any security logic or fix a vulnerability.

This commit is a pure test-code refactoring. It takes three helper functions in a Go test file and splits each into two versions: one for non-taproot channels and one for taproot channels. The behavior being tested is unchanged; only the way the tests are organized is different. There is no production code change and no security fix or vulnerability introduced.

This commit fixes how LND parses signature fields during RBF (fee-bumping) cooperative channel closes. Previously, the code rejected valid protocol messages that contained both a 'closer-only' and a 'both-parties' signature, and it didn't always pick the right signature in the order required by the Lightning spec. The change makes signature selection follow the BOLT specification strictly, which prevents a peer from accidentally or deliberately stalling or breaking a cooperative close by sending a spec-compliant message.

This commit removes an unused error variable and widens a test generator's range. It is a cleanup/test-coverage change with no apparent security relevance.

This commit simply adds a directory named `.worktrees` to the `.gitignore` file. It tells Git to ignore that folder. There is no code change, no security fix, and no vulnerability introduced.

This commit updates how the Lightning Network Daemon (LND) exchanges special one-time cryptographic numbers (nonces) when a Taproot payment channel reconnects after being offline. It adds support for a new 'LocalNonces' field while keeping the old 'LocalNonce' field for older peers. The change is a protocol integration/cleanup rather than a clear fix for an active security bug, but mishandling these nonces can in principle weaken the multi-signature security of Taproot channels.

This commit only adds new test code for the LND Lightning wallet. It introduces helper functions and test cases that check how taproot channels synchronize cryptographic nonces during channel re-establishment, covering both a newer 'LocalNonces' map field and the older single 'LocalNonce' field. No production code is changed, so it does not fix or introduce a live security vulnerability by itself.

This commit only adds a documentation hint showing which lncli command maps to the SignPsbt API. It changes comments in a .proto file, a generated swagger JSON file, and generated Go gRPC code. There is no functional code change and no security relevance.

This commit fixes a simple but real programming bug: a logical 'and' was used where an 'or' was needed. In the LND lightning node software, when preparing a network ping message, the code asks for the latest Bitcoin block header. If that lookup fails and returns no header, the old code would try to use the missing header and crash the program with a nil pointer panic. The fix makes the code return a cached header whenever the lookup errors OR when the header hasn't changed, preventing the crash.

This commit is a routine, mechanical update of automatically generated protobuf Go code to match newer versions of the protobuf and gRPC libraries. The commit message explicitly states there are no functional differences. The visible changes are only in generated boilerplate: field ordering, removal of the `protoimpl.UnsafeEnabled` guard, use of the `unsafe` package for string-to-byte conversions of descriptor data, and newer protoc-gen-go version comments. No application logic, RPC definitions, or security behavior changed.

This commit changes a single line in a GitHub CI workflow file, bumping the pinned version of a Google gRPC library used during automated testing from v1.59.0 to v1.79.1. It does not modify any application code, cryptographic logic, network handling, or user-facing behavior. There is no indication in the commit that this fixes a known security vulnerability.

This commit updates several software building blocks (dependencies) used by the Lightning Network Daemon (LND), most notably the gRPC networking library from version 1.73.0 to 1.79.1, plus related Google and Go standard-library packages. The commit message says the new versions include bug fixes, but does not say any of those bugs are security issues. Because the diff only shows version number changes and no code changes, we cannot confirm from this commit alone that a specific vulnerability is being fixed. It is best treated as a routine maintenance update that may incidentally close known bugs in upstream libraries.

This commit adds a small helper function used only in tests. It creates a test-only object for constructing Lightning Network payment descriptors with specific values. There is no change to production code, no user-facing behavior change, and no security fix or vulnerability introduced.

This commit changes how Lightning Network channels check whether a special 'custom' payment (HTLC) can be added. Previously, bandwidth checks for these custom payments happened earlier, while routes were still being planned, and multiple payments could look at the same balance without knowing about each other. The new code moves the final check to the moment just before the payment is committed to the channel, using the most up-to-date balance and a corrected view of pending payments. It also fixes a bug where a height counter used in these checks was being left at zero. The change is defensive and aimed at preventing inconsistent or over-committed custom channel states rather than a classic remote exploit.

This commit only adds code comments (TODOs) suggesting a future cleanup: a database query currently returns a list of invoices, but because of the table's primary key it can actually return at most one. No code behavior is changed, so there is no security issue in this commit itself.

This commit fixes a flaky test in the LND project's backwards-compatibility test suite. It changes how often test nodes re-sync gossip information from once per hour to every 10 seconds, preventing a race condition where one node would miss channel announcements and get stuck. It also adds collection of debug logs when the test fails so developers can diagnose future failures more easily. There is no security vulnerability being fixed here.

This commit adds the ability for LND nodes to forward encrypted 'onion messages' through intermediate peers, rather than only sending them directly. It introduces new actor-based code for routing these messages, expands the RPC API response to expose more message details, and adds integration tests. There is no direct evidence in the commit that this fixes a known security bug; it appears to be a feature implementation. However, any new message-forwarding path can affect privacy, denial-of-service exposure, and correctness of cryptographic handling, so it warrants careful review.

This commit adds a new user-configurable switch that lets an LND node operator turn off support for "onion messages" (a type of Lightning network control message). When the switch is enabled, the node stops advertising that it supports the feature, does not create the internal component that handles those messages, and ignores incoming onion messages. It is a defensive feature addition, not a fix for an active bug or vulnerability, and it does not change default behavior.

This commit fixes a test-only comparison helper used when validating that old payment data can be moved from LND's older key-value database to the newer SQL database. The 'LegacyPayload' flag only mattered to the old database format and is not stored in SQL. The change makes the comparison ignore that flag so migrations with legacy-format hops don't falsely fail validation. It is not a runtime security fix and does not change how user funds or payment data are handled in production.

This commit is a routine Go module housekeeping change. It removes the '// indirect' label from a tiny helper library (go-difflib) so Go recognizes it as a direct dependency. There is no code change, no bug fix, and no security-relevant behavior change visible in the diff.

This commit is a defensive code-freeze: it copies the core payment database logic into a dedicated migration1 package so that future changes to the main payments code or serialization format cannot accidentally break or corrupt old payment data during upgrades. It is a hardening/refactoring change, not an active vulnerability fix, and it reduces the risk of migration bugs rather than introducing new exploit paths.

This commit is a minor cleanup in LND's payment database code. It removes a duplicate compile-time type check and reorders two table-drop statements in a database downgrade script. The author notes the reordering was not actually a bug because the database already uses CASCADE deletes. There is no apparent security vulnerability here.

This commit fixes a bug in LND's SQL payment database where the code was ignoring caller-provided timestamps and always using the current time when recording when a payment succeeded or failed. The fix makes stored timestamps match the actual event time, which is important for reliable automated tests and consistent record-keeping. There is no direct security exploit here.

This commit only adds a code comment (a TODO note) suggesting a future cleanup for payments that were started but never had an actual payment attempt registered. It makes no code changes that fix or alter behavior, so it does not by itself address any active security issue.

This commit removes one blank line in a test file to satisfy a code linter. It does not change any program logic, behavior, or security-relevant code.