After all night running, on nvme, a powerful CPU and with plenty of RAM, it took several hours to reach 65% and is stuck there. Now all peers are blocked for some reason and is not syncing anymore. Command used: ``` monerod --data-dir /flash/monero/ --prune-blockchain --sync-pruned-blocks --db-sync-mode=fast:async:250000000 --fast-block-sync 1 --prep-blocks-threads 8 --block-sync-size 100 --max-concurrency 8 --no-igd --no-zmq --enable-dns-blocklist --out-peers 16 --in-peers 8 ``` logs: ``` ... 2026-02-17 07:54:36.217 I Host 95.217.7.137 blocked. 2026-02-17 07:54:36.217 I Host 95.217.7.248 blocked. 2026-02-17 07:54:40.113 E Too many object fields 2026-02-17 07:54:40.116 E Exception at [portable_storage::load_from_binary], what=Too many object fields 2026-02-17 07:54:41.609 E Too many object fields 2026-02-17 07:54:41.611 E Exception at [portable_storage::load_from_binary], what=Too many object fields status Height: 2365820/3611892 (65.5%) on mainnet, not mining, net hash 2.70 GH/s, v14, 16(out)+0(in) connections, uptime 0d 0h 0m 16s ``` All I want is to finish sync and measure the CPU time of validating transactions after the initial sync, to compare with bitcoind and see how it would scale.

I take it back, you don't seem to be technically ignorant or a liar 🙏 but I've never had a the Monero daemon hang like that. You're running this locally, not a VPS right? what kind of internet do you have? is /flash removable storage? @shortwavesurfer2009 @Saberhagen The Nameless

You might want to sync without giving it too many parameters at first. Pruning will still need to download the whole chain. I usually need something like one night to sync a new node, but I don't want to benchmark the process on my mediocre systems anyways. You might want to push this to github to see if you discovered ba bug.