<p>Very little of the time is spent downloading the blockchain data compared to how much time your computer is spending verifying each transaction.  Bitcoin does a ton of disk i/o for this.</p>

<p>As there are more transactions since April (thanks to SatoshiDICE, we now see 40K and more transactions a day) those blocks take longer to verify.</p>

<p>If you are on an encrypted filesystem, that will really be hurtful for perfomance.  If so, consider moving the blockchain and index to a filesystem that isn't encrypted and then symlink to them there.</p>

<p>Also, the latest release of the Bitcoin.org client (v0.6.3) has peformance improvements in this area over previous releases.</p>

<p>End uses generally will not need to run the client and instead use <a href="https://en.bitcoin.it/wiki/Thin_Client_Security#Simplified_Payment_Verification_.28SPV.29" rel="nofollow noreferrer">SPV (Simplified Payment Verification)</a>.  So individuals and organizations that do want to run the full client should recognize that to do so requires a beefy CPU and quick storage (SSD maybe even).</p>

<p>A future version (after 0.7) will include LevelDB which should make huge gains as far as performance.</p>

<p>In the meantime, you can always <a href="https://bitcoin.stackexchange.com/questions/3551/how-can-one-download-the-initial-blockchain-data-files-securely">securely download</a> a full set of blockchain data <a href="http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/" rel="nofollow noreferrer">from   Sourceforge</a> that is as-of a fairly recent point in time.</p>

CC BY-SA 3.0
2012-08-17T10:33:18.053Z
Oh, "If there is any attack that works in this way, it's a defect in the client". Didn't know that. I didn't try this yet because I didn't know the security implications. Only 4900 blocks left now, but let's see which method is faster. It's going ridiculously slow now...
Luc
CC BY-SA 3.0
2012-10-24T23:26:48.913Z
Just to update, version 0.7.1 which has been released, will automatically load bootstrap.dat, which is a blockchain data file pulled as a bittorrent data file.  http://bitcointalk.org/index.php?topic=117982.0
Stephen Gornick
CC BY-SA 3.0
2012-10-24T23:28:45.800Z
And ultraprune is implemented (though still some bugs being resolved) and first reports are that it performs phenomenally well, particularly where disk i/o was hugely limiting.
Stephen Gornick
CC BY-SA 3.0
2012-08-17T03:16:05.620Z
2013-03-15T12:27:35.353Z
2017-04-13T12:47:36.647Z
Stephen Gornick
<p>Yes, it's normal for the rate of blocks being received to decrease as the download progresses.</p>

<p>The reason it slows down is because there were very few transactions in each block in the early days of Bitcoin, so the blocks were smaller. Later blocks are bigger. </p>

<p>The Satoshi Bitcoin Client is still a Beta version, and even if it wasn't it may still need to download the entire blockchain which I believe is over 2GB.</p>

<p>Which platform are you running the client on? You should be able estimate how much data is left to download by looking at the blockchain files on disk in the <a href="https://en.bitcoin.it/wiki/Data_directory">application folder</a>.</p>

<p>It appears that HDD speed may be a significant factor too, as verification of each block is performed as it's downloaded, and that can be complicated for a transaction with many inputs. <a href="https://bitcointalk.org/index.php?topic=74275.0">Discussion here</a>. <em>dooglus</em> provides evidence of that theory by testing with a RAM disk and heavily reducing the download time.</p>

CC BY-SA 3.0
2012-08-17T02:54:18.620Z
I'm running on Linux, already checked the ~/.bitcoin folder. The block chain is in blk0001.dat right? It's 1.2GB now, so some time to go... Still wondering why it doesn't max out my download speed, and why it doesn't go faster with more connections.
Luc
CC BY-SA 3.0
2012-08-17T02:46:53.750Z
2012-08-17T03:19:49.870Z
2012-08-17T03:19:49.870Z
Highly Irregular
<ol>
<li>Moving blkindex.dat to a let's say ram drive dramatically improves bitcoin/bitcoind performance. Just notice that currently index is around 1.5Gb size.</li>
<li>Next version 0.8, as already been said, is using a new database instead of BDB and this works much faster and don't need to be moved to a ram drive or something.</li>
</ol>

CC BY-SA 3.0
2013-01-13T23:20:34.377Z
How do I move blkindex.dat, and only blkindex.dat, to a ramdrive? Symlink/hardlink/whateverlink it there?
Luc
CC BY-SA 3.0
2013-01-15T03:04:46.050Z
If your OS is Linux you can use tmpfs and create a symlink back to bitcoin directory.
Stanislav German-Evtushenko
CC BY-SA 3.0
2013-01-13T18:55:17.187Z
2013-01-13T18:55:17.187Z
Stanislav German-Evtushenko
<p>I kinda figured out how to improve performance on ext4/linux:</p>

