Feb 6, 2025

A recent change I had made to the first query was to expect success (prevout confirmed) and only if it is not confirmed, search for other possible identical transactions (same but with other ids) in the strong_tx table. This is costly, but rare. In a normal run there are only two duplicate txs (bip30 exceptions) and these don't spend. So performing the extra step as necessary is essentially free. The second query is a different problem, because the search must be exhaustive. The issue then is that txs with the same hash don't have the same primary key, so natural keys (tx hash) must be searched to correlate both spends and confirmations. But we cannot ensure that no duplicates enter the store, as that requires a search for every insert. That tight coupling makes archival (download) very slow. However, the hashmap hash of each identical hashmap element must of course be the same. These duplicates show up as hashmap conflicts and we simply walk the conflict list using an iterator to key on matching search keys, which makes any hash table a multimap.