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

ln: add trampoline mpp accumulation with rejection on completion

Public commit record

What the developer wrote

Authored by Carla Kirk-Cohen

100/100 · Strong
ln: add trampoline mpp accumulation with rejection on completion

Add our MPP accumulation logic for trampoline payments, but reject
them when they fully arrive. This allows us to test parts of our
trampoline flow without fully implementing outbound dispatch.

This commit keeps the same first_claimable_htlc debug_assert behavior
as MPP claims, asserting that we do not fail our
check_claimable_incoming_htlc merge for the first HTLC that we add to a
set. This assert can only be hit if our first part exceeds the
`MAX_VALUE_MSAT`, which should not be hit because we check individual
amounts elsewhere in the codebase (the check exists to check that
multiple parts combined don't hit this overflow).
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit adds partial support in the Lightning Dev Kit node software for receiving and temporarily holding multi-part trampoline payments, then deliberately rejects them once all parts arrive because full outbound forwarding is not yet implemented. It is a development/testing step for the trampoline routing feature, not a finished payment path. The code includes safety checks and debug assertions to catch inconsistent payment data, and it explicitly fails unsupported forwards rather than silently mishandling them.

Recommended action

Treat this as normal feature development with no immediate security patch required. Reviewers should verify that the MPP merge path cannot be reached with a first HTLC that exceeds MAX_VALUE_MSAT, confirm the debug_assert assumption holds in production builds, and track the TODO about consistent trampoline fields across MPP parts. Monitor follow-up commits that replace the deliberate TemporaryTrampolineFailure with real outbound dispatch.

Security signals we found

01

New trampoline forward handling path accumulates MPP parts before rejecting

02

Debug assertion guards first-HTLC failure in MPP merge

03

TODO comment flags possible MPP inconsistency in next_node_id across trampoline parts

04

Fee and CLTV validation added before deliberate failure

05

Explicit TemporaryTrampolineFailure returned instead of silent drop or incorrect forward

Risk score

Why this scored 25/100

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