Bitcoin full node and query server
Oct 21, 2024
View in context in the libbitcoin Slack #general mirror.
evoskuil22:06
I'm consistently hitting 46 minutes of a full chain (866k blocks) sync with default config on the Windows mini, and 61 minutes with my big box config. I'm working out what the difference is. Have shaved off 4 minutes by reducing the table growth rates to 5% (default) vs. 15%, and by reducing the outbound peer count from 200 to the default of 100. I suspect the rest is turning on automatic snapshotting, which I'll run now.
🔥 3
3 replies · evoskuil · last Oct 22, 2024
evoskuil17:51
Well I tracked this down. In our configuration we have settings for min and max services.
services_minimum = 9 # witness node services_maximum = 9 # witness node
This is how I've had my config file set up for a long time. However running with default config, the min is set to 1. Because this results in the node not requiring witness capable peers, this implies the node is not a witness node, and everything operates pre-witness serialization. This drops a large amount of data from the input table, where the witness is stored. I first noticed it there, and then figured out that node default value was 1, so when running without config we shaved off 15 minutes. So the reported 45 minutes is legit, but it's for non-witness (legacy node). The witness-included sync remains at about 60 minutes.
(edited)👍 2
evoskuil18:55
So I just completed a full run with the witness config, verified the result, and it came in at 47 minutes (to benchmark block 840k), probably because I took out the 5 snapshots from default config. I also recomputed the theoretical limit based on block download alone (no other messages up or down) of [609,888,208,331] bytes, on my (measured) 2.3Gbps Internet to the top block [866,881]. It comes out to 36 minutes, where that block took 52 minutes. So we're still only 68% efficient.
(edited)