Author

Topic: Is there any point to encrypt a bitcoind wallet if it's being unlocked often (Read 1238 times)

sr. member
Activity: 910
Merit: 302


Unlocking a wallet takes about 0.1 seconds of CPU time, during which time most other wallet operations are suspended. The number of keys in the wallet does not affect unlock performance, a key is only unlocked when required (for as long as the wallet remains in an unlocked state). If performance is a concern, you should consider specifying a longer timeout when unlocking the wallet, and then anytime you need to perform an operation which requires an unlocked wallet, you should start off by assuming it is already unlocked, and handle errors where your assumption was wrong by unlocking the wallet and retrying the operation.
ecure application design is really hard... if you're not an expert (not that I claim to be one), you might be getting yourself into trouble with storing a wallet on an Internet-facing server...

Hm, that seems rather high, especially the suspension of other operation, since this is being done for every visitor of the site.

What is the common practice, unencrypted wallet on non-internet facing server, that's accessed only via the internal network or something else?
hero member
Activity: 672
Merit: 504
a.k.a. gurnec on GitHub
Let's say you have your wallet.dat encrypted on the internet facing server, but need to unlock it all the time to refill the pool when generating new addresses (because the service does that for every visitor) and when doing transactions.
So, effectively it's being unlocked like every 10-20 seconds or so when the site gets traffic.
In that case is there any point to encrypt it at all?

An encrypted wallet.dat remains encrypted on disk even when unlocked, it's only unlocked in RAM. Depending on your application design, this could improve security. For example if you have a 2-tier app plus bitcoind, where only the backend tier has access to bitcoind, then a vulnerability in the frontend tier which permited read access to the wallet.dat file would not on its own compromise the wallet.

How does encryption affects performance on big wallets?

Unlocking a wallet takes about 0.1 seconds of CPU time, during which time most other wallet operations are suspended. The number of keys in the wallet does not affect unlock performance, a key is only unlocked when required (for as long as the wallet remains in an unlocked state). If performance is a concern, you should consider specifying a longer timeout when unlocking the wallet, and then anytime you need to perform an operation which requires an unlocked wallet, you should start off by assuming it is already unlocked, and handle errors where your assumption was wrong by unlocking the wallet and retrying the operation.

Newer versions (starting from 9 maybe?) don't require unlocking anymore when requesting new addresses.

I assume that unlocking becomes required once the key pool runs dry, correct?


Incidentally, secure application design is really hard... if you're not an expert (not that I claim to be one), you might be getting yourself into trouble with storing a wallet on an Internet-facing server...
legendary
Activity: 1358
Merit: 1001
https://gliph.me/hUF
Are you refilling the pool or generating a single address?

Newer versions (starting from 9 maybe?) don't require unlocking anymore when requesting new addresses.
sr. member
Activity: 910
Merit: 302
Let's say you have your wallet.dat encrypted on the internet facing server, but need to unlock it all the time to refill the pool when generating new addresses (because the service does that for every visitor) and when doing transactions.
So, effectively it's being unlocked like every 10-20 seconds or so when the site gets traffic.
In that case is there any point to encrypt it at all?
How does encryption affects performance on big wallets?
Jump to: