<p>I had the same problem on a very old machine (with 4 GB RAM and an Intel Core 2 Duo E8400 CPU) running Debian GNU/Linux. I read the very helpful answer of @Willtech and derived the following command:</p>

<pre><code>./bitcoin-qt -banscore=10 -dbcache=1024 -listen=0
</code></pre>

<p>This resulted in a sync time of roughly 2 weeks on that PC. Very long indeed but much better than having to buy new hardware...</p>

CC BY-SA 4.0
2019-12-16T12:51:13.057Z
2019-12-16T12:51:13.057Z
Hagbard
<p>Sorry to necro this post, but these problems persist to this day, even on Satoshi:v0.20.x.</p>
<p>Here's a quick fix to alleviate your issues. Manually specify peer IPs to console. If you're using Bitcoin-qt, use ctrl+t to open the console, and type in:</p>
<pre><code>addnode &lt;node IP&gt;:&lt;node port, almost always 8333&gt; onetry
</code></pre>
<p>for each IP you want.</p>
<p>You can get node IPs from a public node directory, such as <a href="https://bitnodes.io/nodes/" rel="nofollow noreferrer">Bitnodes</a>. Pick a bunch of random nodes, and make sure they're not all in the same geographic location and/or from some VPS provider (i.e. Amazon, Google, etc.), and try to diversify them. It should increase your speed a bit since those nodes will assist you with peer discovery.</p>

CC BY-SA 4.0
2020-08-23T17:46:38.607Z
2020-08-23T17:46:38.607Z
Expectator
<p>I guess your computer is too slow.</p>

<p>Use the latest release (0.15.1 for example) and don't change cache values unless your RAM is less than 8 GB (800 MB is less than the default setting so by setting that you actually made it worse).</p>

CC BY-SA 3.0
2018-01-30T10:46:24.193Z
Looking at Bitcoin Core v0.15.1 it says that the default for `dbcache` is 450MB
Willtech
CC BY-SA 3.0
2017-11-30T05:17:54.310Z
2017-11-30T05:17:54.310Z
whatever
<p>For some reason some nodes does not give you any blocks when you are connected to them. To see if this is happening to you, open <em>Peers</em> (Window > Peers) and check to see how much is received for each node. If a node does not give you any data just ban it by right clicking and selecting "Ban for 1 hour" do this until you are connected to a node that actually sends you blocks.</p>

<p><strong>bitcoind</strong> connects to 10 nodes as standard but if you are unlucky you will be connected to 10 nodes that does not give you any blocks. Normally just waiting will eventually resolve this issue but banning nodes until you get connected to some fast ones is a much faster way.</p>

CC BY-SA 4.0
2020-05-19T03:51:13.970Z
2020-05-19T03:51:13.970Z
JKAbrams
<h1>Bitcoin Core sync very slow</h1>

<p>Bitcoin Core is capable of full sync in a relatively short period of time depending mainly on the hardware.</p>

<p>Most of the work done is not actually downloading the blocks, it is validating them and every transaction that they contain. It not only depends on downloading the blocks but also on the quantity and complexity of every transaction. The downloading of the blocks themselves is usually not an issue if you are connected (outbound) to several nodes. I am able to download blocks generally in forty-five seconds each (which includes the request time etc. and validation as well as the transfer) when I have been offline and am catching up on my restricted local 256Kbps link. My upload speed is low, and latency is high. At the rate of one block per forty-five seconds, it would currently take over two-hundred-and-sixty-three days to complete the whole blockchain as there are more than 506822 blocks as of writing.</p>

<p>From my personal experience, the initial sync actually took over five days to complete on a 2.5GHz Core i5 notebook with 4GB of RAM running Fedora with Bitcoin Core v0.15.1. For that, I used ADSL2+ and never perceived the actual downloading of the blocks to be the issue.</p>

<h2>Performance of initial sync</h2>

<p>Performance of initial sync largely comes down to the individual performance of your computer, provided your internet is fine.</p>

<p>Always use the latest release version of Bitcoin Core (includes bitcoin-qt and bitcoind) downloaded from the official site at <a href="https://bitcoin.org/en/wallets/desktop/windows/bitcoincore/" rel="noreferrer">www.bitcoin.org</a>. An upgrade is safe and easy, just safely exit Bitcoin Core first and make a new secure backup of your <code>wallet.dat</code> before you upgrade.</p>

<h2>Adjusting parameters</h2>

<p>There are some parameters that you can <em>look at</em> and consider depending on your system. Always make a backup of your wallet before making any changes. The parameters can be entered at the command line or generally in your <code>bitcoin.conf</code> file, which you would need to exit and restart Bitcoin Core in that case to see the effect. Some things to consider that <em>could</em> make a difference:</p>

