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

validation: do not wipe utxo cache for stats/scans/snapshots

Public commit record

What the developer wrote

Authored by Pieter Wuille

93/100 · Strong
validation: do not wipe utxo cache for stats/scans/snapshots

Since #28280, the cost of a non-wiping sync of the UTXO cache is only proportional to the number of dirty entries, rather than proportional to the size of the entire cache. Because of that, there is no reason to perform a wiping flush in case the contents of the cache is still useful.

Split the FlushStateMode::ALWAYS mode into a FORCE_SYNC (non-wiping) and a FORCE_FLUSH (wiping), and then use the former in scantxoutset, gettxoutsetinfo, snapshot creation.

Co-authored-by: l0rinc <pap.lorinc@gmail.com>
Co-authored-by: cedwies <141683552+cedwies@users.noreply.github.com>
✓ Specific, 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 Bitcoin Core change tweaks how the in-memory UTXO cache is flushed to disk during certain RPC operations and snapshot creation. Previously these operations always wiped the cache, which could cause temporary performance slowdowns. The patch adds a non-wiping flush mode and uses it where the cache contents are still useful. It is a performance/robustness improvement, not a fix for an active security vulnerability.

Recommended action

Treat as a routine performance/robustness improvement. Reviewers should verify that FORCE_SYNC correctly preserves cache invariants and that the default wipe_cache=true for other callers remains safe. No urgent security response is warranted.

Security signals we found

01

No direct memory safety, cryptographic, consensus, or authorization bug is patched in the diff.

02

The change reduces cache pressure and I/O amplification during RPC/snapshot operations, which marginally improves DoS resilience.

03

Functional tests are adjusted to expect different flush sizes/modes, consistent with intended behavior change rather than a vulnerability fix.

04

No CVE, security advisory, or bug bounty attribution is present in the commit message or diff.

Risk score

Why this scored 24/100

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