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

validation: Use dirty entry count in flush warnings and disk space checks

Public commit record

What the developer wrote

Authored by Pieter Wuille

73/100 · Adequate
validation: Use dirty entry count in flush warnings and disk space checks

Changes flush warnings to use the actual number of dirty entries being written rather than total cache size or memory usage:
* Moves warning from `FlushStateToDisk` to `CCoinsViewDB::BatchWrite` so it applies to both regular flushes and `AssumeUTXO` snapshot writes
* Changes threshold from `WARN_FLUSH_COINS_SIZE` (1 GiB) to `WARN_FLUSH_COINS_COUNT` (10M entries), approximately equivalent - this also helps with the confusion caused by UTXO size difference on-disk vs in-memory
* Moves benchmark logging to `BatchWrite` where the actual disk I/O occurs to make sure AssumeUTXO also warns
* Uses dirty count for disk space check (48 bytes per entry estimate)
* Removes redundant `changed` counter since `dirty_count` is now tracked

This ensures users are warned appropriately even when only a fraction of the cache is dirty, and provides accurate warnings during `AssumeUTXO` loads.

Co-authored-by: l0rinc <pap.lorinc@gmail.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This Bitcoin Core commit changes how the software warns users and checks disk space before writing the UTXO cache to disk. It now counts the actual number of changed (dirty) entries instead of the total cache memory size. This makes warnings more accurate, especially during special operations like AssumeUTXO snapshot loads, and prevents unnecessary disk-space checks based on unchanged cached data. There is no indication this fixes an exploitable vulnerability; it is a correctness and logging improvement.

Recommended action

No urgent action required. Treat as a routine correctness/logging improvement. Operators should still ensure adequate disk space, as the estimate remains conservative.

Security signals we found

01

Disk-space check now uses dirty entry count rather than total cache size, which could avoid a false 'disk full' fatal error when most of the cache is clean

02

Warning threshold moved from memory usage to dirty entry count, improving accuracy during AssumeUTXO loads

03

No input validation, cryptographic, or consensus logic changed

Risk score

Why this scored 19/100

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