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

kernel: allow setting chainstate `dbcache`

Public commit record

What the developer wrote

Authored by Lőrinc

68/100 · Adequate
kernel: allow setting chainstate `dbcache`

Add `btck_chainstate_manager_options_set_database_cache_bytes()` so Kernel callers can set the total database cache budget.
Use `uint64_t` for a fixed-width C API, reject values outside the architecture-specific range, and keep `DEFAULT_KERNEL_CACHE` as the fallback.
Apply the selected split to the block tree database and `LoadChainstate()`.

Co-authored-by: stickies-v <stickies-v@protonmail.com>
Co-authored-by: w0xlt <94266259+w0xlt@users.noreply.github.com>
Co-authored-by: stringintech <stringintech@gmail.com>
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a new public API knob to the Bitcoin Core 'libbitcoinkernel' library so that programs using the kernel can choose how much memory to use for the chainstate database cache. It also enforces minimum and maximum size limits. There is no obvious security bug in the change; it is a normal feature addition. The only security-relevant aspect is that the new setting is now properly validated and applied, whereas before the cache size was hard-coded.

Recommended action

No immediate action required. Treat as a routine feature commit. Reviewers may want to confirm that MIN_DBCACHE_BYTES/MAX_DBCACHE_BYTES match the documented API comments and that the cache split in kernel::CacheSizes remains safe for very small or very large values.

Security signals we found

01

New configurable cache-size API with explicit min/max validation

02

Replaces hard-coded DEFAULT_KERNEL_CACHE with caller-supplied value

03

Adds unit tests for out-of-range rejection and 32-bit upper-bound rejection

04

Uses existing mutex (opts.m_mutex) when reading/writing the new field

Risk score

Why this scored 20/100

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