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

ln: enforce trampoline onion recipient constraints

Public commit record

What the developer wrote

Authored by Carla Kirk-Cohen

83/100 · Strong
ln: enforce trampoline onion recipient constraints

Tests are added to cover validation of blinded and unblinded trampoline
payloads against their outer onion. These are consolidated with our
existing coverage for successful receives.

Co-authored-by: Arik Sosman <git@arik.io>
Co-authored-by: Maurice Poirrier <mpch@hey.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit adds safety checks in the Lightning Dev Kit (LDK) to ensure that the inner 'trampoline' payment instructions match the outer onion packet's amounts and deadlines. Without these checks, a malicious or buggy sender could craft a trampoline payment where the outer layer promises one amount or deadline while the inner layer demands a higher one, potentially allowing a node to be tricked into accepting or relaying an inconsistent payment. The patch enforces that the outer onion's amount and CLTV expiry are at least as large as the trampoline onion's, and adds tests for underpayment and deadline mismatch cases.

Recommended action

Review the new constraints for off-by-one or rounding issues, ensure the error codes returned match the BOLT specifications for trampoline payments, and verify that the blinded forward path's use of `InvalidOnionBlinding` does not leak information that could aid de-anonymization. Consider whether additional constraints (e.g., fee sanity) should also be enforced for trampoline forwards.

Security signals we found

01

New validation function enforcing trampoline/outer onion consistency for amount and CLTV

02

Blinded trampoline failures mapped to InvalidOnionBlinding to preserve sender anonymity

03

Trampoline blinded forward path now validates amount/CLTV constraints before relay

04

Test coverage added for underpayment and CLTV mismatch attack/failure scenarios

05

Log assertions confirm expected failure reasons are hit

Risk score

Why this scored 61/100

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