<p><a href="http://tlfabian.blogspot.hu/2013/04/speeding-up-bitcoin-qt-on-linux.html" rel="nofollow">http://tlfabian.blogspot.hu/2013/04/speeding-up-bitcoin-qt-on-linux.html</a></p>

CC BY-SA 3.0
2013-04-03T14:43:58.497Z
Although not a direct answer to the question, this is good to know. Thanks!
Luc
CC BY-SA 3.0
2013-04-03T05:22:36.857Z
2013-04-03T05:22:36.857Z
netom
<p>Bitcoin is P2P like BitTorrent. It is likely to be because your computer is slow validating the blockchain as it downloads. Most of the work is not actually the downloading. This <a href="https://bitcoin.stackexchange.com/a/69862/75001">answer</a> may help you.</p>

CC BY-SA 3.0
2018-02-02T09:13:03.020Z
2018-02-02T09:13:03.020Z
Willtech
<p>Okay, combining answers and what more I've observed:</p>

<ul>
<li>The rate of blocks slows down because more recent blocks are larger. The number of blocks remaining is not actually a good measure for estimated time.</li>
<li>You can make an estimate based on how much data is downloaded (in how much time) and how much data is left: At the moment of writing, my blk000x.dat files are totaling 8.3GB (10 Feb 2013).</li>
<li>I can't say anything about how fast the data size will increase, perhaps someone can comment on this for future readers.<br>
<strong>Update:</strong> It seems to be growing rather fast, probably linearly with <a href="http://blockchain.info/charts/n-transactions?timespan=all&amp;showDataPoints=false&amp;daysAverageString=1&amp;show_header=true&amp;scale=0&amp;address=">the number of transactions per block</a></li>
<li>The reason it doesn't max out your download speed, is because it's actually doing a lot of other things to verify the transactions.</li>
<li>Downloading a zip with nightly blk000x.dat files is a lot faster, but copying the files didn't work... In the end I just left it running a few more hours. Also see the comment about a bug this might introduce when an error is present in the files (intentionally or not).</li>
<li>Encrypted filesystems make it take even longer because verifying blocks is an disk-intensive process.</li>
<li><strong>If you can, use an SSD</strong>, this speeds it up by a lot. You could be done in a few hours instead of taking all night.</li>
<li>Usually this process just takes a while. 24 hours is not uncommon. Best is to leave your computer running during the night, and don't be disappointed when it's still not done in the morning.</li>
</ul>

<p>Hope this helped! Credits to the other answers for some of the bullet points.</p>

CC BY-SA 3.0
2012-08-18T21:15:34.370Z
If you download blk___.dat files, and put them in your Bitcoin folder, they are NOT verified. The client will not know that it didn't download+verify them itself. Doing this is a bad idea: if a small error is present (intentionally or not) in one of those files downloadable from a popular location. there is a risk that all those clients together will disagree about the validness of a particular chain, resulting in a large and permanent fork. There will soon be options for importing instead of replacing your block chain database, which will be safe.
Pieter Wuille
CC BY-SA 3.0
2012-08-18T21:16:48.953Z
Most of the memory requirement comes from network send/receive buffers. Especially when many clients try to download the blockchain from you, memory usage will increase. If you limit the number of connections (-maxconnections=16) for example, memory usage will be more modest.
Pieter Wuille
CC BY-SA 3.0
2012-08-19T22:53:11.093Z
@PieterWuille Updated accordingly. Thanks for the comments :)
Luc
CC BY-SA 3.0
2012-08-18T18:30:44.687Z
2013-02-16T22:04:26.853Z
2013-02-16T22:04:26.853Z
Luc
<p>First off, this really needs to get fixed. I'm downloading blocks for at least 8 hours now, and it's still not done. I know the problem of having to download the entire block chain is being worked on, but I feel it's already out of hand. Setting up an application should take something you would measure in minutes, not hours or days. (After spending the entire night, it's now 4:15am, I would estimate the setup time to be two <em>days</em>.)</p>

<p>Also downloading can be much optimized as it is. It's far from using my maximum download speed, and being connected to one peer is as fast as being connected to 8+ (yup, also tried port forwarding).</p>

<p><strong>Now, ontopic.</strong></p>

<p>Is it normal that downloading blocks goes slower, the further you progress? The first half (out of 194.000) went in the blink of an eye, after that it became less and less fast. Now at 20.000 blocks remaining, progress comes in bursts, but there can easily be 20 seconds of inactivity and when it bursts it's like 10 blocks.</p>

