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

coins: assume `GetCoin` only returns unspent coins

Public commit record

What the developer wrote

Authored by Andrew Toth

85/100 · Strong
coins: assume `GetCoin` only returns unspent coins

`CCoinsViewCache::FetchCoin()` had special handling for a spent `Coin` returned by the parent view.
Production parents (`CCoinsViewCache` and `CCoinsViewDB`) do not return spent coins, so this path is unreachable.

Replace it with an `Assume(!coin.IsSpent())`, drop outdated documentation about spent+FRESH cache entries, and simplify `SanityCheck()` to assert the remaining possible state invariants.
This is safe because it does not change behavior for valid backends and will fail fast if the `GetCoin()` contract is violated.

Co-authored-by: Lőrinc <pap.lorinc@gmail.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit tightens an internal assumption in Bitcoin Core's coin cache. It removes a special code path that handled the theoretical case where a parent view returns a spent coin, replacing it with a hard assertion that this never happens. It also simplifies related bookkeeping and sanity checks. The change is defensive cleanup rather than a fix for a known exploitable bug.

Recommended action

No immediate action required. Treat as normal code-quality/defensive-hardening review. Monitor for any test or fuzz failures triggered by the new assertion, which would indicate a backend violating the GetCoin() contract.

Security signals we found

01

Replaced defensive handling of anomalous parent-view spent-coin return with a hard assertion

02

Removed unreachable spent+FRESH cache state from documented invariants

03

Simplified cache state machine and sanity checks

04

No change in behavior for valid backends; fail-fast on contract violation

Risk score

Why this scored 22/100

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