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

Move HTLC interception decisions to `forward_htlcs` callsites

Public commit record

What the developer wrote

Authored by Matt Corallo

85/100 · Strong
Move HTLC interception decisions to `forward_htlcs` callsites

In the next commit we'll substantially expand the types of HTLCs
which can be intercepted. In order to do so, we want to make
forwarding decisions with access to the (specified) destination
channel. Sadly, this isn't available in `forward_htlcs`, so here we
move interception decisions out of `forward_htlcs` and into
`process_pending_update_add_htlcs` and `handle_release_held_htlc`.

Note that we do not handle HTLC interception when forwarding an
HTLC which was decoded in LDK versions prior to 0.2, which is noted
in a suggested release note. This is due to a gap where such HTLC
might have had its routing decision made already and be waiting
for an interception decision in `forward_htlcs`, but now we will
only make an interception decision when decoding the onion.
✓ 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 refactors when and where the Lightning node decides to intercept HTLCs (payments it is asked to forward). It moves the interception decision from a later forwarding stage to the earlier moment when the incoming HTLC is decoded. The change is preparatory work for a larger feature and includes a noted backwards-compatibility limitation: HTLCs first received on LDK versions before 0.2 will no longer be intercepted and will instead be forwarded or failed automatically. There is no direct evidence in the commit that this fixes an active security vulnerability, but it changes payment-handling logic in a security-sensitive area.

Recommended action

Review the next commit in the series to understand the full interception expansion. Test the backwards-compatibility path for pre-0.2 HTLCs to ensure automatic forwarding/failing behaves correctly. Audit the new `can_forward_htlc_intercepted` path for consistency with existing failure semantics, especially around phantom and intercept SCIDs.

Security signals we found

01

Refactor of HTLC interception decision points

02

Backwards-compatibility note: pre-0.2 HTLCs will not be intercepted

03

Addition of fee and CLTV sanity checks in the no-channel forward path

04

New persistence notifier guard around release-held-HTLC handling

05

Removal of shared-secret-based intercept ID derivation in favor of htlc_id/channel_id/counterparty_node_id

Risk score

Why this scored 35/100

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