Bitcoin full node and query server

Mar 7, 2025

View in context in the libbitcoin Slack #general mirror.

evoskuil03:30
I just realized that another major advantage of the approach is that for each insert we must only identify existence (i.e. the first match found). In the current model we always find one (own spend) and must ALWAYS search for a second at least (potential double spends). Even though a second is never found, this means walking the iterator over the same conflict list (which could have any number of non-matching conflicts). So we do two searches for every one point. This approach is upon insert, so the first existing match is a potential conflict. All we need to do is flag that and later in the confirmation phase we can scan for all spends of that point and check confirmation state. So this cuts the paging in half again.
(edited)
👀 1