Apr 17, 2024

Spent some time working out the query to handle the three forks that make up bip30 handling. This is the only one I hadn't worked out in the design, because it wasn't absolutely necessary. But for consistency we should have it as in some fork configurations it must be applied. It can be costly to implement, but I worked out a constant time solution. The difficulty for us arises from parallel writes with minimal locking. It is possible to end up with duplicate instances of any block, header, tx... in the store. This is the result of races, but extremely rare and logically a non-issue. But in this one case, the number of instances of a duplicated coinbase tx matter, and the instances of associated confirmations of it, spends of it, and confirmations of the spenders. So it presented a bit of a challenge. But I found that, because every spend association commits to is spending tx by surrogate key, and every tx confirmation commits to its confirming block, we can count up the total number of uniquely confirmed (by block key) duplicated coinbases, and the total number of unique spends (by spender key) uniquely confirmed. The difference gives us the desired result - 0 means all spent, 1 means one unspent, -n and n> means fault, n > 1 means fault. Since each query iterates only these unique instances and they are essentially always singletons, it's not too costly if/when it's enabled.