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

Refactor attribution data (#3320)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

88/100 · Strong
Refactor attribution data (#3320)

* Refactor attribution data

We refactor the attribution data code to make it more consistent with
the rest of the Sphinx-related code. We add comments and intermediate
variables to make it more readable. We introduce intermediate classes
to hold data and add better symmetry between the success and failure
cases.

This will make it easier to implement trampoline attribution and add
fulfillment data (https://github.com/lightning/bolts/pull/1344).

* Refactor trampoline attribution data

We correctly extract shared secrets (including trampoline shared
secrets) and detect when we're inside a blinded path to avoid
including attribution data. Note that we don't use the trampoline
shared secret yet, since full trampoline isn't implemented (see
https://github.com/ACINQ/eclair/pull/2819 for the full changes).

We add tests for attribution data with blinded paths and trampoline
payments.
✓ Descriptive subject✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit is a code refactor of how Eclair handles 'attribution data'—extra encrypted timing and accountability information attached to Lightning payment success and failure messages. It restructures the code to support future trampoline payments and blinded routes, and adds tests. The commit itself does not claim to fix a security bug; it is described as making later features easier to implement. However, the refactor changes how shared secrets are extracted and how attribution data is included or omitted for blinded and trampoline payments, which touches privacy-sensitive logic.

Recommended action

Treat as a normal code-review item rather than an urgent security patch. Reviewers should verify that the new shared-secret extraction correctly handles malformed trampoline onions, that blinded-path detection cannot be bypassed by a crafted payload, and that the HMAC verification changes do not weaken attribution accountability. Run the new tests and consider additional edge-case tests for partial/malformed attribution data.

Security signals we found

01

Refactor of cryptographic attribution-data creation/verification

02

New shared-secret extraction path parses trampoline onion and path-key/blinded-path state

03

Attribution data now explicitly suppressed for blinded-route intermediate nodes

04

Attribution HMAC verification now uses optional payload (None for success, Some failure packet for failures)

05

Adds tests for blinded-path and trampoline attribution behavior

Risk score

Why this scored 34/100

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