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

paymentsdb: normalize orphaned blinded total

Public commit record

What the developer wrote

Authored by ziggie

78/100 · Adequate
paymentsdb: normalize orphaned blinded total

The KV route format stores blinded fields independently. Routes accepted
through SendToRouteV2 could therefore contain a blinded total amount
without encrypted recipient data. The SQL migration treated the total as
proof of a blinded hop and bound nil to the required encrypted-data
column, preventing LND from starting.

Use encrypted recipient data as the blinded-hop discriminator and
normalize only the known total-only case. Reject blinding-point-only
records with payment, attempt and hop context instead of exposing an
opaque SQL constraint error. Log normalized totals, account for them
during migration validation, and cover both cases with regression tests.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a database migration bug in LND (Lightning Network Daemon) that could prevent the node from starting after upgrading. Some old payment routes stored a 'blinded total amount' without the matching encrypted recipient data. The previous migration incorrectly treated that total as proof of a real blinded hop and tried to insert a row with missing required data, causing a SQL constraint failure on startup. The fix uses the presence of encrypted recipient data as the real signal for a blinded hop, silently drops the harmless 'orphaned total' case, and reports a clear error for the genuinely malformed case of a blinding point without encrypted data. It also adds regression tests and adjusts validation so the migrated SQL data matches the original KV data.

Recommended action

Apply the patch before any deployment that migrates KV payment databases to SQL. Operators who have already hit the startup failure should upgrade to a release containing this commit and restart; no manual database repair should be needed because the migration will now skip the orphaned-total-only rows. Review any logs mentioning 'blinding point requires encrypted recipient data' to identify genuinely malformed payment records.

Security signals we found

01

Fixes a startup-denial condition caused by a SQL constraint violation during migration

02

Changes discriminator for sensitive blinded-hop rows from a monetary total to encrypted recipient data

03

Adds explicit malformed-data rejection with payment/attempt/hop context instead of an opaque SQL error

04

Adds regression tests covering both nil and empty encrypted-data orphaned-total variants

05

Adjusts migration validation to account for normalized totals so KV vs SQL comparison passes

Risk score

Why this scored 46/100

Our methodology →
Potential impact 18/30
Exploitability 5/25
Stealth signal 3/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.