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

lnworker: differentiate PaymentInfo by direction

Public commit record

What the developer wrote

Authored by f321x

68/100 · Adequate
lnworker: differentiate PaymentInfo by direction

Allows storing two different payment info of the same payment hash by
including the direction into the db key.
We create and store PaymentInfo for sending attempts and for requests (receiving),
if we try to pay ourself (e.g. through a channel rebalance) the checks
in `save_payment_info` would prevent this and throw an exception.
By storing the PaymentInfos of outgoing and incoming payments separately in
the db this collision is avoided and it makes it easier to reason about
which PaymentInfo belongs where.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit changes how Electrum stores Lightning payment records. Previously, outgoing and incoming payments sharing the same payment hash (for example, when rebalancing your own channels) could collide in the database and cause errors. The fix adds a direction flag to the database key so both sides can be stored separately. It is a bug-fix and robustness improvement, not an obvious security vulnerability, though the original collision could have caused crashes or inconsistent state in self-payment scenarios.

Recommended action

Treat as a normal bug-fix/robustness patch. Review that the database migration correctly handles wallets with existing lightning_payments entries and that all callers now pass the correct direction. No urgent security response is indicated by the diff itself.

Security signals we found

01

Database key collision between sent and received PaymentInfo records for the same payment hash is resolved

02

Prevents exception/crash in save_payment_info during self-payments or rebalances

03

Adds wallet_db migration from seed_version 63 to 64 to preserve existing payment_info data

04

Refactors status lookups to require explicit direction, reducing ambiguity about whether a record belongs to an invoice or a request

05

No new cryptographic operations, network parsing, or privilege changes are introduced

Risk score

Why this scored 36/100

Our methodology →
Potential impact 8/30
Exploitability 7/25
Stealth signal 5/15
Affected reach 6/15
Confidence 7/10
Evidence quality 3/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.