Is it possible to add nodes for faster Bitcoin Core sync?

I'm using a prune node. I heard Bitcoin Core connects to various remote nodes. Can I add some nearby nodes to make the syncing process faster? Also, where can I find a list of nodes?

In my experience, it's not needed. If your ISP isn't throttling you, Bitcoin Core should find fast enough nodes on it's own. Odds are the rest of your hardware is more limiting though.

Exactly what Loyce said above. The only thing, in my experience, that will significantly increase your speed is the dbcache option. Set it high enough. Of course, provided that the hardware is proper: 1. high RAM 2. SSD instead of HDD 3. USB 3 connection if the disk is external 4. high internet speed 5. good ethernet connection cable

I accustomed myself to VPN service when connecting Bitcoin Core to peers and sometime, being connecting via servers with the certain IPs, experienced the slow sync. Changing VPN server (by simply choosing different country for it) and relaunching Bitcoin Core after that usually helped  to to speed up the sync,   in which cases,  the connected nodes were modified. And,  I would add blocksonly=1 entry in bitcoin.conf file and set the correct value of dbcache in it. In general situation  the rule of thumb dbcache=1/4 RAM, i.e. for 8 Gb of RAM  dbcache=2048

Good suggestion. Recently I downloaded the whole blockchain in 72hrs using a Raspberry Pi 4b with 8 GB RAM and a 2TB SSD. I used dbcache=5000 in terms of configuration. Just make sure to change the conf and restart bitcoin core after the IBD is finished.

If your VPN can't handle the bandwidth, obviously changing can help. I prefer to have dbcache > chainstate, but that only works if you can allocate 10 GB to it. I wouldn't recommend a quarter of your RAM, that depends on what else you're doing on the system.

It's been a long time since I last performed an IBD, but I thought transactions were not downloaded or added to your mempool until your node was full synced (since your node will be unable to verify if a transaction is valid until it is fully synced). If that's the case, then blocksonly=1 should make no difference to the speed of the IBD, since you aren't syncing transactions anyway.

Yeah, you are correct. blocksonly=1 helps to speed up a little the initial block download and at node being fully sync  the entry should be commented/deleted. Another case when this entry is helpful is the resuming sync after long nod's deadtime . I accustomed myself to turn off my node at going for two-tree weeks vacation and be back usually activate this entry in  bitcoin.conf file until sync is completed.

Check your peers' ping first if it's really the cause of your slow IBD: Click the network icon below and select "Show peers tab", or click "Window->Peers". Or via command: getpeerinfo It'll only be slow if you're exclusively connected to very slow nodes which rarely happens; Most of the case, it's the hardware and node settings.

Block downloads are highly parallelized, and it would be difficult for you to obtain only the slow nodes unless you were intentionally doing so. Misbehaving or slow nodes would be disconnected by your client after a certain threshold. Hence, it would be likely that you are experiencing slow validation because of hardware limitations. Besides, you can only connect to a maximum of 10 other nodes. You can take a look at your task manager for more statistics and check if there are other bottlenecks in your system; CPU, memory or I/O speeds. They are the likely culprit.

As stated by other user, usually there are other factor which limit sync speed. But FYI if you use Bitcoin Core, you can't connect to more node since Bitcoin Core only let you connect up to only 10 nodes (outgoing connection). The only way to increase that is by editing Bitcoin Core source code and then compile it. There are many website such as bitnodes.io/ which provide such list, but you can't know which of those have fast connection.

Thank you. I have another question. IBD, why every node has to do it? If I only run a prune node, I can not use my node to check too old block details like genesis block, because it exceeds my prune node limit. I feel it is like unnecessary to sync it from genesis block. It is more convenient if I set my prune node is 50 GB and I start directly at a past block that accounts for 50GB data till the current newest block. Block 0 https://blockchair.com/bitcoin/block/0 hash 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f I get this

Convenient - YES Possible - NO Bitcoin Core deletes previous history data  after their downloading and verification. That’s how it works, and there’s nothing you can do about it. I think this due to the implemented  procedure design  to index both the chainstate and blocks  on disk that keep copy of pruned blockchain.

You can of course use prunednode.today, and download a pruned node. I just tried: it took my server 75 seconds. But you'll never be absolutely sure it's completely legit. And if enough people do it, someone will find a way to scam them. This guy knows a thing or 2 about the subject:

You can actually have 18 outbound connections in total - 8 automatic full relay connections, 2 automatic blocks only connections, and up to 8 manual outbound connections using the addnode command. I do agree that adding more nodes will make no difference to the speed of the IBD, though.

Downloading whole blockchain is necessary to verify that all transaction and block follow Bitcoin protocol/consensus. And if OP want more recent data, he can check https://bitcoin-snapshots.jaonoct.us/. I haven't tried it, but the owner also provide assumeutxo file which should be better than copy of Bitcoin Core folder.

You don't need to query for data of a block, in fact, Bitcoin Core also doesn't look at the earlier blocks after the initial synchronization. That is other than the startup which checks for the last XXX blocks, can't remember how many off the top of my head. The reason for IBD is to ensure that the chainstate is built correctly, hence all of the unspent outputs are correctly indicated. It would then be impossible for a rogue node to falsify transactions with inputs that doesn't exist. Risk is relatively low, but it doesn't mean that it is impossible. If you are unable to conduct IBD for your Bitcoin Core node, I would recommend using an SPV wallet instead.

Thank you. Thank you too. Thank you too. From your replies, I understand like chainstate is important to check status (spent  or unspent of UTXOs from previous blocks) and it will be stored on my Bitcoin Core prune node. Other data will be deleted after IBD.