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

Initialize peer stats with past events (#3272)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

88/100 · Strong
Initialize peer stats with past events (#3272)

We initialize peer statistics by reading past events from the `AuditDb`.
We read events in chunks to avoid overloading the DB or the RAM. We only
return peer statistics to callers once we've finished reading past data
from the DB.

Note that on-chain statistics need to be computed whenever statistics
are requested, because they require merging data from two distincts
events (transaction published and transaction confirmed), which requires
keeping state between those events and thus requires the DB (because the
node may restart after publishing a transaction and before it confirms).
✓ 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 commit changes how Eclair tracks peer statistics. Previously, after a restart, the node would start collecting statistics from scratch and wait for new events before making automated decisions. Now it loads up to 7 days of past payment and on-chain events from the database in chunks, and only returns complete statistics once that initial load is done. It also refreshes on-chain fee data from the database whenever statistics are requested, so fees from transactions confirmed while the node was offline are not missed. This is a correctness/operational improvement, not a security fix.

Recommended action

No security action required. Reviewers may want to verify that the bounded 7-day window and chunked DB reads adequately protect startup performance, and that the empty LatestStats response during historical loading does not cause unintended behavior in callers other than PeerScorer.

Security signals we found

01

No security-relevant signals in the diff: no privilege changes, no cryptographic operations, no network input parsing, no authentication/authorization logic.

02

The commit message and code comments describe an operational/correctness feature, not a vulnerability fix.

03

Database reads are chunked and bounded by the 7-day retention window, mitigating memory/DB load concerns.

Risk score

Why this scored 18/100

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