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

Accept blinded paths built by a phantom node participant

Public commit record

What the developer wrote

Authored by Matt Corallo

85/100 · Strong
Accept blinded paths built by a phantom node participant

In the next commit we'll add support for building a BOLT 12 offer
which can be paid to any one of a number of participant nodes. Here
we add support for validating blinded paths as coming from one of
the participating nodes by deriving a new key as a part of the
`ExpandedKey`.

We keep this separate from the existing `ReceiveAuthKey` which is
node-specific to ensure that we only allow this key to be used for
blinded payment paths and contexts in `invoice_request` messages.
This ensures that normal onion messages are still tied to specific
nodes.

Note that we will not yet use the blinded payment path phantom
support which requires additional future work. However, allowing
them to be authenticated in a phantom configuration should allow
for compatibility across versions once the building logic lands.
✓ Specific, 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 prepares the Lightning Dev Kit (LDK) to support a new 'phantom node' feature for BOLT 12 offers. It changes how encrypted control data in blinded payment paths and onion messages is authenticated: instead of checking one extra node-specific key, it now checks two keys (the existing node-specific key and a new shared phantom-node key). The commit itself does not enable the actual phantom-node building logic yet, but it adds the cryptographic plumbing so that future versions can authenticate blinded paths from any participant in a phantom-node setup while still keeping normal onion messages tied to a specific node.

Recommended action

Review the new ExpandedKey.phantom_node_blinded_path_key derivation for correctness and independence from the ReceiveAuthKey. Ensure that the TriPolyAADUsed logic cannot be confused by an attacker who crafts a tag that validates under an unintended AAD (e.g., collision between no-AAD and AAD MACs). Verify that downstream consumers of control_tlvs_from_phantom_participant enforce the intended restricted usage once the feature is fully enabled. Treat this as a feature commit with security-relevant plumbing rather than an active vulnerability fix.

Security signals we found

01

Cryptographic authentication logic changed from two MAC checks to three MAC checks

02

New key derivation added to ExpandedKey for phantom-node blinded paths

03

Onion message authentication now distinguishes local-node vs phantom-participant origin

04

Normal onion message contexts still require node-specific authentication

05

Blinded payment/trampoline TLV parsing now accepts a third authentication key

06

Commit message explicitly frames change as compatibility groundwork, not yet active feature

Risk score

Why this scored 37/100

Our methodology →
Potential impact 8/30
Exploitability 5/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.