Mar 10, 2025

So going with Bloom, it comes down to a straightforward tradeoff between filter size and false positive rate. There are no false negatives, but false positives are like hash conflicts and increase as the filter saturates. These can only be resolved by querying the main point table, which of course we want to avoid. Increasing filter size is like increasing table headers. Headers and the filter are randomly accessed and therefore consume most of their size in RAM. Currently the total header set is 16GB, and I'm looking at 4GB more for the initial filter sizing. That eats about 20GB RAM. The reset is preserved for working and paging space as blocks are downloaded, read, populated, and validated. But these aspects are very efficient, not requiring hashmap query and therefore conflict paging, except in the smaller tables, like transaction and bk_validate, and is_strong, even to obtain points - as those are navigated from the prevout parent tx and point index.