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

coins: only adjust `cachedCoinsUsage` on `EmplaceCoinInternalDANGER` insert

Public commit record

What the developer wrote

Authored by Lőrinc

83/100 · Strong
coins: only adjust `cachedCoinsUsage` on `EmplaceCoinInternalDANGER` insert

`EmplaceCoinInternalDANGER()` incremented `cachedCoinsUsage` even when `try_emplace` did not insert (duplicate key), inflating the counter.
This is mostly reachable in tests today since `AssumeUTXO` does not overwrite.

Increment only on successful insert, and capture `coin.DynamicMemoryUsage()` before the move so accounting uses the correct value.

Fuzz: add an `EmplaceCoinInternalDANGER` path to exercise insert-only accounting.
Unit test: emplace two different coins at the same outpoint (with different `DynamicMemoryUsage()`), verify `SelfTest()` passes and `AccessCoin(outpoint)` returns the first coin.

Co-authored-by: Andrew Toth <andrewstoth@gmail.com>
Co-authored-by: w0xlt <woltx@protonmail.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes an accounting bug in Bitcoin Core's in-memory coin cache. A function called EmplaceCoinInternalDANGER was adding the memory size of a coin to a running total even when the coin was not actually inserted because the same key already existed. That could slowly inflate the cache-size counter. The patch makes the counter increase only on a successful insert and also records the size before the coin is moved. The commit adds tests and fuzzing coverage to prevent the bug from returning. It is a correctness and resource-accounting fix rather than a direct theft or remote-code-execution vulnerability.

Recommended action

Treat as a low-severity correctness fix. Reviewers should confirm that all callers of EmplaceCoinInternalDANGER already guarantee non-duplicate keys, or that duplicate-key behavior is now harmless. The regression test and fuzz target should be run in CI. No emergency deployment is warranted, but backporting to maintained branches is reasonable because incorrect cache accounting could theoretically affect memory-limit behavior or trigger assertions in SelfTest().

Security signals we found

01

Resource-accounting imbalance in cache memory tracking

02

Function name contains DANGER, indicating internal unsafe API

03

Fix moves accounting inside successful-insert branch

04

Adds regression unit test and fuzz coverage

05

No direct cryptographic, network, or consensus code changed

Risk score

Why this scored 33/100

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