May 2, 2025

Found and resolved the issue. The newish arraymap primitive has an expanding head, but was never previously read past it's limit due to the nature of the confirmation prevout query that consumed it. I changed two more tables to arraymap (validated_bk and txs) and in these cases the tables are read for items that may not be found just due to lack of ordering. When the element searched is greater than the head allocation there is a read protection fault. When writing there is no problem because a write would just expand the head. The low level file does not guard against such overflows, because at such a low level that's a big performance expense for all tables, most of which wouldn't benefit from it. The arrayhead test cases didn't cover it, because they were derived from the hashmap tests, and hashhead doesn't resize. So test added, simple fix within the arrayhead. https://github.com/libbitcoin/libbitcoin-database/pull/629