<p><em>I am presuming here that you are running bitcoin-qt which is the GUI version and not bitcoind.</em></p>

<p><em>If parameters are used in the <code>bitcoin.conf</code> file, omit the leading <kbd>-</kbd>.</em></p>

<ul>
<li><code>-datadir=</code> You could have your datadir on a fast drive. If you move your whole .bitcoin folder you will need to specify this parameter on the command line. Note that if you change your datadir and do not copy the .bitcoin folder over to the new location first, it will create a new wallet and begin downloading the blockchain again from the start.</li>
<li><code>-dbcache=</code> The default for this is 450. If you have 8GB of RAM, you could easily set this to 4096</li>
<li><code>par=</code> The default for this setting is auto, but I do not know what the automatic setting does. You could try setting this to -1 which leaves one core free.</li>
<li><code>-banscore=</code> You could try setting this to 10 to kick off misbehaving nodes sooner.</li>
<li><code>-listen=</code> You could temporarily set this to 0 to disable incoming connections while you get the initial sync done. Your busy node does not need the additional work.</li>
</ul>

<p>After the initial sync, you can revert these settings to their defaults but probably leave your datadir wherever you put it.</p>

<p>Some of these parameters are available as options in the bitcoin-qt Settings > Options menu.</p>

<p><strong>TLDR;</strong> The short answer if you want it fast is, get a fast computer, loads of RAM, a fast HDD and, fast internet. The same as anytime you want anything fast on a computer.</p>

<p>In the real world, and from personal experience, using an SSD increased sync speed more than 10x on my example system from the performance noted above.</p>

<h2>Anecdotes</h2>

<p>Real life example of varying system performance: I know someone personally who had to work on a quite large, but not extraordinarily large, Illustrator file. He opened it on his ~12-month-old upper spec Mac which usually performs great and, it was virtually unusable (slow to respond). Just for kicks he thought he would try the same file on a bog standard PC, opened it in Illustrator and it was completely normal. Some hardware/software builds have bottlenecks for some processes. The opposite result is probably true for some operations.</p>

<p>Also note, I have observed that exiting and restarting Bitcoin Core during initial sync seems to speed it up a bit for a while once it connects to nodes again.</p>

<p>Referencing again personal experience, syncing on Windows 10 64-bit seems to be orders of magnitude faster than syncing on Linux on the same hardware - even if Windows is running in Gnome-Boxes, it easily churns through 100 blocks per second during the initial stages of download.</p>

<h2>Alternatives</h2>

<p>If you are in serious trouble waiting to sync Bitcoin Core (a full node client) and you do not need the additional features that Bitcoin Core provides then, you may consider trying <a href="https://bitcoin.org/en/wallets/desktop/windows/electrum/" rel="noreferrer">Electrum</a> (not a full node client) which does not need to do the initial sync. On Fedora 27, getting Electrum is as simple as <code>sudo dnf install electrum</code>.</p>

CC BY-SA 3.0
2018-01-30T12:20:46.790Z
2018-04-17T13:13:36.150Z
2018-04-17T13:13:36.150Z
Willtech
<p>I have the issue that my node's synchronisation is very slow. I am 14 weeks behind and it estimates to take 12 weeks to get synced. The synchronisation rate per hour is only 0,01%.
I have a fast broadband connection and no other issues with this PC. It should be able to download the whole blockchain in a few hours. However, the average transfer rate is about 0,5 KB/s.
Any idea what the issue might be?
I am running v0.14.2 and the number of outgoing connections is 3.
I have already changed cache memory to 800 MB but that didn't change anything.</p>

CC BY-SA 3.0
2017-08-31T18:48:03.263Z
How many incoming connections do you see?  Are you on Windows, Linux, or macOS?  For what it's worth, I have the same problem.  I'm on 0.4.2 on Windows 10 on a 100 Mbit/sec network connection.  The first approx 25% of the blockchain synced quickly, but things got very slow after that.  I receive a new block about every 20 seconds.  Approx 2 incoming, 4 outgoing connections.
royco
CC BY-SA 3.0
2017-09-01T18:56:58.200Z
I use it on Windows 8.1. I have 8 outgoing connections now (i needed to delete one blockchain file because a seperate issue after i have asked this question). Currently it takes 3 years to download everything which is nonsense.
michL
CC BY-SA 3.0
2018-01-30T10:40:37.610Z
It is probably not the actual downloading of blocks that is making it slow. From personal experience on a 2.5GHz Core i5 notebook running Bitcoin Core v0.15.1, it took more than five days to do the initial sync. Most of the slow seemed to be validating blocks. It was certainly nowhere near as slow initially, so I suspect a BIP has activated somewhere along the blockchain that causes validation to execute slowly after that. I did notice it seemed faster for a while if I safely exited and let Bitcoin Core shut down nicely before starting it up again.
Willtech
CC BY-SA 3.0
2018-01-31T13:12:56.283Z
Hi Willtech, thank you. It turned out that Bitcoin Core does not work very well with network drive. I have mapped the data since with iscsi and this worked fine. Still all the syncing is slow in general by design which is bad, but there seems to be nothing to get around it.
michL
CC BY-SA 3.0
2018-02-02T09:06:48.553Z
@michL Thanks. That would do it. If my answer below has helped you I would appreciate it if you would mark it as accepted so that the question does not remain "unanswered".
Willtech
CC BY-SA 4.0
2020-08-20T22:09:28.843Z
My Windows 10 firewall was blocking it
Leo
<bitcoin-core><synchronization><peer-discovery>
Sync with bitcoin-qt very slow (0,01%)
michL
# Sync with bitcoin-qt very slow (0,01%)

