Feb 6, 2025

Our hashmap functions for sha256-hash keyed hashmaps is a no-op. It's just the low order bytes of the hashes. So not only is it a good distribution, but we can obtain it at no cost. But this isn't the most interesting aspect. By making the spend table search key a function of the point hash, all conflicting spends would necessarily share the same spend table search key. So it is unnecessary to read the point table at all unless there is a conflict. It's not necessary to know the point hash, as the spend for which we are investigating conflicts is already indexed with the foreign point that all conflicting spends must have. This would be the case if the point table was guaranteed to be unique, but it cannot be. So if there are no conflicts with the foreign point of the spend (i.e. a search finds only itself) then there is never a read of the point table during the search. And if there is a conflict in the spend search, the spend can directly identify its point (which it presently does via the foreign point). This implies extra bytes per spend to account for the hash function value in the search key while retaining the point pk.