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

coins: Keep track of number of dirty entries in `CCoinsViewCache`

Public commit record

What the developer wrote

Authored by Pieter Wuille

100/100 · Strong
coins: Keep track of number of dirty entries in `CCoinsViewCache`

Adds `m_dirty_count` member to track the running count of dirty cache entries as follows:
* Incremented when entries are marked dirty via `CCoinsCacheEntry::SetDirty`
* Decremented when dirty entries are removed or cleaned
* Passed through `CoinsViewCacheCursor` and updated during iteration

The dirty count is needed because after non-wiping flushes (introduced in #28280 and #28233), the percentage of dirty entries in the cache may be far below 100%. Using total cache size for flush warnings and disk space checks is therefore misleading.

Updates all test code to properly initialize and maintain the dirty count.

Co-authored-by: l0rinc <pap.lorinc@gmail.com>
Co-authored-by: Andrew Toth <andrewstoth@gmail.com>
Co-authored-by: optout <13562139+optout21@users.noreply.github.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This Bitcoin Core change adds an internal counter that tracks how many unspent-coin cache entries are 'dirty' (modified but not yet saved to disk). It is a correctness and accounting improvement, not a fix for an active security flaw. The change helps flush warnings and disk-space checks reflect reality after a recent feature that allows partial, non-wiping flushes. No exploit or vulnerability is described in the commit.

Recommended action

No security action required. Treat as normal code-quality/refactoring review. If auditing, verify that m_dirty_count is correctly maintained across all SetDirty/erase/clear paths and that SanityCheck() catches inconsistencies in debug builds.

Security signals we found

01

Internal cache accounting change with no consensus or network impact

02

Adds Assume(m_dirty_count == 0) after Flush/Sync and assert in SanityCheck

03

No mention of vulnerability, exploit, bug, crash, or DoS in commit message or diff

04

Test-only additions verify dirty count invariants

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.