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

payments/db: remap legacy zero attempt IDs

Public commit record

What the developer wrote

Authored by ziggie

68/100 · Adequate
payments/db: remap legacy zero attempt IDs

Legacy KV payments can contain HTLC attempts with attempt ID zero. The
SQL payments schema requires payment_htlc_attempts.attempt_index to be
globally unique, so migrating multiple such attempts can fail with a
UNIQUE constraint violation.

Allocate synthetic attempt indexes for legacy zero-ID attempts from the
switch payment ID sequencer horizon. Keep nonzero attempt IDs unchanged
and advance the switch sequence once after migration validation succeeds.

This preserves the SQL uniqueness invariant and prevents future switch
IDs from colliding with migrated attempts. It also wraps HTLC insert
errors with the attempted index and payment hash so future migration
failures identify the problematic row.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a database migration bug in LND where very old payment records could have HTLC attempt ID zero, which would collide under the new SQL schema's uniqueness requirement. The patch assigns synthetic unique IDs to those legacy attempts and advances the switch sequencer so future IDs don't overlap. It also fails any still-in-flight legacy zero-ID attempts before migration because they can't be safely resumed. This is a defensive correctness fix, not an exploitable vulnerability.

Recommended action

No immediate operator action required beyond applying the patch before migrating legacy nodes to the SQL payment store. Operators with very old LND databases upgrading to a SQL-backed release should ensure this commit is included. Review migration logs for warnings about terminalized legacy zero-ID attempts.

Security signals we found

01

Fixes data-integrity failure during KV-to-SQL migration (UNIQUE constraint violation)

02

Prevents future switch payment IDs from colliding with migrated legacy attempt IDs

03

Terminalizes unresumable in-flight legacy zero-ID attempts to avoid inconsistent live state

04

Adds defensive error context (attempt index, payment hash) for migration failures

05

Adds unit tests covering zero and advanced switch sequences plus unresolved in-flight legacy attempts

Risk score

Why this scored 41/100

Our methodology →
Potential impact 12/30
Exploitability 5/25
Stealth signal 4/15
Affected reach 8/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.