Mar 22, 2023

In the first run I encountered a simple script deserialization failure, which is resolved. In the second run I encountered a link overflow. This was due to running multiple peers in a race for blocks. Since there is not yet a block chaser to eliminate redundancies, the store had a large amount of redundant writes (stopped at ~800GB at ~block 600,000). These become orphaned naturally and are not technically a problem. However the tables use byte-aligned internal links that are sized based on expected table size. This run overflowed the txs association table link (4 bytes), effectively killing the run. I hadn't added a runtime guard in for this scenario, but I figure it's worth the trivial extra check. So that's included now. The node will encounter a handled write failure in the case of link type overflow, and this implies that the node must be recompiled using a larger link capacity for that table. In v3 links were all either 32 or 64 bytes, which had the same issue but also wasted a huge amount of space. Presently we use 3/4/5 byte link sizes. The third run (with one peer, so no redundancies) completed as expected. In analyzing sizes I noticed that the both this run and the previous overflowed the puts association table link. But in this case there would be no failure unless a read of the txs is attempted. In the case of txs there was a read in order to test for block existence, which caused the halt. The reason this run overflowed puts is that my estimate of inputs/outputs count was too low. As configured it was targeting 78% capacity, but it hit 104%. This means the link type for puts must be increased from 4 bytes to 5. That implies a .7GB store increase. All link types now have cushion in bitcoin for many years to come.