[solved] blocks folder of pruned node keeps growing

[darkv0rt3x]

Hello,

I've just installed the pre-compiled binaries of bitcoin core into a RockPro64 board and with the following config file, the blocks folder keeps growing. It is now with 163Gb and it shouldn't,
I think. What am I doing wrong here:

Code:

dbcache=2048
par=1 -daemon
server=1
rpcauth=bitcoin:[REPLACED]
rpcallowip=127.0.0.1
rpcport=8332
maxtxfee=0.00002000
mintxfee=0.00000002
network=testnet
 
# Options only for testnet
[testnet]
debug=net
debug=tor
debuglogfile=/media/Storage/blockchain/debug.log
addresstype=bech32
changetype=bech32
listen=1
prune=550

Just a side note. When I started this node, I forgot to delete the line 'txindex=1' and only noticed that when blocks folder was already 60Gb big. Then, I removed that line from the config file and restarted the daemon, but the blocks folder kept going and still is. What I need to do to force the daemon to use the config line 'prune=550' and stop blocks folder from growing?

[nc50lc]

You can add -prune=550 as an additional start parameter instead.

For the bitcoin config issue, is it located in the default directory?
If not, try to put the entries in the default data directory's bitcoin.conf file whether you're using a custom datadir or not.

[darkv0rt3x]

I think I found the problem.

I can't have the prune=550 config line inside the [testnet] section. It must be out of it.
But I'm still not sure it's all good now because I've been told more than once that for a pruned node to get sync'ed, it takes like 2 or 3h. But not in my case.
It's now almost 20h and it is still at 06/2019.

Is this normal or it should be way faster? I'm running this on a Samsung 970 Evo Plus NVMe M.2 drive.

[LoyceV]

I've been told more than once that for a pruned node to get sync'ed, it takes like 2 or 3h.

That's very optimistic A pruned node still needs to download and verify about 350 GB of data.

But not in my case.
It's now almost 20h and it is still at 06/2019.

Is this normal or it should be way faster?

Depending on your other system specs, this seems normal. It should be done by tomorrow.

[darkv0rt3x]

I've been told more than once that for a pruned node to get sync'ed, it takes like 2 or 3h.

That's very optimistic A pruned node still needs to download and verify about 350 GB of data.

But not in my case.
It's now almost 20h and it is still at 06/2019.

Is this normal or it should be way faster?

Depending on your other system specs, this seems normal. It should be done by tomorrow.

This is a RockPro64 board with 4Gb of RAM. It uses a Dual-core Cortex-A72 up to 2.0GHz CPU an a Quad-core Cortex-A53 up to 1.5GHz CPU.
But I think the main role in the process is at the capability of read/write of the storage drive which is pretty much the best we can get at an affordable price (the Samsung 970 Evo Plus NVMe M.2 drive).

But I'm still not sure it's all good now because I've been told more than once that for a pruned node to get sync'ed, it takes like 2 or 3h. But not in my case.
It's now almost 20h and it is still at 06/2019.

Is this normal or it should be way faster? I'm running this on a Samsung 970 Evo Plus NVMe M.2 drive.

That depends on your hardware, but obviously there's bottleneck. On blog 2020 Bitcoin Node Performance Tests, he uses Samsung 960 EVO 1TB M.2 SSD (similar to yours) with high-end hardware and managed to fully sync in 5 hours 41 minutes.

But IMO 20h to reach 06/2019 is quite fast since some people took days to weeks to fully sync Bitcoin node.

yeah, I guess my bottleneck now is on the CPU computing power.

[HCP]

But I'm still not sure it's all good now because I've been told more than once that for a pruned node to get sync'ed, it takes like 2 or 3h. But not in my case.

Pruning (in general) doesn't really sync any faster or slower than when not pruning... It still has to download and verify everything like a "standard" node... the only real difference in the process is that it doesn't store all the block data.

So, expect it to take as long as it would if you were just syncing normally.