Feb 6, 2025

Another related consideration is that of strong_tx indexing. Presently the tx table pk is the search key for the strong_tx table. This means that the same tx can be strong (confirmed) under any of the pks under which it may be stored. This means that the exhaustive search above must exhaust them all. This means searching the tx hashmap (using the sha256 hash of the tx) to obtain the pks, until all are excluded. I've considered indexing this table on the hashmap hash of the tx's sha256 hash a well. This would also require secondary conflict resolution, but would preclude searching the tx table or using the 32 byte search key. This resolution could be satisfied by storing the pk of the specific tx confirmed in the row. This would then allow for an immediate search using information immediately available in the spend row (the hashmap hash of the tx sha256 hash is the spend search key), which would eliminate any tx table searching. The implied storage cost is 4 bytes per tx, presently 3.8GiB.