<p>Is this normal behavior? And also, why doesn't the number of connections make any difference for the speed at all? If it works like Bittorrent, which some describe it to work like, it should get faster with more people who can upload to you (more connections).</p>

<p>I've Googled, but all I've found is that it takes a few hours and that it may get stuck. It's not stuck and taking as long as people describe it to be, but I just wonder if it's normal that it's going slower and slower, and why it doesn't saturate my download capacity (like BitTorrent) no matter how many connections.</p>

<p>Thanks</p>

CC BY-SA 3.0
2012-08-17T03:04:57.650Z
Are you running on an encrypted filesystem?
Stephen Gornick
CC BY-SA 3.0
2012-08-17T03:06:02.623Z
@StephenGornick Nope (already read that in another question posted here, but that's not it).
Luc
CC BY-SA 3.0
2012-08-17T03:09:25.223Z
Related question which provides an alternative way of downloading the blockchain: http://bitcoin.stackexchange.com/questions/799/can-i-download-the-whole-block-chain-from-somewhere
Highly Irregular
<installation><synchronization>
Why is downloading blocks taking longer and longer?
Luc
# Why is downloading blocks taking longer and longer?

(Asked by: username_0 on 2012-08-17)

First off, this really needs to get fixed. I'm downloading blocks for at least 8 hours now, and it's still not done. I know the problem of having to download the entire block chain is being worked on, but I feel it's already out of hand. Setting up an application should take something you would measure in minutes, not hours or days. (After spending the entire night, it's now 4:15am, I would estimate the setup time to be two *days*.)

Also downloading can be much optimized as it is. It's far from using my maximum download speed, and being connected to one peer is as fast as being connected to 8+ (yup, also tried port forwarding).

**Now, ontopic.**

Is it normal that downloading blocks goes slower, the further you progress? The first half (out of 194.000) went in the blink of an eye, after that it became less and less fast. Now at 20.000 blocks remaining, progress comes in bursts, but there can easily be 20 seconds of inactivity and when it bursts it's like 10 blocks.

Is this normal behavior? And also, why doesn't the number of connections make any difference for the speed at all? If it works like Bittorrent, which some describe it to work like, it should get faster with more people who can upload to you (more connections).

I've Googled, but all I've found is that it takes a few hours and that it may get stuck. It's not stuck and taking as long as people describe it to be, but I just wonder if it's normal that it's going slower and slower, and why it doesn't saturate my download capacity (like BitTorrent) no matter how many connections.

Thanks

**Tags:** installation, synchronization

