Bitcoin full node and query server

Mar 25, 2023

View in context in the libbitcoin Slack #general mirror.

evoskuil00:54
Well, I just figured out the likely reason for the input size deflection at segwit, I'm not getting witness-included blocks over the wire. This was nothing more than a config setting that I forgot to update (minimum required services, witness bit). This also explains why the store size came in well below estimate. The optimizations I made in implementation aren't enough to account for the savings. This will increase the size of the base store, and should bring the yellow and red (size of inputs, size of total puts) into the same slope as the others. Not sure what it will do with proportionality, probably not much - as both bytes and time will increase. Though there is proportionally less computation in just serializing more data into the same number of inputs, so it may flatten them out even more. Will run tonight and find out tomorrow afternoon.
👍 1
7 replies · neillm, evoskuil · last Mar 25, 2023
neillm02:46
V3 nodes storage reqs are currently near ~850GB, so ... when mainnet ready?! 🤪
neillm02:48
And amazing work for sure, big congrats! 🎉 This is certainly the kind of underappreciated work that has amazing long term impact 😄
evoskuil04:05
Thanks! I'm hopeful. The 2 years worth of work prior to getting the node running are paying off 🙂.
🎉 1
evoskuil04:11
I'm estimating about 430GB for the base store, and about 480GB with all validation/confirmation metadata. And with address indexation, around 500GB. Still better than 850 🙂.
neillm04:12
Awesome! Yes, way better!! 🎉
evoskuil04:12
But way better in a lot of ways.
evoskuil04:14
The native data is fully indexed for constant time navigation in all directions. Address index will capture all inputs/outputs using the Electrum addressing index mechanism. Read and write should be significantly faster and less disk intensive, with append only data tables.
👍 1