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

offers: only use blinded path nodes from offers when creating invoice for invoice_request.

Public commit record

What the developer wrote

Authored by Rusty Russell

65/100 · Adequate
offers: only use blinded path nodes from offers when creating invoice for invoice_request.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
The short version

What changed, and why it matters

This change fixes how Core Lightning creates invoices in response to BOLT12 offers. Previously, when replying to an invoice_request, the node used its own configured 'fronting nodes' rather than the ones actually listed in the offer. That meant an offer that specified a particular privacy/fronting path could be ignored, potentially exposing the recipient's real node identity in the invoice. The patch makes the invoice reuse the offer's blinded-path fronting nodes, falling back to defaults only if the offer did not specify any. It also adds tests showing offers can now enforce specific fronting nodes or no fronting at all.

Recommended action

Treat as a privacy bugfix. Review whether prior behavior could have caused real node IDs to leak in invoices for offers that requested fronting; consider backporting if BOLT12 offers are enabled in production releases. No immediate exploit code is evident, but operators relying on offer-level privacy should upgrade.

Security signals we found

01

Privacy-path misrouting: prior code ignored offer-specified blinded-path fronting nodes and used node defaults, which could deanonymize the invoice issuer

02

Blinded path first-hop selection now derived from offer_paths instead of plugin-wide fronting_nodes

03

Added validation/failure path when offer fronting nodes are unusable

04

New test coverage for explicit offer fronting, no-fronting, and multiple fronting nodes

Risk score

Why this scored 35/100

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