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

ln: process added trampoline htlcs with CLTV validation in tests

Public commit record

What the developer wrote

Authored by Carla Kirk-Cohen

95/100 · Strong
ln: process added trampoline htlcs with CLTV validation in tests

We can't perform proper validation because we don't know the outgoing
channel id until we forward the HTLC, so we just perform a basic CLTV
check.

We don't yet have proper handling of trampoline forwards on restart, so
we only enable this in our tests.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit changes how the Lightning node handles a special kind of forwarded payment called a 'trampoline' payment. Previously, trampoline forwards were always rejected. Now, in test builds only, the code allows them through after checking basic fee and timeout (CLTV) rules. The commit also removes one test that expected trampoline forwards to be rejected. This is a development/testing change, not a fix for an active security flaw, and production behavior still rejects these forwards.

Recommended action

Treat as normal development review. If trampoline forwarding is intended for production, ensure full forwarding validation, restart persistence, and interception logic are implemented before removing the #[cfg(test)] guard. No urgent security patch is indicated by this commit alone.

Security signals we found

01

Trampoline forwarding previously hard-rejected; now conditionally accepted in test builds with reduced validation

02

CLTV and fee-skim checks added for trampoline forwards, but full channel-level forwarding checks still skipped

03

Production code path continues to reject trampoline forwards

04

Restart persistence for trampoline forwards explicitly noted as unimplemented

05

Test-only gating via #[cfg(test)] reduces real-world exposure

Risk score

Why this scored 23/100

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