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

sqldb+payments: add payment_duplicates for legacy duplicate payments

Public commit record

What the developer wrote

Authored by ziggie

85/100 · Strong
sqldb+payments: add payment_duplicates for legacy duplicate payments

Older LND versions could create multiple payments for the same hash.
We need to preserve those historical records during KV→SQL migration,
but they don’t fit the normal payment schema because we enforce a
unique payment hash constraint. Introduce a lean payment_duplicates
table to store only the essential fields (identifier, amount,
timestamps, settle/fail data).

This keeps the primary payment records stable and makes the migration
deterministic even when duplicate records lack attempt info. The table
is intentionally minimal and can be dropped after migration if no
duplicate payments exist.

For now there is no logic in place which allows the noderunner to
fetch duplicate payments after the migration.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit adds a new database table called payment_duplicates to help migrate old LND payment records into a new SQL database. Older versions of LND could accidentally create multiple payments with the same identifier, which conflicts with the new database's rule that each payment hash must be unique. The new table stores the extra duplicate records separately during migration so no data is lost. It is not a security fix and does not change how live payments are handled; it only preserves historical records.

Recommended action

No immediate action required. Treat as a database schema/migration change. Review the migration logic (not present in this commit) that populates payment_duplicates to ensure duplicates without attempt info are handled deterministically and that the fallback 'mark as failed' behavior is acceptable.

Security signals we found

01

New table preserves legacy duplicate payment records rather than deleting or merging them

02

Foreign key uses ON DELETE CASCADE, which is consistent with dependent data but means deleting a primary payment deletes its duplicates

03

CHECK constraint enforces outcome data presence, with migration-time fallback to marking unresolved duplicates as failed

04

No runtime query logic exposed to users; migration-only insert and an internal fetch query

Risk score

Why this scored 18/100

Our methodology →
Potential impact 2/30
Exploitability 0/25
Stealth signal 1/15
Affected reach 3/15
Confidence 8/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.