Feb 6, 2025

In the above table, there would be over 300k spends that would encounter no conflict (14%). This means that the point table would now be unsearched for each of these - never even accessed. Singular entries in the spend table multimap would imply the current spend is the only spend (which is verified at no cost by comparing the spend pks). The remainder would compare hashes in the point table for each conflict that is not self. That reduces to n-1 hash compare for each n conflicts. So for 2 conflicts above (41% of all spends) that's one sha256 compare in the point table. This drops off logarithmically, 31% require 2 compares, 12% require 3 , and the rest is inconsequential. And again, no searching and comparing all conflicts in the point table. The cost tradeoff is 4 bytes extra per spend. That's not trivial, presently 49GiB (7% increase).