<p>My "Intel(R) Core(TM)2 Duo CPU     T6600  @ 2.20GHz" laptop just took 80 seconds to create 1000 new addresses, so I'm surprised you're seeing over 2 hours for 10 times that.</p>

<p>One thing I noticed is that the address creation is noticeable faster now than I remember it - so perhaps upgrading to a recent version of the client will speed things up for you.</p>

<p>Run "tail -f ~/.bitcoin/debug.log" to see a log of which key number it's currently creating.</p>

<p>Either way, the start up should only be noticeably slower the first time, when the pool is initially created.</p>

<p>Edit: (in response to miernik's comment)</p>

<p>The debug.log output will end with lines like the following while it's populating the keypool:</p>

<pre><code>keypool added key 41, size=41
keypool added key 42, size=42
keypool added key 43, size=43
keypool added key 44, size=44
keypool added key 45, size=45
keypool added key 46, size=46
keypool added key 47, size=47
keypool added key 48, size=48
keypool added key 49, size=49
keypool added key 50, size=50
</code></pre>

<p>The stuff you're seeing is what happens while bitcoin is running normally.  It's receiving and responding to messages on the P2P network.  I don't know what to suggest as to why it isn't accepting RPC connections.  Could it be a firewall issue, or some other configuration problem unrelated to the keypool argument?</p>

CC BY-SA 3.0
2012-05-15T04:21:31.207Z
I've put the last 200 lines from debug.log here: http://dpaste.com/748342/plain/ Can you tell me which is the key number? How does such a line look like, so I can grep for it? BTW: its 18 hours already and still running.
ria
CC BY-SA 3.0
2012-05-14T19:53:45.003Z
2012-05-15T10:50:40.627Z
2012-05-15T10:50:40.627Z
Chris Moore
<p>In the end it had nothing to do with <code>keypool=10000</code>. For some unknown reason my local interface was down. I fixed it with:</p>

<pre><code>ifconfig lo up
</code></pre>

<p>I killed the bitcoin daemon with <code>kill $PID</code>, started it again and within a minute I could do <code>bitcoind getbalance</code>.</p>

CC BY-SA 3.0
2012-05-15T05:09:24.970Z
2012-05-15T05:09:24.970Z
ria
<p>For others that might be encountering a similar problem, here are some other issues that I ran into:</p>

<p>1) IP ports not being opened:</p>

<pre><code>/sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
</code></pre>

<p>2) Make sure that your cloud instance security settings allow for TCP connections on the appropriate ports.</p>

<p>3) If you have ssl enabled in the server, make sure that you created an ssl certificate:</p>

<p><a href="https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon" rel="nofollow">https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon</a></p>

<p>4) Make sure to kill processes as others have described:</p>

<pre><code>ps -A | grep bitcoind
kill [PID]
</code></pre>

CC BY-SA 3.0
2013-02-27T04:51:16.957Z
2013-02-27T04:51:16.957Z
ZenBalance
<p>The initial question asked was as follows, but it turned out to be nothing to do with keypools:</p>

<blockquote>
  <p>I had keypool=1000 before. Now I started bitcoind (the daemon version)
  with keypool=10000 option, and it is 2 hours already and bitcoind
  didn't start up yet. I.e. I still get <code>error: couldn't connect to
  server</code> when I try to do <code>bitcoind getbalance</code>.</p>
  
  <p>Its a quite fast machine AMD 64bit 4000+ CPU with 10 GB RAM, how long
  the start-up time can be? And will it be so long every time I start
  the daemon, or only the first time?</p>
  
  <p>Will future start-up times increase in any noticeable way if I keep
  keypool=10000 in comparison with 1000? Or any other performance
  degradation, except this first startup?</p>
</blockquote>

<p><strong>Edit</strong>: In the end it had nothing to do with <code>keypool=10000</code>. For some unknown reason my local interface was down. I fixed it with:</p>

<pre><code>ifconfig lo up
</code></pre>

<p>I killed the bitcoin daemon with <code>kill $PID</code>, started it again and within a minute I could do <code>bitcoind getbalance</code>.</p>

