Bitcoin full node and query server

Apr 20, 2026

View in context in the libbitcoin Slack #general mirror.

evoskuil05:26
So the approach is to rely on the relative stability of confirmed history, and recompute unconfirmed history on each even. Fortunately the sort places confirmed history first in the preimage. The simple approach is to wipe the midstate cache whenever there is a reorganization (confirmed block height reduced), because the midstate cannot be rolled back. The address hash table is a multimap, which allows iteration from the bucket to the end of the conflict list (though the iterator skips over conflicts and only exposes matches). So it presents as a stack, with the most recent item at the top (in the hashmap bucket). So we store the top at the start of the iteration, grab all of the entries and spenders, sort by confirmed state, and hash the confirmed ones using the streaming hash accumulator. Once the last confirmed is committed to the accumulator, we save off the accumulator to the subscription, and continue with the unconfirmed. The set of unconfirmed can change completely given just one new tx in the mix, so there is no benefit in caching. But the number of them is generally trivial by comparison. For the 5M output address there may be zero or one touch unconfirmed. Still, we need to find all of them, and they can be any depth in the stack for a given address. So on the first iteration, we read the entire set. On subsequent iterations, we set the iterator to stop at the previous top, and we read for confirmed entries only. We sort and hash these into the midstate, update the cache, and then read the entire stack for unconfirmed entries. Since this will be updating with each block (at least) the confirmed query will be trivial and require almost no hashing. The unconfirmed iteration ignores all entries for which the associated tx is not associated to a block (not strong). However it still hits every single element in the conflict list (e.g. 5M). But the cost of this query is dramatically reduced because there are a trivial number of unconfirmed, and new entries require a fee computation prevout confirmedness, and position/height. So basically, by caching the midstate, we still have to run a long iteration, find each tx instance, and check each for confirmation, but overall the query cost is cut dramatically, and the hash cost is eliminated almost entirely.
(edited)