Jan 13, 2025

I've just merged the changes to write the prevout cache for validated blocks. Only the prevout parent tx primary key and its coinbase-ness are written, and I've merged the coinbase bit into the 32 bit tx pk word (enough space for like 8 more years). I'm not sure that writing the spend pk will be necessary, but that can be quickly added. The writes are bypassed for block-internal spends, as these spends are confirmable as long as they pass relative locktime checks, which require no chain context apart for bip68 activation. So this is checked during populate for validation. This saves about 9% of "is-confirmed" confirmation calls. No space is saved because I'm using a sentinel value to maintain prevout positions within the block. This eliminates the need for storing a count, and provides an easy correlation to spends that do not need to be checked for "is-not-double-spending", saving 9% of those confirmation calls as well. I spend a good part of the day isolating a problem that turned out to be that I needed to check for bip68 activation before applying the relative locktime checks in populate. That's now merged and I'm running a performance test to get the performance cost of the additional writes (and relative locktime checks, which should be trivial). Next is to adapt the confirmable query by incorporating the prevout cache, and then measure the performance change on the maxi/mini machines.