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

paymentsdb: make verifyAttempt more robust

Public commit record

What the developer wrote

Authored by ziggie

80/100 · Strong
paymentsdb: make verifyAttempt more robust

We now return an error when blinded and non blinded attempts are
combined. This was theoretically possible to register a legacy
attempt in combination with a blinded payment. This would have
been prevented by other checks in the code because legacy payments
are not split into shards.
✓ 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 tightens validation in LND's payment database so that a single payment cannot mix regular (non-blinded) and blinded routing attempts. Before this change, the code already rejected MPP records inside blinded payments, but it did not explicitly reject a plain legacy attempt being registered alongside a blinded one. The commit message says such a mix was only 'theoretically possible' because other checks prevent legacy payments from being split into shards. The patch adds an explicit error and many unit tests, making the safeguard more robust but not clearly fixing an actively exploitable vulnerability.

Recommended action

Treat as a hardening patch. Reviewers should confirm that no code path can actually register a mixed attempt today, and consider whether the new error needs to be handled by callers that retry or split payments. No urgent security response is indicated by the commit materials alone.

Security signals we found

01

New defensive validation preventing mixed blinded/non-blinded HTLC attempts in the same payment

02

Addition of a new sentinel error for mixed blinded and non-blinded payments

03

Extensive unit-test coverage added for verifyAttempt edge cases

04

Commit message describes the issue as 'theoretically possible' and already mitigated by other checks

Risk score

Why this scored 44/100

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