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

onion_message: let caller specify considered channels for blinded paths. This allows restricting blinded paths to channels that have sufficient receive capacity for payment.

Public commit record

What the developer wrote

Authored by Sander van Grieken

73/100 · Adequate
onion_message: let caller specify considered channels for blinded paths.
This allows restricting blinded paths to channels that have sufficient receive
capacity for payment.

NOTE: this might have privacy issues, as this can be used to probe channel capacity.
Maybe randomize leeway?

@f321x: changed to use scid alias in create_blinded_path
✓ Specific, 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 builds private Lightning Network routing hints called 'blinded paths.' It lets the wallet choose which channels to include in a blinded path, and when channels are explicitly chosen, it publishes a short channel ID (a public network identifier) instead of just the next node's public key. The commit message itself warns that this 'might have privacy issues, as this can be used to probe channel capacity.' In plain terms, a payment sender could learn more than intended about a receiver's channel balances, which is a known Lightning privacy concern. The change is not a full fix; it is a partial implementation that introduces a new probing risk while trying to solve a payment-reliability problem.

Recommended action

Treat this as a privacy-relevant change requiring follow-up. The author already flagged the probing risk; reviewers should evaluate whether exposing short_channel_id in payment blinded paths is acceptable, whether encrypted_data_tlv padding is implemented to remove length side-channels, and whether callers filter channels in a way that reveals capacity. Users and downstream callers should avoid passing highly selective channel lists until the privacy trade-off is analyzed and documented. No immediate emergency patch is indicated, but the issue should be tracked.

Security signals we found

01

Commit message explicitly flags possible privacy issue / channel-capacity probing

02

New API exposes short_channel_id in blinded path encrypted_data where next_node_id was used before

03

Caller can restrict blinded paths to channels with sufficient receive capacity, potentially leaking capacity information

04

Padding TODO remains, so encrypted_data length may vary and could leak which branch was taken

05

Change is defensive/functional but introduces a noted privacy trade-off

Risk score

Why this scored 43/100

Our methodology →
Potential impact 8/30
Exploitability 10/25
Stealth signal 9/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.