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

Always pad `BlindedMessagePath` hop data to a consistent length

Public commit record

What the developer wrote

Authored by Matt Corallo

85/100 · Strong
Always pad `BlindedMessagePath` hop data to a consistent length

If we're building a blinded message path with extra dummy hops, we
have to ensure we at least hide the length of the data in pre-final
hops as otherwise the dummy hops are trivially obvious. Here we do
so, taking an extra `bool` parameter to `BlindedMessagePath`
constructors to decide whether to pad every hop to the existing
`MESSAGE_PADDING_ROUND_OFF` or whether to only ensure that each
non-final hop has an identical hop data length.

In cases where the `DefaultMessageRouter` opts to use compact
paths, it now also selects compact padding, whether short channel
IDs are available or not.
✓ 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 fixes a privacy leak in Lightning onion messages. When building a blinded path with fake 'dummy' hops, the program previously did not always hide the size of the data carried at each hop. That made the dummy hops easy to spot, defeating their purpose. The patch adds a new padding mode so that every non-final hop is padded to the same length, keeping dummy hops indistinguishable from real ones. It also lets compact paths use this same minimal padding instead of skipping padding entirely.

Recommended action

Review callers of BlindedMessagePath constructors to ensure the new `compact_padding` argument is set appropriately; prefer `false` for maximum privacy unless path size is constrained (e.g., BOLT 12 QR codes). Verify that compact padding still yields identical intermediate payload lengths in all configurations.

Security signals we found

01

Privacy leak: dummy hops identifiable by payload length

02

Padding policy change in blinded path construction

03

New API parameter `compact_padding` added to BlindedMessagePath constructors

04

Functional tests updated to assert uniform intermediate hop lengths under compact padding

05

DefaultMessageRouter compact paths now use compact padding regardless of short_channel_id availability

Risk score

Why this scored 51/100

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