AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 46 Bitcoin

invoices/sql: replace catch-all GetInvoice with indexed lookups

Public commit record

What the developer wrote

Authored by ziggie

95/100 · Strong
invoices/sql: replace catch-all GetInvoice with indexed lookups

The GetInvoice query used an OR IS NULL pattern for each filter
parameter:

WHERE (i.hash = $1 OR $1 IS NULL)
AND (i.payment_addr = $2 OR $2 IS NULL)

SQLite's query planner decides on an execution plan at prepare time,
before seeing any parameter values. Because either condition can be
trivially true when its parameter is NULL, the planner conservatively
falls back to a full table scan rather than using the unique indexes on
hash and payment_addr. This caused every invoice lookup and update on
the hot path (HTLC settlement) to scan the entire invoices table.

Replace the single catch-all query with three dedicated queries, each
using a direct equality on a uniquely constrained column:

- GetInvoiceByHash: WHERE hash = $1
- GetInvoiceByAddr: WHERE payment_addr = $1 (new, covers AMP path)
- GetInvoiceBySetID: existing, unchanged

Update getInvoiceByRef to route to the appropriate query based on which
fields are present in the InvoiceRef. When both hash and payment address
are provided, we look up by hash and then verify the returned invoice's
payment address matches.

GetInvoice is now unused and removed from the SQLInvoiceQueries
interface.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a database performance bug in LND's invoice handling. The old code used a flexible query that could match by payment hash, payment address, or neither, which made the database scan the entire invoices table for every lookup. The new code uses specific, indexed queries so lookups are fast. The change also adds a check that prevents a caller from providing a payment hash and payment address that point to different invoices. There is no direct evidence in the commit that this was a security vulnerability, but the performance issue could contribute to denial-of-service under load.

Recommended action

Treat as a performance and hardening improvement rather than a critical security patch. Operators running LND with the SQL invoice backend should upgrade to benefit from faster HTLC settlement and reduced database load. Reviewers should confirm the new equivocation check does not break legitimate AMP or keysend invoice workflows.

Security signals we found

01

Full table scan on hot path (HTLC settlement) creates a potential denial-of-service vector via resource exhaustion

02

Added equivocation check when both payment hash and payment address are provided

03

No explicit security framing in commit message or diff

04

Performance fix rather than a memory-safety or cryptographic bug fix

Risk score

Why this scored 46/100

Our methodology →
Potential impact 12/30
Exploitability 5/25
Stealth signal 8/15
Affected reach 10/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.