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

Add methods to fetch an `OfferBuilder` for "phantom" node configs

Public commit record

What the developer wrote

Authored by Matt Corallo

73/100 · Adequate
Add methods to fetch an `OfferBuilder` for "phantom" node configs

In the BOLT 11 world, we have specific support for what we call
"phantom nodes" - creating invoices which can be paid to any one of
a number of nodes by adding route-hints which represent nodes that
do not exist.

In BOLT 12, blinded paths make a similar feature much simpler - we
can simply add blinded paths which terminate at different nodes.
The blinding means that the sender is none the wiser.

Here we add logic to fetch an `OfferBuilder` which can generate an
offer payable to any one of a set of nodes. We retain the "phantom"
terminology even though there are no longer any "phantom" nodes.

Note that the current logic only supports the `invoice_request`
message going to any of the participating nodes, it then replies
with a `Bolt12Invoice` which can only be paid to the responding
node. Future work may relax this restriction.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a new feature to rust-lightning that lets a group of Lightning nodes create a single BOLT 12 offer that can be paid to any node in the group. It is a feature addition for 'phantom node' setups, not a fix for a known security bug. There is no evidence in the commit or supplied references that this resolves an active vulnerability or incident.

Recommended action

Review the new API for correct handling of shared keys and blinded path limits, but no immediate security patch is indicated. Treat as normal feature review.

Security signals we found

01

New public API surface added (create_phantom_offer_builder)

02

Use of shared ExpandedKey/phantom_node_blinded_path_key across nodes

03

Blinded path construction delegated to MessageRouter

04

Test-only changes to key derivation with optional phantom_seed

Risk score

Why this scored 30/100

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