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

coins: use SipHash-1-3-UJ for `CCoinsMap`

Public commit record

What the developer wrote

Authored by Lőrinc

68/100 · Adequate
coins: use SipHash-1-3-UJ for `CCoinsMap`

Use the fixed-width `SipHasher13UJ::Hash` path for `CCoinsMap`, while keeping other `SaltedOutpointHasher` users on SipHash-2-4.
The salted outputs are process-local and must not be persisted, serialized, or compared across processes.

Retained cache entries identify real transaction outputs and therefore contain computed txids.
Missing-input validation may probe arbitrary claimed prevouts, but `FetchCoin()` erases each temporary entry immediately when the backend lookup fails, so non-hash keys cannot accumulate.
The assumeutxo loader assumes snapshot txids are valid while loading and verifies the complete snapshot content hash before activation.

Co-authored-by: Pieter Wuille <pieter@wuille.net>
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit changes the hash function used inside Bitcoin Core's in-memory coin cache (the UTXO cache) from SipHash-2-4 to a faster SipHash-1-3 variant. The change is framed as a performance optimization. The commit message and code comments explicitly argue that the weaker hash is still safe here because the keys are real transaction IDs, attackers cannot inject arbitrary long-lived keys into this cache, and the hash values are never saved to disk or shared between processes. There is no direct evidence in the commit of an exploitable vulnerability, but it is a deliberate relaxation of a cryptographic primitive in a security-sensitive data structure, which warrants scrutiny.

Recommended action

Treat as a routine but security-relevant optimization. Reviewers should verify that (1) no new code path allows attacker-controlled `COutPoint`s to become long-lived entries in `CCoinsMap`, (2) the `noexcept` hash contract is preserved so libstdc++ does not store cached hash values that could be leaked or misused, and (3) the deterministic salt constants are only used in tests/fuzzing and not in production. No immediate patch or incident response is indicated by the supplied materials.

Security signals we found

01

Reduced-round SipHash (1-3 instead of 2-4) introduced for a core security-sensitive data structure (UTXO cache).

02

Commit explicitly addresses attack surface: arbitrary prevouts cannot accumulate because FetchCoin() erases temporary entries on backend miss.

03

Hash outputs are process-local and not persisted/serialized, limiting cross-process collision attacks.

04

assumeutxo loader relies on full snapshot content-hash verification before activation, mitigating collision-based snapshot manipulation.

05

No CVE, advisory, or vendor security disclosure is present in the supplied materials.

Risk score

Why this scored 26/100

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