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

htlcswitch+invoices: align final-hop CLTV handling

Public commit record

What the developer wrote

Authored by ziggie

73/100 · Adequate
htlcswitch+invoices: align final-hop CLTV handling

Apply the same supported CLTV delta range to final-hop HTLC handling that is
already used for forwarding.

Use a shared helper for the exit-hop link path so final-hop amount and CLTV
checks remain consistent across invoice creation and HTLC handling.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit tightens the checks that Lightning nodes perform when they are the final recipient of a payment. It makes sure the payment's time-lock expiry is not unreasonably far in the future, matching the same limit already used when forwarding payments. It also moves the final-hop amount and time-lock checks into a shared helper so invoice creation and HTLC handling stay consistent. The change is defensive and reduces the risk of abuse involving very long-dated payment locks, but the commit message does not frame it as a security fix and no CVE or advisory is referenced.

Recommended action

Review the new MaxFinalCltvDelta and MaxOutgoingCltvExpiry defaults to ensure they match operational expectations, and verify that the new failure responses (FailIncorrectDetails for final-hop expiry-too-far, FailExpiryTooFar for forwarding) propagate correctly without breaking legitimate payments that use large but previously accepted CLTV deltas.

Security signals we found

01

Adds explicit upper-bound validation for final-hop CLTV expiry

02

Adds explicit upper-bound validation for forwarding CLTV delta

03

Fixes underflow-prone subtraction in CheckHtlcForward by checking incomingTimeout < outgoingTimeout before computing delta

04

Centralizes final-hop validation logic to prevent divergence between invoice creation and HTLC acceptance

05

Adds tests for boundary conditions (exactly at maximum, one past maximum, below outgoing CLTV)

06

No vendor security framing, CVE, or researcher attribution present in commit or references

Risk score

Why this scored 64/100

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