(Asked by: username_0 on 2017-08-20)

I have the issue that my node's synchronisation is very slow. I am 14 weeks behind and it estimates to take 12 weeks to get synced. The synchronisation rate per hour is only 0,01%.
I have a fast broadband connection and no other issues with this PC. It should be able to download the whole blockchain in a few hours. However, the average transfer rate is about 0,5 KB/s.
Any idea what the issue might be?
I am running v0.14.2 and the number of outgoing connections is 3.
I have already changed cache memory to 800 MB but that didn't change anything.

**Tags:** bitcoin-core, synchronization, peer-discovery

> **Comments:**
> **username_1**: How many incoming connections do you see?  Are you on Windows, Linux, or macOS?  For what it's worth, I have the same problem.  I'm on 0.4.2 on Windows 10 on a 100 Mbit/sec network connection.  The first approx 25% of the blockchain synced quickly, but things got very slow after that.  I receive a new block about every 20 seconds.  Approx 2 incoming, 4 outgoing connections.  
> **username_0**: I use it on Windows 8.1. I have 8 outgoing connections now (i needed to delete one blockchain file because a seperate issue after i have asked this question). Currently it takes 3 years to download everything which is nonsense.  
> **username_2**: It is probably not the actual downloading of blocks that is making it slow. From personal experience on a 2.5GHz Core i5 notebook running Bitcoin Core v0.15.1, it took more than five days to do the initial sync. Most of the slow seemed to be validating blocks. It was certainly nowhere near as slow initially, so I suspect a BIP has activated somewhere along the blockchain that causes validation to execute slowly after that. I did notice it seemed faster for a while if I safely exited and let Bitcoin Core shut down nicely before starting it up again.  
> **username_0**: Hi username_2, thank you. It turned out that Bitcoin Core does not work very well with network drive. I have mapped the data since with iscsi and this worked fine. Still all the syncing is slow in general by design which is bad, but there seems to be nothing to get around it.  
> **username_2**: @username_0 Thanks. That would do it. If my answer below has helped you I would appreciate it if you would mark it as accepted so that the question does not remain "unanswered".  
> **username_3**: My Windows 10 firewall was blocking it  

---

## 5 answers

### Answer by username_2 on 2018-01-30. Score: 12 | Accepted answer

# Bitcoin Core sync very slow

Bitcoin Core is capable of full sync in a relatively short period of time depending mainly on the hardware.

Most of the work done is not actually downloading the blocks, it is validating them and every transaction that they contain. It not only depends on downloading the blocks but also on the quantity and complexity of every transaction. The downloading of the blocks themselves is usually not an issue if you are connected (outbound) to several nodes. I am able to download blocks generally in forty-five seconds each (which includes the request time etc. and validation as well as the transfer) when I have been offline and am catching up on my restricted local 256Kbps link. My upload speed is low, and latency is high. At the rate of one block per forty-five seconds, it would currently take over two-hundred-and-sixty-three days to complete the whole blockchain as there are more than 506822 blocks as of writing.

From my personal experience, the initial sync actually took over five days to complete on a 2.5GHz Core i5 notebook with 4GB of RAM running Fedora with Bitcoin Core v0.15.1. For that, I used ADSL2+ and never perceived the actual downloading of the blocks to be the issue.

## Performance of initial sync

Performance of initial sync largely comes down to the individual performance of your computer, provided your internet is fine.

