Bitcoin full node and query server

Jul 12, 2026

View in context in the libbitcoin Slack #general mirror.

evoskuil16:40
After initially optimizing the full vertical table implementation for minimal locking (1 vs 4 per composite 4 column table), and eliminating all allocations during multisig capture, I found that there was still a significant performance issue. Eventually I was able to determine that this was chaotic behavior not caused by any single inefficiency (like table allocator locks or copy and malloc excess) but instead by insufficient control over batch sizes. The config sets a minimum batch size, and then the node cuts off the capture in the validation message pipeline. However because a full window worth of block validations (e.g. 50k blocks) can pass that gate almost immediately, being queued up for concurrent validate, the result is a pressure wave that eventually cuts out all batch draining until the window closes. This dramatically oversized the batch tables creating a large amount of I/O back pressure. This was exacerbated by an oversight in the calculation of the window itself when batching, as using the prevalid state (validated and batch accumulated, but sigs not yet verified) and the valid state (post-verify) led to a doubling of the intended window size. After resolving this so that it maintains the window only on the valid state, performance was materially improved. But the major issue of excessive table sizing remained. Prior to optimizing above, the full validation run bypassing sig verify took about 6:00. After the above changes that was down to around 4:00. Then made the change to increase control over table excesses, but moving the batch cutoff out of the ASIO message pump and into the executing validations. At the same time I removed the reader-writer mutex lock that was set up to guard the batch tables during verify, replaced with an atomic turnstile. This reduced the above total time to 3:18 as it brought batch tables into a very well-controlled range (1.0 - 1.2x of target). However the turnstile was set up to allow blocks to continue to validate (unbatched, with inline sig verify) when the batch cutoff was signaled. This allowed about 24% of all batchable signatures to bypass capture. That's about 43 minutes of pure sig verify cost. This is far greater than optimal, so I've modified the turnstile to allow blocks to write into the batch cutoff, while still allowing them to validate inline during the batch verify. It may turn out that validating during GPU verify is also suboptimal, as pre and post-processing the GPU may be slowed by it, in which case that can be adjusted as well.
(edited)