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

Introduce Dummy BlindedPaymentTlv

Public commit record

What the developer wrote

Authored by shaavan

58/100 · Thin
Introduce Dummy BlindedPaymentTlv

Dummy BlindedPaymentTlvs is an empty TLV inserted immediately before the
actual ReceiveTlvs in a blinded path. Receivers treat these dummy
hops as real hops, which prevents timing-based attacks.

Allowing arbitrary dummy hops before the final ReceiveTlvs obscures
the recipient's true position in the route and makes it harder for
an onlooker to infer the destination, strengthening recipient privacy.
✓ Descriptive subject✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a new 'dummy hop' feature for blinded payment routes in LDK. It lets senders insert fake intermediate routing steps before the real recipient in a private Lightning payment path. Because these dummy hops look and behave like real forwarding nodes, outside observers watching timing or route structure have a harder time figuring out where the payment actually ends up. The change is defensive: it strengthens recipient privacy rather than fixing an active bug or vulnerability.

Recommended action

No immediate action required. This is a privacy-hardening feature. Operators and downstream users should review release notes for any compatibility or behavior changes related to blinded payment path construction once this lands in a release.

Security signals we found

01

Adds dummy intermediate hops to blinded payment paths to obscure recipient position

02

Treats dummy hops with realistic relay semantics (fees, CLTV, constraints) to preserve indistinguishability

03

Explicitly intended to mitigate timing-based route analysis attacks

04

Adds defensive failure paths (debug_assert + InvalidOnionPayload/InvalidOnionBlinding) if dummy hops leak into normal forwarding/receive handling

05

Changes PaymentRelay and PaymentConstraints to Copy, a benign API change supporting the new variant

Risk score

Why this scored 45/100

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