> **Comments:**
> **username_1**: Are you running on an encrypted filesystem?  
> **username_0**: @username_1 Nope (already read that in another question posted here, but that's not it).  
> **username_2**: Related question which provides an alternative way of downloading the blockchain: http://bitcoin.stackexchange.com/questions/799/can-i-download-the-whole-block-chain-from-somewhere  

---

## 6 answers

### Answer by username_0 on 2012-08-18. Score: 18 | Accepted answer

Okay, combining answers and what more I've observed:

* The rate of blocks slows down because more recent blocks are larger. The number of blocks remaining is not actually a good measure for estimated time.
* You can make an estimate based on how much data is downloaded (in how much time) and how much data is left: At the moment of writing, my blk000x.dat files are totaling 8.3GB (10 Feb 2013).
* I can't say anything about how fast the data size will increase, perhaps someone can comment on this for future readers.  
  **Update:** It seems to be growing rather fast, probably linearly with [the number of transactions per block](http://blockchain.info/charts/n-transactions?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=)
* The reason it doesn't max out your download speed, is because it's actually doing a lot of other things to verify the transactions.
* Downloading a zip with nightly blk000x.dat files is a lot faster, but copying the files didn't work... In the end I just left it running a few more hours. Also see the comment about a bug this might introduce when an error is present in the files (intentionally or not).
* Encrypted filesystems make it take even longer because verifying blocks is an disk-intensive process.
* **If you can, use an SSD**, this speeds it up by a lot. You could be done in a few hours instead of taking all night.
* Usually this process just takes a while. 24 hours is not uncommon. Best is to leave your computer running during the night, and don't be disappointed when it's still not done in the morning.

Hope this helped! Credits to the other answers for some of the bullet points.

> **Comments:**
> **username_6**: If you download blk___.dat files, and put them in your Bitcoin folder, they are NOT verified. The client will not know that it didn't download+verify them itself. Doing this is a bad idea: if a small error is present (intentionally or not) in one of those files downloadable from a popular location. there is a risk that all those clients together will disagree about the validness of a particular chain, resulting in a large and permanent fork. There will soon be options for importing instead of replacing your block chain database, which will be safe.  
> **username_6**: Most of the memory requirement comes from network send/receive buffers. Especially when many clients try to download the blockchain from you, memory usage will increase. If you limit the number of connections (-maxconnections=16) for example, memory usage will be more modest.  
> **username_0**: @username_6 Updated accordingly. Thanks for the comments :)  

---

### Answer by username_1 on 2012-08-17. Score: 23

Very little of the time is spent downloading the blockchain data compared to how much time your computer is spending verifying each transaction. Bitcoin does a ton of disk i/o for this.

As there are more transactions since April (thanks to SatoshiDICE, we now see 40K and more transactions a day) those blocks take longer to verify.

If you are on an encrypted filesystem, that will really be hurtful for perfomance. If so, consider moving the blockchain and index to a filesystem that isn't encrypted and then symlink to them there.

Also, the latest release of the Bitcoin.org client (v0.6.3) has peformance improvements in this area over previous releases.

End uses generally will not need to run the client and instead use [SPV (Simplified Payment Verification)](https://en.bitcoin.it/wiki/Thin_Client_Security#Simplified_Payment_Verification_.28SPV.29). So individuals and organizations that do want to run the full client should recognize that to do so requires a beefy CPU and quick storage (SSD maybe even).

A future version (after 0.7) will include LevelDB which should make huge gains as far as performance.

In the meantime, you can always [securely download](https://bitcoin.stackexchange.com/questions/3551/how-can-one-download-the-initial-blockchain-data-files-securely) a full set of blockchain data [from Sourceforge](http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/) that is as-of a fairly recent point in time.

> **Comments:**
> **username_0**: Oh, "If there is any attack that works in this way, it's a defect in the client". Didn't know that. I didn't try this yet because I didn't know the security implications. Only 4900 blocks left now, but let's see which method is faster. It's going ridiculously slow now...  
> **username_1**: Just to update, version 0.7.1 which has been released, will automatically load bootstrap.dat, which is a blockchain data file pulled as a bittorrent data file.  http://bitcointalk.org/index.php?topic=117982.0  
> **username_1**: And ultraprune is implemented (though still some bugs being resolved) and first reports are that it performs phenomenally well, particularly where disk i/o was hugely limiting.  

---

### Answer by username_2 on 2012-08-17. Score: 6

Yes, it's normal for the rate of blocks being received to decrease as the download progresses.

The reason it slows down is because there were very few transactions in each block in the early days of Bitcoin, so the blocks were smaller. Later blocks are bigger.

The Satoshi Bitcoin Client is still a Beta version, and even if it wasn't it may still need to download the entire blockchain which I believe is over 2GB.

Which platform are you running the client on? You should be able estimate how much data is left to download by looking at the blockchain files on disk in the [application folder](https://en.bitcoin.it/wiki/Data_directory).

It appears that HDD speed may be a significant factor too, as verification of each block is performed as it's downloaded, and that can be complicated for a transaction with many inputs. [Discussion here](https://bitcointalk.org/index.php?topic=74275.0). *dooglus* provides evidence of that theory by testing with a RAM disk and heavily reducing the download time.

> **Comments:**
> **username_0**: I'm running on Linux, already checked the ~/.bitcoin folder. The block chain is in blk0001.dat right? It's 1.2GB now, so some time to go... Still wondering why it doesn't max out my download speed, and why it doesn't go faster with more connections.  

---

### Answer by username_3 on 2013-01-13. Score: 5

1. Moving blkindex.dat to a let's say ram drive dramatically improves bitcoin/bitcoind performance. Just notice that currently index is around 1.5Gb size.
2. Next version 0.8, as already been said, is using a new database instead of BDB and this works much faster and don't need to be moved to a ram drive or something.

> **Comments:**
> **username_0**: How do I move blkindex.dat, and only blkindex.dat, to a ramdrive? Symlink/hardlink/whateverlink it there?  
> **username_3**: If your OS is Linux you can use tmpfs and create a symlink back to bitcoin directory.  

---

### Answer by username_4 on 2013-04-03. Score: 4

I kinda figured out how to improve performance on ext4/linux:

<http://tlfabian.blogspot.hu/2013/04/speeding-up-bitcoin-qt-on-linux.html>

> **Comments:**
> **username_0**: Although not a direct answer to the question, this is good to know. Thanks!  

---

### Answer by username_5 on 2018-02-02. Score: 0

Bitcoin is P2P like BitTorrent. It is likely to be because your computer is slow validating the blockchain as it downloads. Most of the work is not actually the downloading. This [answer](https://bitcoin.stackexchange.com/a/69862/75001) may help you.


---

