What the developer wrote
Authored by rustaceanrob
util: Remove `FilterHeaderHasher`
With respect to `std::unordered_map` documentation, the `Hash` type
defined in the template is over the `Key` and not `T`, the value. This
hasher is incorrectly named as the `FilterHeader` is the value within this map.
I consider this a bug as opposed to a refactor as the key and value
relationship is implied to be `filter header -> block hash` when it is
the opposite.
Further, the hasher for the key already exists via `BlockHasher`.
ref: https://en.cppreference.com/w/cpp/container/unordered_map.html
What changed, and why it matters
This commit removes a redundant and misleadingly-named hash function called FilterHeaderHasher and replaces its single use with an existing, functionally identical BlockHasher. Both hashers do the exact same thing—read the first 8 bytes of a 256-bit value as the hash—so the change has no effect on runtime behavior. The author frames it as a naming/documentation bug because the old name wrongly implied the hasher was for filter-header values, when in fact it hashed block-hash keys. It is essentially a code-cleanup change with no known security impact.
No security action required. Treat as routine code-quality/maintenance cleanup. Reviewers may optionally verify that BlockHasher and the removed FilterHeaderHasher produce identical output, which they do by direct code inspection.
Security signals we found
No memory safety, cryptographic, or consensus-affecting change
Hash function implementation is identical before and after
Change is local to a cache used for getcfcheckpt responses
No input validation, authentication, or authorization logic modified
Evidence from the diff
In src/index/blockfilterindex.h, the type of m_headers_cache (an unordered_map keyed by uint256 block hashes and valued by uint256 filter headers) changes its Hash template argument from FilterHeaderHasher to BlockHasher. In src/util/hasher.h, the FilterHeaderHasher struct is deleted. Both FilterHeaderHasher and BlockHasher implement size_t operator()(const uint256& hash) const { return ReadLE64(hash.begin()); }, so the hash computation is byte-for-byte identical. The commit message cites std::unordered_map documentation that the Hash type hashes the Key, not the mapped value, and notes that a hasher for the key (uint256 block hash) already exists. No functional change is introduced.
Changed components
src/index/blockfilterindex.hsrc/util/hasher.hBIP 158 block-filter header cache (m_headers_cache)Inspect captured patch +1 / −5
diff --git a/src/index/blockfilterindex.h b/src/index/blockfilterindex.h
index 85cc8f18..96d393a3 100644
--- a/src/index/blockfilterindex.h
+++ b/src/index/blockfilterindex.h
@@ -51,7 +51,7 @@ private:
Mutex m_cs_headers_cache;
/** cache of block hash to filter header, to avoid disk access when responding to getcfcheckpt. */
- std::unordered_map<uint256, uint256, FilterHeaderHasher> m_headers_cache GUARDED_BY(m_cs_headers_cache);
+ std::unordered_map<uint256, uint256, BlockHasher> m_headers_cache GUARDED_BY(m_cs_headers_cache);
// Last computed header to avoid disk reads on every new block.
uint256 m_last_header{};
diff --git a/src/util/hasher.h b/src/util/hasher.h
index cdf2250b..02c77033 100644
--- a/src/util/hasher.h
+++ b/src/util/hasher.h
@@ -76,10 +76,6 @@ public:
}
};
-struct FilterHeaderHasher {
- size_t operator()(const uint256& hash) const { return ReadLE64(hash.begin()); }
-};
-
/**
* We're hashing a nonce into the entries themselves, so we don't need extra
* blinding in the set hash computation.
Why this scored 17/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.