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

lnworker: enforce creation of PaymentInfo for b11

Public commit record

What the developer wrote

Authored by f321x

68/100 · Adequate
lnworker: enforce creation of PaymentInfo for b11

Enforce that the information used to create a bolt11 invoice using
`get_bolt11_invoice()` is similar to the related instance of PaymentInfo
by requiring a PaymentInfo as argument for `get_bolt11_invoice()`.
This way the invoice cannot differ from the created PaymentInfo.
This allows to use the information in PaymentInfo for validation of
incoming htlcs more reliably.

To cover all required information for the creation of a b11 invoice the
PaymentInfo class has to be extended with a expiry and
min_final_cltv_expiry. This requires a db upgrade.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit tightens how Electrum creates Lightning invoices so the stored payment record and the generated invoice always match. Previously, callers passed invoice details separately, creating a risk that the invoice could differ from what Electrum later used to validate incoming payments. Now a single PaymentInfo object is required, and it stores extra fields (expiry and minimum locktime) so validation can rely on it. This is a defensive hardening change, not a fix for a known active exploit.

Recommended action

Review as a hardening improvement. Ensure the database migration is backward-compatible and that all new PaymentInfo fields are correctly populated by third-party plugins or scripts using the API. No urgent patch deployment is indicated, but downstream integrators should adapt to the new get_bolt11_invoice() signature.

Security signals we found

01

Defensive refactoring to eliminate parameter-drift between invoice generation and HTLC validation

02

Database schema upgrade for PaymentInfo with new expiry and cltv fields

03

Constant rename/removal of MIN_FINAL_CLTV_DELTA_FOR_INVOICE in favor of MIN_FINAL_CLTV_DELTA_ACCEPTED + buffer

04

Hold invoices and submarine swaps now create PaymentInfo before generating bolt11

05

No explicit vulnerability, CVE, or bug identifier mentioned in commit

Risk score

Why this scored 46/100

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