LND

This commit only reformats two function definitions in a database helper file, changing how the code is split across lines. There is no change to program logic, SQL queries, or security behavior.

This commit adds a missing database method called FailAttempt for the new SQL backend in LND's payment database. It simply records when an individual payment attempt (HTLC) fails, including the reason and timestamp. There is no security vulnerability visible in the change; it is a normal feature-completion patch that brings the SQL backend in line with the existing KV backend.

This commit refactors internal database helper functions in LND's payment database code. It removes the reliance on a pointer to the SQLStore object and instead passes the database query configuration and transaction handle directly. The stated goal is to make the code more robust by ensuring the helpers use the provided database transaction rather than accidentally creating a new one. There is no direct evidence in the commit of a fix for an exploitable security vulnerability.

This commit adds a missing database method (RegisterAttempt) for the new SQL backend in LND's payment subsystem. It is a feature-completion change that stores HTLC attempt details in the SQL database. There is no indication of a security bug or vulnerability fix in the code or commit message.

This commit adds a missing database method called SettleAttempt to LND's new SQL-based payments storage backend. It records when a Lightning payment attempt succeeds, including the cryptographic proof (preimage) and the settlement time. There is no indication in the commit that this fixes a security vulnerability; it appears to be ordinary feature completion work.

This commit adds a validation check in LND's payment database to ensure that blinded (privacy-preserving) Lightning payments always include a total amount on the final hop. Without this check, a missing total amount could lead to incorrect accounting or routing behavior for blinded payments. The change is defensive and does not appear to fix an active exploit, but it closes a gap where invalid payment data could be stored.

This commit only adds a documentation comment warning future developers that a function must be called serially for the same payment. It does not change any code behavior, fix a bug, or add synchronization. It is a code-comment-only change with no direct security effect by itself.

This commit adds a missing database cleanup feature for the SQL backend of LND's payment database. It lets the node delete failed payment attempts after a payment finishes, matching behavior that already existed for the older key-value database backend. There is no obvious security vulnerability in the change; it is a feature-completion patch with a defensive guard that refuses cleanup while a payment still has active/in-flight HTLCs.

This commit adds a missing database method called DeletePayment for the new SQL backend of the LND Lightning node. It simply wires up an existing delete capability that was already available in the older KV database backend, so that both storage backends behave the same way. There is no indication this introduces a security bug; it is a routine feature-completion patch.

This commit adds new database helper functions for storing payment-related records in LND's SQL backend. It is purely an infrastructure/CRUD addition: more INSERT statements and generated Go wrappers. There is no bug fix, no logic change, and no security-sensitive behavior visible in the diff.

This commit adds a new database method called InitPayment for the SQL backend of the Lightning Network Daemon (LND). It is a feature implementation that creates a new payment record while checking whether a payment with the same hash already exists. If an existing payment failed, it deletes the old record and allows a retry; otherwise it returns an error. There is no direct evidence in the commit that this fixes a security vulnerability, but it does touch payment lifecycle logic and transaction handling, which are security-sensitive areas.

This commit adds two new database helper functions for deleting payment records and failed payment attempts in LND's SQL backend. It is purely an infrastructure change: the new functions are defined but not yet called anywhere in the code, so it cannot by itself cause data loss, unauthorized deletion, or any other security issue. It simply prepares the database layer for future features such as payment cleanup or pruning.

This commit restructures how a Lightning Network node stores payment records in its database. It changes the relationship between a 'payment intent' (such as a BOLT 11 invoice) and an actual payment from one intent possibly linked to many payments, to exactly one intent per payment. It also makes the intent record refer to the payment and automatically delete if the payment is deleted. There is no direct security vulnerability visible in the diff, but any schema migration in a financial database needs careful review for data integrity and correctness.

This commit only improves the explanatory text (godoc comments) above several internal database helper functions. No program logic, queries, or behavior were changed. It is purely a documentation cleanup and has no security relevance.

This commit adds a new, more efficient database query that retrieves only the final resolution status of HTLC (payment attempt) records for a single payment, rather than fetching all attempt details. It is a straightforward performance and code-organization change with no visible security implications.

This commit adds a new SQL database implementation for listing and filtering Lightning Network payments. It is a feature/refactoring change that moves existing payment-query logic to a new SQL backend. There is no indication in the commit that it fixes a security bug or introduces a vulnerability.

This commit adds a new database helper function that retrieves a single Lightning payment record from the new SQL-based storage backend. It is a routine feature implementation with no visible security bug.

This commit only adds a single line to the release notes document, describing a recently merged code change (new query methods for a payments database SQL backend). It does not modify any program code, configuration, or security controls.

This commit only adds a new internal error constant called errMaxPaymentsReached to the payments database error definitions. There is no functional code change, no bug fix, and no security-relevant behavior introduced. It appears to be preparatory groundwork for future pagination logic.

This commit adds new database read-only queries for the QueryPayments feature in LND. It does not change any existing logic, fix a bug, or alter security-sensitive behavior. It is purely adding data retrieval capabilities for payments, HTLC attempts, route hops, and custom records.

This commit is a routine database schema update for LND. It adds a unique index to prevent duplicate payment intents and improves a code comment explaining how failure messages are stored. There is no security-relevant change visible in the diff.

This commit only adds new database tables for tracking Lightning Network payments. It is a schema-only change with no application logic, no bug fixes, and no security-related behavior. There is nothing here that could be exploited.

This commit only updates the release notes document for version 0.21.0. It adds a short description of a payment store improvement project and adds two names to the contributor list. No program code was changed, and there is no security relevance.

This commit only changes a development-only test configuration file so that an existing database schema migration for payments is also applied during a specific test mode (test_native_sql). It does not alter production code, add new migrations, or change any runtime behavior. There is no security issue visible in the diff.

This commit is purely preparatory infrastructure. It adds scaffolding for a future SQL-based payments database backend in LND, but explicitly does not implement any actual payment database methods yet. The new SQL store currently falls back to the existing key-value store implementation to satisfy build requirements. There is no security-relevant behavior change or vulnerability introduced in this patch.