<p>The problem has to do with other processes on the computer with too high CPU priority:</p>

<p><a href="https://raspberrypi.stackexchange.com/q/42474/39301">https://raspberrypi.stackexchange.com/q/42474/39301</a></p>

CC BY-SA 3.0
2016-02-12T18:29:46.847Z
2016-02-12T18:29:46.847Z
2017-04-13T12:56:29.273Z
pinhead
<p>Bitcoin 0.11 on a Raspberry Pi 2:</p>

<p><a href="https://github.com/jgarzik/python-bitcoinrpc" rel="nofollow">https://github.com/jgarzik/python-bitcoinrpc</a></p>

<p>I am using this RPC auth proxy to talk to bitcoind from Python. I have a script that requests <code>getmempoolinfo</code> every 1 second. Occasionally given user input a new address is needed, and the script requests <code>getnewaddress</code>. This RPC-call often times out.</p>

<p>Sometimes the time-out causes even weirder behavior in other RPC calls until python is interrupted and the script killed: for example, <code>getmempoolinfo</code> returns the same information every time it is called until the script is restarted. Even querying bitcoind from the command line in a separate terminal window <code>bitcoin-cli getmempoolinfo</code> indicates that the mempool is not growing at all until the script that timed-out calling <code>getnewaddress</code> is terminated.</p>

<p>I also notice from the command line <code>bitcoin-cli getnewaddress</code> can take up to 30 seconds, without any python scripts running or other in-progress RPC calls.</p>

<p>I thought bitcoind is just retrieving a new address from wallet.dat, what is taking so long? It's not decrypting the wallet, it's not generating a whole new address from entropy... yet this specific RPC call is causing me lots of downstream problems.</p>

CC BY-SA 3.0
2016-02-08T11:13:21.857Z
How large is your wallet, in keys/transactions/megabytes?
Pieter Wuille
CC BY-SA 3.0
2016-02-08T15:17:38.267Z
101 keys, 0 transactions. I wonder if it's disk io? The wallet and the blockchain are both on the same USB flash drive.
pinhead
CC BY-SA 3.0
2016-02-08T15:23:06.563Z
Wallet.dat is 294 kb. Interesting, command line `dumpwallet` works instantly.
pinhead
CC BY-SA 3.0
2016-02-08T15:28:51.820Z
Please report this as a bug in that case: https://github.com/bitcoin/issues.
Pieter Wuille
CC BY-SA 3.0
2016-02-09T00:05:03.397Z
https://github.com/bitcoin/bitcoin/issues/7486
pinhead
CC BY-SA 3.0
2016-02-11T10:37:13.900Z
Judging from the discussion on github, you probably have found out what the issue was. Could you please summarize your findings by answering your own question for other users that find this question later?
Murch
CC BY-SA 3.0
2016-02-11T17:45:51.407Z
@Murch I'm still working on it...
pinhead
CC BY-SA 3.0
2016-02-11T17:48:51.693Z
Oh, sorry, it appeared to me that it would probably have been the USB stick. Nevermind then! Good luck.
Murch
CC BY-SA 3.0
2016-02-11T17:50:02.683Z
@Murch last night I switched out the stick with an SSD drive, a lot of things went faster but I think there's another process running on my Pi that is still making `getnewaddress` timeout - even up to 45 minutes! I'm using the Pi's GPIO to drive an LED matrix.
pinhead
CC BY-SA 3.0
2016-02-11T17:50:51.950Z
Oh wow, that's too bad. Hope you'll figure it out.
Murch
<bitcoind><json-rpc><python><address-generation><raspberry-pi>
Why does getNewAddress take so long? Often times out python-bitcoinrpc
pinhead
# Why does getNewAddress take so long? Often times out python-bitcoinrpc

(Asked by: username_0 on 2016-02-08)

Bitcoin 0.11 on a Raspberry Pi 2:

<https://github.com/jgarzik/python-bitcoinrpc>

I am using this RPC auth proxy to talk to bitcoind from Python. I have a script that requests `getmempoolinfo` every 1 second. Occasionally given user input a new address is needed, and the script requests `getnewaddress`. This RPC-call often times out.

Sometimes the time-out causes even weirder behavior in other RPC calls until python is interrupted and the script killed: for example, `getmempoolinfo` returns the same information every time it is called until the script is restarted. Even querying bitcoind from the command line in a separate terminal window `bitcoin-cli getmempoolinfo` indicates that the mempool is not growing at all until the script that timed-out calling `getnewaddress` is terminated.

I also notice from the command line `bitcoin-cli getnewaddress` can take up to 30 seconds, without any python scripts running or other in-progress RPC calls.

I thought bitcoind is just retrieving a new address from wallet.dat, what is taking so long? It's not decrypting the wallet, it's not generating a whole new address from entropy... yet this specific RPC call is causing me lots of downstream problems.

**Tags:** bitcoind, json-rpc, python, address-generation, raspberry-pi

> **Comments:**
> **username_1**: How large is your wallet, in keys/transactions/megabytes?  
> **username_0**: 101 keys, 0 transactions. I wonder if it's disk io? The wallet and the blockchain are both on the same USB flash drive.  
> **username_0**: Wallet.dat is 294 kb. Interesting, command line `dumpwallet` works instantly.  
> **username_1**: Please report this as a bug in that case: https://github.com/bitcoin/issues.  
> **username_0**: https://github.com/bitcoin/bitcoin/issues/7486  
> **username_2**: Judging from the discussion on github, you probably have found out what the issue was. Could you please summarize your findings by answering your own question for other users that find this question later?  
> **username_0**: @username_2 I'm still working on it...  
> **username_2**: Oh, sorry, it appeared to me that it would probably have been the USB stick. Nevermind then! Good luck.  
> **username_0**: @username_2 last night I switched out the stick with an SSD drive, a lot of things went faster but I think there's another process running on my Pi that is still making `getnewaddress` timeout - even up to 45 minutes! I'm using the Pi's GPIO to drive an LED matrix.  
> **username_2**: Oh wow, that's too bad. Hope you'll figure it out.  

---

## 1 answers

### Answer by username_0 on 2016-02-12. Score: 0 | Accepted answer

The problem has to do with other processes on the computer with too high CPU priority:

<https://raspberrypi.stackexchange.com/q/42474/39301>


---

