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

Support generic HTLC interception

Public commit record

What the developer wrote

Authored by Matt Corallo

70/100 · Adequate
Support generic HTLC interception

At various points we've had requests to support more generic HTLC
interception in LDK. In most cases, full HTLC interception was not,
in fact, the right way to accomplish what the developer wanted, but
there have been various times when it might have been.

Here, we finally add full HTLC interception support, doing so with
a configurable bitfield to allow developers to intercept only
certain classes of HTLCs.

Specifically, we currently support intercepting HTLCs:
* which were to be forwarded to intercept SCIDs (as was already
supported),
* which were to be forwarded to offline private channels (for LSPs
to accept HTLCs for offline clients so that they can attempt to
wake them before failing the HTLC),
* which were to be forwarded to online private channels (for LSPs
to take additional fees or enforce certain policies),
* which were to be forwarded over public channels (for general
forwarding policy enforcement),
* which were to be forwarded to unknown SCIDs (for everything
else).
✓ Descriptive subject✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit expands an existing Lightning payment interception feature in LDK. Previously, developers could only intercept payments routed through special fake channel IDs. Now they can intercept a wider range of forwarded payments (private channels, public channels, unknown channel IDs) using a configurable bitfield. The change is a feature addition, not a fix for a known vulnerability, but it touches sensitive payment-forwarding logic and changes a public configuration option from a boolean to a bitfield.

Recommended action

Review the new interception paths and bitfield handling for correctness, especially the interaction with channel liveness checks and the requirement that intercepted HTLCs must be handled within seconds. Ensure serialization backward compatibility is preserved for the renamed config field. Consider whether the new unknown-SCID interception path could be abused to delay or stall payments if not handled promptly.

Security signals we found

01

Sensitive payment-forwarding logic modified

02

Public API/config field changed (accept_intercept_htlcs -> htlc_interception_flags)

03

New interception surface for unknown SCIDs and public channels

04

Documentation warns against holding intercepted HTLCs for more than a few seconds to avoid DoS

05

Extensive new test coverage added for interception behavior

Risk score

Why this scored 37/100

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