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

connectd, gossipd, pay, bcli: use timemono when solely measuring duration for timeouts.

Public commit record

What the developer wrote

Authored by Rusty Russell

73/100 · Adequate
connectd, gossipd, pay, bcli: use timemono when solely measuring duration for timeouts.

This is immune to things like clock changes, and has the convenient side-effect that
it will *not* be overridden when we override time for developer purposes.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit swaps wall-clock timestamps for monotonic timestamps when measuring durations and timeouts in several parts of Core Lightning. Monotonic time only moves forward at a steady rate and is not affected by system clock changes or developer time overrides. The change makes timeout logic more reliable and prevents accidental misbehavior during testing, but it is a hardening/refactoring patch rather than a fix for an active, exploitable vulnerability.

Recommended action

Treat as a routine hardening/refactoring change. Reviewers should verify that no remaining duration/timeout comparisons in the same code paths still mix timeabs and timemono types, and that the timemono helper functions used (timemono_before, timemono_after, timemono_add, timemono_sub, timemono_between) behave equivalently to their timeabs counterparts for non-negative durations. No urgent security response is indicated.

Security signals we found

01

Use of monotonic clock for timeout/duration measurements reduces risk of premature or delayed timeouts due to wall-clock jumps

02

Avoids developer time override affecting production timeout behavior

03

Touches HTLC forwarding grace-period and channel feerate timeout comparisons

04

Touches payment deadline and retry logic

05

No explicit vulnerability, CVE, or security bug is described in the commit

Risk score

Why this scored 29/100

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