Apr 18, 2024

Is 3 hours bad? I don't think so, right?

3 hours as a minimum for a full chain download, validation, and confirmation is excellent.

The concurrent download can happen in half that time, and I'm hopeful that concurrent validation can beat 3 hours. But combining them will increase each unless maybe with full chain RAM.

In any case, it's a very positive data point. The confirmation is extremely costly in theory. You must mark each output (or its tx) as confirmed, and must mark each spending input as confirmed (or its tx), ensure that when you spend you are only spending outputs that exist, and are confirmed in tx of a block height at/previous to the input tx, and must ensure that they are not previously spent by a confirmed block tx. Then there are coinbase maturity checks (spender must be > 100 blocks from coinfirmed cb height), and finally relative locktime checks (bip68), which require the height and mtp of spender and spent, as well as spender tx.sequence.

Core does this by maintaining a redundant hash table of unspent outputs (the output object including script, indexed by tx hash). By adding and removing from this redundant data, these questions are more simply answered. But it introduces not only a large amount of redundant data, but a heavy ordering requirement.

Our approach does not update any primary blockchain table data or maintain any redundant data. We just maintain a hash table of associations from tx to confirming block, one entry per tx. A negative entry in the same table reorgs out the confirmation. That's it. So getting those answers and updating the confirmation table that fast is pretty good.