Always use the latest release version of Bitcoin Core (includes bitcoin-qt and bitcoind) downloaded from the official site at [www.bitcoin.org](https://bitcoin.org/en/wallets/desktop/windows/bitcoincore/). An upgrade is safe and easy, just safely exit Bitcoin Core first and make a new secure backup of your `wallet.dat` before you upgrade.

## Adjusting parameters

There are some parameters that you can *look at* and consider depending on your system. Always make a backup of your wallet before making any changes. The parameters can be entered at the command line or generally in your `bitcoin.conf` file, which you would need to exit and restart Bitcoin Core in that case to see the effect. Some things to consider that *could* make a difference:

*I am presuming here that you are running bitcoin-qt which is the GUI version and not bitcoind.*

*If parameters are used in the `bitcoin.conf` file, omit the leading `-`.*

* `-datadir=` You could have your datadir on a fast drive. If you move your whole .bitcoin folder you will need to specify this parameter on the command line. Note that if you change your datadir and do not copy the .bitcoin folder over to the new location first, it will create a new wallet and begin downloading the blockchain again from the start.
* `-dbcache=` The default for this is 450. If you have 8GB of RAM, you could easily set this to 4096
* `par=` The default for this setting is auto, but I do not know what the automatic setting does. You could try setting this to -1 which leaves one core free.
* `-banscore=` You could try setting this to 10 to kick off misbehaving nodes sooner.
* `-listen=` You could temporarily set this to 0 to disable incoming connections while you get the initial sync done. Your busy node does not need the additional work.

After the initial sync, you can revert these settings to their defaults but probably leave your datadir wherever you put it.

Some of these parameters are available as options in the bitcoin-qt Settings > Options menu.

**TLDR;** The short answer if you want it fast is, get a fast computer, loads of RAM, a fast HDD and, fast internet. The same as anytime you want anything fast on a computer.

In the real world, and from personal experience, using an SSD increased sync speed more than 10x on my example system from the performance noted above.

## Anecdotes

Real life example of varying system performance: I know someone personally who had to work on a quite large, but not extraordinarily large, Illustrator file. He opened it on his ~12-month-old upper spec Mac which usually performs great and, it was virtually unusable (slow to respond). Just for kicks he thought he would try the same file on a bog standard PC, opened it in Illustrator and it was completely normal. Some hardware/software builds have bottlenecks for some processes. The opposite result is probably true for some operations.

Also note, I have observed that exiting and restarting Bitcoin Core during initial sync seems to speed it up a bit for a while once it connects to nodes again.

Referencing again personal experience, syncing on Windows 10 64-bit seems to be orders of magnitude faster than syncing on Linux on the same hardware - even if Windows is running in Gnome-Boxes, it easily churns through 100 blocks per second during the initial stages of download.

## Alternatives

If you are in serious trouble waiting to sync Bitcoin Core (a full node client) and you do not need the additional features that Bitcoin Core provides then, you may consider trying [Electrum](https://bitcoin.org/en/wallets/desktop/windows/electrum/) (not a full node client) which does not need to do the initial sync. On Fedora 27, getting Electrum is as simple as `sudo dnf install electrum`.


---

### Answer by username_4 on 2019-12-16. Score: 2

I had the same problem on a very old machine (with 4 GB RAM and an Intel Core 2 Duo E8400 CPU) running Debian GNU/Linux. I read the very helpful answer of @username_2 and derived the following command:
./bitcoin-qt -banscore=10 -dbcache=1024 -listen=0

This resulted in a sync time of roughly 2 weeks on that PC. Very long indeed but much better than having to buy new hardware...


---

### Answer by username_5 on 2020-08-23. Score: 1

Sorry to necro this post, but these problems persist to this day, even on Satoshi:v0.20.x.
Here's a quick fix to alleviate your issues. Manually specify peer IPs to console. If you're using Bitcoin-qt, use ctrl+t to open the console, and type in:
addnode : onetry

for each IP you want.
You can get node IPs from a public node directory, such as Bitnodes. Pick a bunch of random nodes, and make sure they're not all in the same geographic location and/or from some VPS provider (i.e. Amazon, Google, etc.), and try to diversify them. It should increase your speed a bit since those nodes will assist you with peer discovery.


---

### Answer by username_6 on 2017-11-30. Score: 0

I guess your computer is too slow.

Use the latest release (0.15.1 for example) and don't change cache values unless your RAM is less than 8 GB (800 MB is less than the default setting so by setting that you actually made it worse).

> **Comments:**
> **username_2**: Looking at Bitcoin Core v0.15.1 it says that the default for `dbcache` is 450MB  

---

### Answer by username_7 on 2020-05-19. Score: 0

For some reason some nodes does not give you any blocks when you are connected to them. To see if this is happening to you, open *Peers* (Window > Peers) and check to see how much is received for each node. If a node does not give you any data just ban it by right clicking and selecting "Ban for 1 hour" do this until you are connected to a node that actually sends you blocks.

**bitcoind** connects to 10 nodes as standard but if you are unlucky you will be connected to 10 nodes that does not give you any blocks. Normally just waiting will eventually resolve this issue but banning nodes until you get connected to some fast ones is a much faster way.


---

