Bitcoin full node and query server

Mar 27, 2023

View in context in the libbitcoin Slack #general mirror.

evoskuil06:43
Spent the day cleaning up sizing spreadsheets, updating table initialization defaults, reviewing capacity and perf. When some numbers didn't line up exactly I determined that I was incorrectly treating the validation tables as records but I had changed them to slabs so that values could be compressed. This creates a different link sizing requirement, and sure enough when I reviewed the link capacity, the validated_tx table was well over capacity. The validated_bk table was well below. This explained why set_connected(tx) population run accelerated significantly after a certain value. The link had overflowed, resulting in logical failures (which are fast). I'm summing up logical results, but there are expected failures due to the simulation. So after updating the build, the set connected run took 28 mins vs 9. All still constant time. This is still well within criteria, especially given that these calls will run concurrently.
(edited)