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

Use actual CLTV delta for reputation (#3134)

Public commit record

What the developer wrote

Authored by Thomas HUET

76/100 · Adequate
Use actual CLTV delta for reputation (#3134)

When computing reputation, instead of using a fixed multiplier for pending HTLCs, we now use the CLTV expiry of the HTLC (assuming a new block is mined every 10 minutes).
The reason for the fixed multiplier was that a HTLC with the maximum CLTV delta could stay pending for several orders of magnitude longer than a regular HTLC and would have an oversized impact on the reputation. We mitigate this by increasing the expected settlement time (from a few seconds to a few minutes), using more historical data (increasing the half-life), and counting on the fact that most HTLCs will have a CLTV expiry a lot lower than the maximum.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit changes how Eclair estimates the trustworthiness (reputation) of other Lightning nodes when deciding whether to forward payments. Previously, pending payments were penalized using a fixed multiplier that did not reflect how long an HTLC could actually stay locked. Now the penalty is based on the real CLTV expiry (the deadline by which the payment must settle on-chain), assuming each block takes about 10 minutes. The change also increases the half-life of reputation data from 15 to 30 days and raises the 'max-relay-duration' threshold from 12 seconds to 5 minutes. It is a defensive hardening change against channel-jamming attacks, not a fix for an active exploit or a disclosed vulnerability.

Recommended action

Review the new CLTV-based weight formula for numerical stability and edge cases (e.g., expiry at or below current block height, very large CLTV deltas). Ensure the 10-minute/block assumption and the 5-minute max-relay-duration threshold are acceptable for your node's risk profile. Run the updated reputation tests and consider monitoring reputation scores after upgrade.

Security signals we found

01

Anti-jamming / reputation-system hardening

02

Removal of fixed pending-multiplier in favor of CLTV-based expected settlement time

03

Configuration change: half-life 15 days -> 30 days, max-relay-duration 12 seconds -> 5 minutes

04

Reputation scoring now depends on current block height and HTLC expiry

05

No memory-safety, cryptographic, or remote-code-execution signals in diff

Risk score

Why this scored 41/100

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