CC BY-SA 3.0
2012-05-14T15:07:12.737Z
I don't know the answer. But I guess the slower startup is only the first time; after 10000 keys are generated, starting up should be quick.
Meni Rosenfeld
CC BY-SA 3.0
2012-05-14T16:57:33.063Z
I would believe it would slow Bitcoin down a bit when each block is validated, as the program will probably have to check each transaction for whether or not it matches every key in the wallet. I don't know how much slower it would go though...
ThePiachu
CC BY-SA 3.0
2012-05-14T18:44:12.593Z
@ThePiachu: If there is a hashset of all addresses, scanning the block for relevant transactions should take the same time no matter how many there are. Unless the addresses in the block itself are indexed.
Meni Rosenfeld
<bitcoind><backup><keypool>
Why can't I connect to bitcoind on localhost?
ria
# Why can't I connect to bitcoind on localhost?

(Asked by: username_0 on 2012-05-14)

The initial question asked was as follows, but it turned out to be nothing to do with keypools:

I had keypool=1000 before. Now I started bitcoind (the daemon version)
  with keypool=10000 option, and it is 2 hours already and bitcoind
  didn't start up yet. I.e. I still get error: couldn't connect to
  server when I try to do bitcoind getbalance.
Its a quite fast machine AMD 64bit 4000+ CPU with 10 GB RAM, how long
  the start-up time can be? And will it be so long every time I start
  the daemon, or only the first time?
Will future start-up times increase in any noticeable way if I keep
  keypool=10000 in comparison with 1000? Or any other performance
  degradation, except this first startup?

Edit: In the end it had nothing to do with keypool=10000. For some unknown reason my local interface was down. I fixed it with:
ifconfig lo up

I killed the bitcoin daemon with kill $PID, started it again and within a minute I could do bitcoind getbalance.

**Tags:** bitcoind, backup, keypool

> **Comments:**
> **username_1**: I don't know the answer. But I guess the slower startup is only the first time; after 10000 keys are generated, starting up should be quick.  
> **username_2**: I would believe it would slow Bitcoin down a bit when each block is validated, as the program will probably have to check each transaction for whether or not it matches every key in the wallet. I don't know how much slower it would go though...  
> **username_1**: @username_2: If there is a hashset of all addresses, scanning the block for relevant transactions should take the same time no matter how many there are. Unless the addresses in the block itself are indexed.  

---

## 3 answers

### Answer by username_3 on 2012-05-14. Score: 2

My "Intel(R) Core(TM)2 Duo CPU     T6600  @ 2.20GHz" laptop just took 80 seconds to create 1000 new addresses, so I'm surprised you're seeing over 2 hours for 10 times that.
One thing I noticed is that the address creation is noticeable faster now than I remember it - so perhaps upgrading to a recent version of the client will speed things up for you.
Run "tail -f ~/.bitcoin/debug.log" to see a log of which key number it's currently creating.
Either way, the start up should only be noticeably slower the first time, when the pool is initially created.
Edit: (in response to miernik's comment)
The debug.log output will end with lines like the following while it's populating the keypool:
keypool added key 41, size=41
keypool added key 42, size=42
keypool added key 43, size=43
keypool added key 44, size=44
keypool added key 45, size=45
keypool added key 46, size=46
keypool added key 47, size=47
keypool added key 48, size=48
keypool added key 49, size=49
keypool added key 50, size=50

The stuff you're seeing is what happens while bitcoin is running normally.  It's receiving and responding to messages on the P2P network.  I don't know what to suggest as to why it isn't accepting RPC connections.  Could it be a firewall issue, or some other configuration problem unrelated to the keypool argument?

> **Comments:**
> **username_0**: I've put the last 200 lines from debug.log here: http://dpaste.com/748342/plain/ Can you tell me which is the key number? How does such a line look like, so I can grep for it? BTW: its 18 hours already and still running.  

---

### Answer by username_0 on 2012-05-15. Score: 2

In the end it had nothing to do with keypool=10000. For some unknown reason my local interface was down. I fixed it with:
ifconfig lo up

I killed the bitcoin daemon with kill $PID, started it again and within a minute I could do bitcoind getbalance.


---

### Answer by username_4 on 2013-02-27. Score: 1

For others that might be encountering a similar problem, here are some other issues that I ran into:
1) IP ports not being opened:
/sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT

2) Make sure that your cloud instance security settings allow for TCP connections on the appropusername_0te ports.
3) If you have ssl enabled in the server, make sure that you created an ssl certificate:
https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon
4) Make sure to kill processes as others have described:
ps -A | grep bitcoind
kill [PID]


---

