The Logic of the Hash: Determinism and Memory Safety

[!NOTE] Technical Context: private_broadcast.h | Lines 162-168

In lines 162 through 168 of private_broadcast.h, we encounter the Hashing Infrastructure of the class. Specifically, the architect defines a custom hasher for CTransactionRef. This block is a fascinating study in the balance between Security and Performance, revealing how Bitcoin Core handles its most sensitive internal maps.

1. The "No Salt" Decision: Trusting Local Data

The code begins with a significant architectural comment (Line 164): "No need for salted hasher because we are going to store just a bunch of locally originating transactions."

What is a "Salted Hasher"?

In many parts of Bitcoin Core, specifically the Mempool and the UTXO set, developers use a "Salted Hasher" (a hash function that includes a secret random key). This is a Security Defense against "Hash DoS" attacks, where an attacker sends millions of transactions designed to collide in the node's hash table, slowing the node to a crawl.

Why "No Salt" Here?

The PrivateBroadcast module only handles "locally originating transactions" (those generated by the user's own wallet). Because the data is Trusted and Local, there is no risk of an external attacker performing a Hash DoS. By choosing a non-salted hasher, the architect is Reducing Complexity and Increasing Speed. It is a "Context-Aware" security decision—the node doesn't need to protect itself from its own owner.

2. struct CTransactionRefHash: The Identity Function

Line 166 introduces the hasher struct. In C++, a hasher is a "Functor" (an object that acts like a function). This hasher is required because CTransactionRef is a smart pointer, and the standard library doesn't know how to hash a smart pointer in a way that respects the transaction's identity.

3. The operator() Signature

Line 167-168 defines the entry point: size_t operator()(const CTransactionRef& tx) const.

This operator takes a constant reference to a transaction and returns a size_t (a 64-bit integer on most systems). This integer is the "Index" that the unordered_map will use to find the transaction.

4. Hashing the Reference, Not the Bytes

The key to this implementation is that it hashes the Transaction's Identity. Even though CTransactionRef is a pointer, the hasher doesn't hash the memory address (which would be useless if the transaction was moved). It hashes the Transaction's Contents (or its pre-computed hash).

This ensures Deduplication. If the wallet adds the same transaction twice, the hasher will produce the same result both times, allowing the Add() method to correctly identify the duplicate and return false (as discussed in Part 0009).

5. Architectural Synthesis: The High-Speed Index

By providing a custom hasher, the PrivateBroadcast class can use a std::unordered_map<CTransactionRef, ...>. This is the most efficient way to store a set of transactions.

The hasher is the "Gatekeeper of the Map." It ensures that:

• Lookups are O(1): Finding a transaction is instant, regardless of how many are in the queue.

• Memory is Safe: By using CTransactionRef, the hasher respects the smart pointer's reference counting, ensuring the transaction isn't deleted while it's still being hashed.

• Logic is Clean: The rest of the class can simply use the transaction as a key, without worrying about the underlying hashing math.

Conclusion: The Trust of the Local Node

Lines 162-168 represent the "Trust Model" of the private broadcast system. We have seen that the node differentiates between "Foreign" data (which needs salted hashes) and "Local" data (which is trusted). This nuance is what makes Bitcoin Core "Efficiently Secure"—it only pays the performance cost for security when there is a real threat. The hasher is the "Silent Servant" that ensures the internal memory of the node remains fast, organized, and reliable.

In the next batch (0025-0030), we will examine the implementation of this hasher and the m_mutex that guards the resulting map.