<p>I didn't have enough reputation to add a comment to the accepted answer. But here's what I have learned:<br />
I'm running Bitcoin Core Version v0.20.1 and Linux Mint 18.3 on pretty old hardware. Pruning blockchain to 2 GB and setting <code>dbcache</code> to 2048 MiB didn't actually help.</p>
<p>Moving the <code>datadir</code> to a USB-Stick did the job for me. Which is weird since my disk is connected too via USB. Maybe there is an issue with how bitcoin-qt is handling its cache? An in-memory cache shouldn't behave like that. At least I wouldn't expect it to.</p>
<p><strong>Note: Using a USB-Stick is not recommended!</strong>
It can cause bitcoin-qt shutting down due to database errors.</p>
<p>So, if it's neither CPU nor bandwidth check your disk I/O.</p>
<p>On Linux you might want to try:</p>
<pre><code>iostat -x 5
</code></pre>
<p>To figure out which device is what disk, you can use</p>
<pre><code>cat /proc/mounts
</code></pre>

CC BY-SA 4.0
2020-10-29T13:45:31.840Z
Hi pisjatblin, in case you didn't see, this question was resolved four years ago. However, if you see the comments on Pieter's answer, some users have found that disk I/O was indeed their bottleneck. It would be great if you could extend your answer a bit in that direction.
Murch
CC BY-SA 4.0
2020-10-30T17:06:19.307Z
Hi Murch, thanks for pointing out. I was too noob to add a comment to the answer (lack of reputation). So I did my best to put here what I have learned.  I'm running Bitcoin Core Version v0.20.1 and Linux Mint 18.3 on a pretty old hardware. Pruning blockchain to 2 G and setting dbcache to 2048 MiB didn't actually help. Moving datadir to a USB-Stick did the job for me. Which is weird since my disk is connected too via USB. Maybe there is an issue with how bitcoin-qt is handling its cache? An in-memory cache shouldn't behave like that. At least I wouldn't expect it to.
pisjatblin
CC BY-SA 4.0
2020-10-30T17:19:05.500Z
Hi pisjatblin, thanks for the explanation! I wasn't sure whether you had meant to comment. I've copied your explanation into the answer. Maybe you could take another look and edit it further to round it out!
Murch
CC BY-SA 4.0
2020-10-30T17:53:25.290Z
Hi Murch, thanks for your kind help converting my input in a readable output! :)
pisjatblin
CC BY-SA 4.0
2020-10-29T03:28:10.480Z
2020-10-31T02:14:31.443Z
2020-10-31T02:14:31.443Z
pisjatblin
<p>downloading 150 Gigabyte will always be very slow. Some suggest to set "listen" to "off" but this has no effect on speed. You might, at intervals, ban the slowest 3 nodes, so you get pretty fast nodes after a while.</p>

CC BY-SA 4.0
2018-12-25T09:13:29.610Z
The problem was not with network bandwidth, but with the fact that Bitcoin verifies all the blocks and it takes a lot of CPU resources. The 150 GB could be downloaded within 2 hours on my network, but it will take much more time to verify all those blocks. And the good CPU will really help in speeding up this process.
Slava Fomin II
CC BY-SA 4.0
2018-12-24T15:51:14.527Z
2018-12-24T15:51:14.527Z
dotbit
<p>What usually takes time is the validation of the transactions in the blockchain, not downloading it. Bitcoin Core implements a fully validating node, which does not trust any of the information other peers give it. The only way to accomplish that is by validating everything itself.</p>

<p>30 hours sounds painfully long though. If you have memory to spare on your system, you absolutely should increase the database cache size. The default in 0.13 is 300 MB, but you'll see very significant speedups from using a higher value, up to 4000 or so (which would require an extra 4GB of memory).</p>

