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

htlcswitch: key the aux traffic shaper on the evaluated channel

Public commit record

What the developer wrote

Authored by bitromortac

73/100 · Adequate
htlcswitch: key the aux traffic shaper on the evaluated channel

During non-strict forwarding, handlePacketAdd evaluates every candidate
channel to the next peer and calls CheckHtlcForward with the sender-requested
outgoing SCID (originalOutgoingChanID) for each candidate. That SCID flowed
through canSendHtlc into AuxTrafficShaper.ShouldHandleTraffic, so a
channel-keyed shaper was asked about the requested channel rather than the
candidate actually being evaluated. With parallel channels to a peer this
inspects the wrong channel.

Key the shaper on l.ShortChanID() (the channel under evaluation) instead.
originalScid is retained solely for createFailureWithUpdate / FailAliasUpdate,
so the alias-aware channel_update returned to the sender is unchanged and the
real SCID handed to the shaper never leaks onto the wire.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a routing bug in LND's Lightning payment forwarding. When a payment could take any of several parallel channels to the same next peer, the node was accidentally asking an optional 'auxiliary traffic shaper' about the channel the sender requested, rather than the channel actually being considered. That could lead to wrong bandwidth/custom-policy decisions and might leak the real channel ID if not carefully handled. The patch keys the shaper on the actual evaluated channel while keeping the sender-facing error messages on the requested (often alias) channel ID, so no real ID leaks onto the network.

Recommended action

Treat as a correctness/security hygiene fix and include in the next maintenance release. Users running custom AuxTrafficShaper implementations with parallel channels to peers should upgrade. No immediate emergency response is indicated, but operators should monitor for inconsistent forwarding decisions on parallel channels.

Security signals we found

01

Logic error: wrong channel identifier used for auxiliary policy/bandwidth check

02

Potential information disclosure: real SCID could leak if passed to shaper-driven wire messages; commit explicitly prevents this

03

Parallel-channel forwarding correctness issue

04

No explicit security wording in commit title/message

05

Regression test added to enforce correct behavior

Risk score

Why this scored 44/100

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