Mar 7, 2025

It seems like there’s always some other option to try. A sufficient requirement is that we need to know if a second point exists for any point that we validate, when we validate it, even if we validate blocks out of order. This is because of the partial order constraint that all prior blocks in the validating branch are archived. So the possible double could not be missed. False positives are ok and expected. During validation we read the entire block and all of its prevouts. Each prevout attachment requires that we search the point table to find the tx of the previous output, so we can obtain the output. This is the only way inputs are associated to outputs. For some reason, this is reasonably performant on the mini. Download and validation/confirmation completes in under 8 hours, without the spent query. So to determine the existence of a potential double, we can iterate past the first match to any second. This doubles the input point search cost. But since points are already scattered across a hashmap it seems that this shouldn’t produce a non-linear increase in cost. The cost is no more than 5 or 10% of the run presently.