CC BY-SA 3.0
2017-06-03T01:27:10.993Z
Ugh, its already been taking me *days* and it still says 3 days to go.
B T
CC BY-SA 3.0
2016-11-11T19:08:21.390Z
Thanks Pieter, that makes perfect sense. I will try to increase the cache size then and will see if it helps!
Slava Fomin II
CC BY-SA 3.0
2016-11-11T19:16:34.267Z
By the way, is it safe to download blockchain from some third-party, will bitcoind validate it?
Slava Fomin II
CC BY-SA 3.0
2016-11-11T20:35:42.783Z
You can download a bootstrap.dat file (which contains just blocks to process at startup, as if they were received from network). Do *not* download a full database copy, bitcoind does not and cannot know you copied from a potentially untrustworthy party.
Pieter Wuille
CC BY-SA 3.0
2016-11-11T20:55:50.540Z
Thanks! Please consider adding this info to the answer, so other users could also easily find it.
Slava Fomin II
CC BY-SA 3.0
2017-10-24T20:37:51.127Z
How do we increase the database cache size?
Shamoon
CC BY-SA 3.0
2017-10-25T00:16:02.823Z
Using the `-dbcache` command line option, the `dbcache` config file option, or in the settings menu in Bitcoin-Qt.
Pieter Wuille
CC BY-SA 3.0
2017-12-03T09:01:26.380Z
If anyone else has a similar problem: what really made a difference for me was moving the chainstate directory to a ssd. Now it's about 10x faster.
Jure1873
CC BY-SA 3.0
2017-12-03T13:48:16.023Z
@Jure1873 Did you try increasing the dbcache size? Disk speed should be almost irrelevant if you can give it a few GB of cache.
Pieter Wuille
CC BY-SA 3.0
2017-12-04T18:40:30.890Z
Yes I did: 4000 dbcache with 8gb ram - no difference, but moving the chainstate dir. to my ssd and symlinking it back - the speed went from 0,5% to 6% and then to 10%. So if anyone else has the same problem it's definitely worth trying.
Jure1873
CC BY-SA 3.0
2017-12-04T18:42:20.173Z
@Jure1873 Do you have pruning enabled? There is currently a bug that makes pruning effectively reduce the dbcache effectiveness.
Pieter Wuille
CC BY-SA 3.0
2017-12-05T21:24:45.240Z
No, I didn't have pruning. Apparently disk was the bottleneck in my situation.
Jure1873
CC BY-SA 3.0
2016-11-11T19:06:08.663Z
2016-11-11T19:06:08.663Z
Pieter Wuille
<p>I'm trying to setup my own Bitcoin node on <code>Ubuntu 16.04.1 LTS</code>.</p>

<p>Right now, I've stuck with blockchain synchronization. I'm letting <code>bitcoind</code> to run every day for at least 10-12 hours while I work and it already takes three days to download 83% of the entire data.</p>

<p>I have very good Internet connection, it should take no more than two hours to download 80 GB of data, however, it's taking at least 30 hours already. My connection is practically free from other downloads most of the time.</p>

<p>I've googled this problem: some people say that current version of the <code>bitcoind</code> is so fast that it doesn't matter how blockchain is downloaded throught the Bitcoin network or by torrent. Other people say, that it takes a week to download the entire blockchain.</p>

<ol>
<li><p>Is there a way to optimize my setup to make it download blockchain much-much faster?</p></li>
<li><p>Or do I better download it via some torrent and then synchronize the differences from the network? What is the best place to find such torrent file or magnet link? Also, is it safe to download blockchain from some third-party, will bitcoind validate it?</p></li>
</ol>

<p>SO, generally speaking, what is the best way to download the blockchain in order to setup a working up-to-date Bitcoin node?</p>



<pre><code>$ cat /etc/issue
Ubuntu 16.04.1 LTS \n \l

$ uname -a
Linux destiny 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ bitcoind -version
Bitcoin Core Daemon version v0.13.1.0-g03422e5
</code></pre>

<blockchain><synchronization>
Blockchain synchronization is painfully slow / Best way to download blockchain
Slava Fomin II
# Blockchain synchronization is painfully slow / Best way to download blockchain

(Asked by: username_0 on 2016-11-11)

I'm trying to setup my own Bitcoin node on `Ubuntu 16.04.1 LTS`.

Right now, I've stuck with blockchain synchronization. I'm letting `bitcoind` to run every day for at least 10-12 hours while I work and it already takes three days to download 83% of the entire data.

I have very good Internet connection, it should take no more than two hours to download 80 GB of data, however, it's taking at least 30 hours already. My connection is practically free from other downloads most of the time.

I've googled this problem: some people say that current version of the `bitcoind` is so fast that it doesn't matter how blockchain is downloaded throught the Bitcoin network or by torrent. Other people say, that it takes a week to download the entire blockchain.

1. Is there a way to optimize my setup to make it download blockchain much-much faster?
2. Or do I better download it via some torrent and then synchronize the differences from the network? What is the best place to find such torrent file or magnet link? Also, is it safe to download blockchain from some third-party, will bitcoind validate it?

SO, generally speaking, what is the best way to download the blockchain in order to setup a working up-to-date Bitcoin node?

```
$ cat /etc/issue
Ubuntu 16.04.1 LTS \n \l

$ uname -a
Linux destiny 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ bitcoind -version
Bitcoin Core Daemon version v0.13.1.0-g03422e5

```

**Tags:** blockchain, synchronization


---

## 3 answers

### Answer by username_4 on 2016-11-11. Score: 13 | Accepted answer

