6

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.

Chris Moore
  • 14,745
  • 6
  • 65
  • 87
ria
  • 702
  • 4
  • 16
  • 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 May 14 '12 at 15:07
  • 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 May 14 '12 at 16:57
  • @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 May 14 '12 at 18:44

3 Answers3

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?

Chris Moore
  • 14,745
  • 6
  • 65
  • 87
  • 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 May 15 '12 at 04:21
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.

ria
  • 702
  • 4
  • 16
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 appropriate 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]
ZenBalance
  • 373
  • 3
  • 11