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

ln: add awaiting_trampoline_forwards to accumulate inbound MPP

Public commit record

What the developer wrote

Authored by Carla Kirk-Cohen

95/100 · Strong
ln: add awaiting_trampoline_forwards to accumulate inbound MPP

When we are a trampoline router, we need to accumulate incoming HTLCs
(if MPP is used) before forwarding the trampoline-routed outgoing
HTLC(s). This commit adds a new map in channel manager, and mimics the
handling done for claimable_payments.

We will rely on our pending_outbound_payments (which will contain a
payment for trampoline forwards) for completing MPP claims,
not want to surface `PaymentClaimable` events for trampoline,
so do not need to have pending_claiming_payments like we have for MPP
receives.

This map is not persisted, as we're currently working on refactoring
restart logic to depend on channel monitors. We should not use this
accumulation map in production yet, as we can hit a force close if:
- We are used as a trampoline, despite not supporting the feature
- A trampoline MPP part arrives and is committed to the inbound channel
and added to `awaiting_trampoline_forwards`
- We restart and the MPP part is not re-added to
`awaiting_trampoline_forwards`

In this scenario, we will not hit our MPP timeout logic for this HTLC
because we have "forgotten" about it. It will be up to our counterparty
to force close the channel on us, because we're not failing it back
after we hit MPP timeout. Likewise, even if other MPP parts arrive,
we won't consider the inbound accumulation to be complete so we'll fail
them back but forget about the HTLC that came before the restart.

We currently reject trampoline HTLCs earlier in the lifecycle, so we
are not at risk of producing a state that could trigger such a force
close. In the commits that follow, we'll allow forwarding of
trampoline HTLC for tests so that we can start to cover this code.
✓ 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 adds a new internal bookkeeping map for a not-yet-enabled feature called trampoline routing. The commit itself is defensive: it documents that the new map is intentionally not saved to disk and warns that using it in production could cause a channel force-close after a restart. Because the feature is currently rejected earlier in the code path, the commit says the risky state cannot be reached today. It is best read as a work-in-progress foundation rather than an active vulnerability.

Recommended action

Treat this as a feature-in-progress commit, not an immediate security patch. Ensure follow-up commits add persistence and proper restart recovery before trampoline forwarding is enabled. Reviewers should verify that the upstream rejection of trampoline HTLCs remains in place until the persistence work lands.

Security signals we found

01

New non-persistent state map for pending trampoline MPP HTLCs

02

Commit message explicitly warns of force-close risk if used in production before persistence/restart logic is added

03

Trampoline HTLCs are currently rejected earlier in the lifecycle, mitigating the documented risk

04

Timeout/failure paths added for both MPP timeout and on-chain CLTV expiry

05

No persistence logic added for the new map

Risk score

Why this scored 30/100

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