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

Force-close on invalid HTLC `cltv_expiry` (#3367)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

88/100 · Strong
Force-close on invalid HTLC `cltv_expiry` (#3367)

Bolt 2 specifies that if tje sending node sets `cltv_expiry` to greater
or equal to 500000000, we should send a warning and close the connection
or send an error and fail the channel. We never implemented that, which
was fine because we already rejected large `cltv_expiry` before that
threshold (without force-closing), but it's better to explicitly force
close if our peer is sending such invalid values.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This change makes the Eclair Lightning node force-close a payment channel if a peer tries to add a payment whose timeout value (cltv_expiry) is 500,000,000 or higher. Such large values are invalid according to the Lightning BOLT 2 specification because they would be interpreted as a Unix timestamp rather than a Bitcoin block height, which could confuse the node and lead to incorrect fund-locking behavior. Previously Eclair rejected these values without force-closing; now it explicitly closes the channel as the spec recommends.

Recommended action

Review the off-by-one change in Scripts.cltvTimeout() for any edge cases with lockTime exactly equal to 500,000,000, and ensure the force-close path does not introduce denial-of-service risks where a malicious peer could cheaply induce channel closures. Consider whether the existing large-cltv_expiry rejection already provided sufficient protection before this change.

Security signals we found

01

BOLT 2 compliance check added for HTLC cltv_expiry >= 500,000,000

02

Invalid cltv_expiry now triggers local error and channel force-close

03

Off-by-one fix in locktime threshold interpretation (<= changed to <)

04

New regression test for force-close on invalid cltv_expiry

Risk score

Why this scored 60/100

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