What usually takes time is the validation of the transactions in the blockchain, not downloading it. Bitcoin Core implements a fully validating node, which does not trust any of the information other peers give it. The only way to accomplish that is by validating everything itself.

30 hours sounds painfully long though. If you have memory to spare on your system, you absolutely should increase the database cache size. The default in 0.13 is 300 MB, but you'll see very significant speedups from using a higher value, up to 4000 or so (which would require an extra 4GB of memory).

> **Comments:**
> **username_0**: Thanks username_4, that makes perfect sense. I will try to increase the cache size then and will see if it helps!  
> **username_0**: By the way, is it safe to download blockchain from some third-party, will bitcoind validate it?  
> **username_4**: You can download a bootstrap.dat file (which contains just blocks to process at startup, as if they were received from network). Do *not* download a full database copy, bitcoind does not and cannot know you copied from a potentially untrustworthy party.  
> **username_0**: Thanks! Please consider adding this info to the answer, so other users could also easily find it.  
> **username_5**: Ugh, its already been taking me *days* and it still says 3 days to go.  
> **username_6**: How do we increase the database cache size?  
> **username_4**: Using the `-dbcache` command line option, the `dbcache` config file option, or in the settings menu in Bitcoin-Qt.  
> **username_7**: If anyone else has a similar problem: what really made a difference for me was moving the chainstate directory to a ssd. Now it's about 10x faster.  
> **username_4**: @username_7 Did you try increasing the dbcache size? Disk speed should be almost irrelevant if you can give it a few GB of cache.  
> **username_7**: Yes I did: 4000 dbcache with 8gb ram - no difference, but moving the chainstate dir. to my ssd and symlinking it back - the speed went from 0,5% to 6% and then to 10%. So if anyone else has the same problem it's definitely worth trying.  
> **username_4**: @username_7 Do you have pruning enabled? There is currently a bug that makes pruning effectively reduce the dbcache effectiveness.  
> **username_7**: No, I didn't have pruning. Apparently disk was the bottleneck in my situation.  

---

### Answer by username_1 on 2020-10-29. Score: 0

I didn't have enough reputation to add a comment to the accepted answer. But here's what I have learned:  
I'm running Bitcoin Core Version v0.20.1 and Linux Mint 18.3 on pretty old hardware. Pruning blockchain to 2 GB and setting `dbcache` to 2048 MiB didn't actually help.

Moving the `datadir` to a USB-Stick did the job for me. Which is weird since my disk is connected too via USB. Maybe there is an issue with how bitcoin-qt is handling its cache? An in-memory cache shouldn't behave like that. At least I wouldn't expect it to.

**Note: Using a USB-Stick is not recommended!**
It can cause bitcoin-qt shutting down due to database errors.

So, if it's neither CPU nor bandwidth check your disk I/O.

On Linux you might want to try:

```
iostat -x 5

```

To figure out which device is what disk, you can use

```
cat /proc/mounts

```

> **Comments:**
> **username_2**: Hi username_1, in case you didn't see, this question was resolved four years ago. However, if you see the comments on username_4's answer, some users have found that disk I/O was indeed their bottleneck. It would be great if you could extend your answer a bit in that direction.  
> **username_1**: Hi username_2, thanks for pointing out. I was too noob to add a comment to the answer (lack of reputation). So I did my best to put here what I have learned.  I'm running Bitcoin Core Version v0.20.1 and Linux Mint 18.3 on a pretty old hardware. Pruning blockchain to 2 G and setting dbcache to 2048 MiB didn't actually help. Moving datadir to a USB-Stick did the job for me. Which is weird since my disk is connected too via USB. Maybe there is an issue with how bitcoin-qt is handling its cache? An in-memory cache shouldn't behave like that. At least I wouldn't expect it to.  
> **username_2**: Hi username_1, thanks for the explanation! I wasn't sure whether you had meant to comment. I've copied your explanation into the answer. Maybe you could take another look and edit it further to round it out!  
> **username_1**: Hi username_2, thanks for your kind help converting my input in a readable output! :)  

---

### Answer by username_3 on 2018-12-24. Score: 0

downloading 150 Gigabyte will always be very slow. Some suggest to set "listen" to "off" but this has no effect on speed. You might, at intervals, ban the slowest 3 nodes, so you get pretty fast nodes after a while.

> **Comments:**
> **username_0**: The problem was not with network bandwidth, but with the fact that Bitcoin verifies all the blocks and it takes a lot of CPU resources. The 150 GB could be downloaded within 2 hours on my network, but it will take much more time to verify all those blocks. And the good CPU will really help in speeding up this process.  

---

