By default, Bitcoin Core creates 100 addresses the first time it starts, and tries to keep 100 not-yet-used keys in wallet.dat 'keypool' (when you unlock the wallet to make a payment it will generate more).
So you do not need to backup continuously. The 'getinfo' RPC command will tell you the time when the oldest not-yet-used key was generated ('...
When a wallet is created, it contains 100 keys in its "key pool". Only one of them is made visible, but when you create a new address, it actually just takes one key from the pool. The reason for this is so you don't need to backup your wallet.dat file after every transaction or new address,
New keys are generated every time one is pulled from the key pool, ...
A wallet (by default) always contains 100 unused keys. Every time the client needs a new key (for a new address, for sending change to, or - in theory - for solo mining payouts), it takes the oldest address from the pool, and creates a fresh one to add.
This just means you need to backup every 100 transactions. No need to switch to a new wallet.
Your wallet keeps all private and public keys it ever used indefinitely. You do not lose coins on old private keys when you give out new addresses.
It is just a privacy measure to give out new addresses for each transaction. It prevents your business partners from knowing about other transactions you have received and sent.
All addresses can be used ...
That's a tricky one.
If you haven't modified the 'keypool' parameter then your key pool will contain 100 "unassigned" addresses. These addresses are controlled by your wallet but remain in a latent state in your client until you explicitly request for a new address.
The thing is that every time you request for a new address, a new one will be added to ...
Providing that you're referring to BitcoinCore, and that by "not being used right now" you mean there's no transaction associated with them yet, you can use this command to list them:
bitcoin-cli listreceivedbyaddress 0 true
The parameters are:
minconf = 0
includeempty = true
If you call getnewaddress 100 times (via RPC for bitcoind, in the debug console for Bitcoin-Qt), the key pool is flushed.
After that, you can request one more new address and send all your funds there.
How about multibit or electrum? Do they also use a key pool?
Electrum is deterministic and addresses are derived from your seed. Each time you need a new address, Electrum calculates it and shows it in the client.
Being deterministic lets Electrum recover your entire wallet addresses from your seed, so you don't need to backup your wallet file every time ...
Bitcoin-QT with standard settings will keep 100 unused addresses in your wallet at all times. The goal is that backups will be future proof to some extent.
A key pool allows to create backups in bigger intervals
Every time you create a transaction, the remainder of the input balance is sent to a new address in your own wallet. If addresses were generated ...
They don't become invalid. When you ask for a new address from the client, it will not choose any that it has already given you. This is for your privacy, because it makes it more difficult to associate those addresses with you.
In this case, we're making them as used for a different reason. To explain why, let's suppose the wallet didn't treat the ...
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.
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.
It is also recommended that immediately after encrypting that you then spend your coins that existed prior to encryption to a new address generated post-encryption.
That way if your old wallet backups were to fall in the wrong hands, your funds would still be safe.
If you didn't do that, then your funds are still spendable from the wallet that was backed ...
No, because the encrypted keys don't change in that case.
When you encrypt a wallet.dat file, a random master key is generated, the master key is encrypted using your passphrase, and the actual address keys are encrypted using the master key.
When you change the passphrase, only the encrypted master key is changed.
Most people don't need to use keypoolrefill.
Bitcoin Core tries to fill the keypool to its configured maximum size whenever you take an address from the keypool. (It does not wait until the keypool is empty before regenerating it.) However, it isn't possible to add keys to the keypool unless the wallet is unlocked with walletpassphrase. So if you call ...
What I ended up doing was more or less what Pieter Wuille suggests: write a small shell script to call bitcoind getrawchangeaddress more than 100 times. (Using getnewaddress would have cluttered my list of receiving addresses.)
The current wallet.dat file increases because you add new keys when you refill your keypool (get new addresses) or if you receive or send transactions. Mind that every wallet-relevant transaction is stored (together with some metadata) in your wallet.dat.
The page you are referring to on the Bitcoin wiki is pretty dated and doesn't really relate to current behavior in Bitcoin Core. Be aware that a lot of the wiki is like this. "Default key" isn't a phrase in common use, I can't fathom what that page could have been talking about in the context of Bitcoin Core.
Reserve keys and the keypool are essentially ...
The value 1392447127 is exactly Sat, 15 Feb 2014 06:52:07 GMT in Unix timestamp
check it here : http://www.onlineconversion.com/unix_time.htm
keypoololdest gives the unix timestamp of the oldest key in the key pool (which stores unused keys). This timestamp can be used to check if a wallet backup still covers all your used keys or a new one needs to be ...
How many keys can be generated by a deterministic wallet?
Effectively infinitely many. The same as a non-deterministic wallet which just keeps generating random private keys. There is a limit, 2^256, but you are never going to reach that. It is effectively infinite.
Is it possible to list all keys (public keys, to avoid leaking critical information) in ...
keypoolsize only shows how many keys are currently in the keypool. It does not reflect the maximum size of the keypool. The keypool=<n> option does not automatically fill the keypool to that size, you will need to refill it by using keypoolrefill.
If after keypoolrefill you still do not see a larger keypool, then that means your bitcoin.conf file is ...
A long sequence of private keys can be computed from the seed in a standard way. The new client will import those keys for your use, while computing the corresponding addresses and checking the block chain to see which ones have been used. When it finds many keys in a row that haven't been used (perhaps several hundred; this number may be configurable in ...
Keypool keys are already in wallet.dat. That's the whole point of the keypool. When you run getnewaddress, you get the address corresponding to the oldest key in the keypool, and a new key is generated and added to the keypool to take its place.
So if your hypothesis is right, the key is still in the keypool, and if you execute getnewaddress again, you ...
The keypool, as the name suggests, is a pool of keys stored in your wallet.dat file for various functions including:
By default you'll have 100 keys. Each time you use a key for change or receiving, there'll be one less key in the pool. A new key is added to replenish the used key.
The oldest key (from February 2014) ...
What is the maximum number of keys/addresses that can be created for a single wallet? Phrased another way, what is the largest value one can safely put for the keypool option in bitcoin.conf?
The type of that parameter is int64_t so the maximum value is 2^(64-1)-1. In practice, you can put any number you want and it should not make the software break. ...
You have probably considered it already, but the only thing I can think of, is to create a new wallet.
Make a new wallet, and get an address from it
Backup your old wallet
Delete the old wallet from the Bitcoin directory
Start Bitcoin Core (it'll create a new wallet).
Copy a receive address from the new wallet.
Close Bitcoin Core
Transfer the bitcoins ...
Consider using hierarchical BIP32 wallets. You can generate the addresses with various tools (e.g. sx) or natively in your web app. Then you can import the keys to your bitcoind node in order to manage them. If needed, you can have multiple bitcoind nodes and load-balance the keys among them (e.g. having X customers per node).
The great advantage of BIP32 ...
Getnewaddress simply marks a private key in the wallet.dat as being used (or, to be more specific, removes that address from the key pool) and returns that address in the response.
So the private key already exists in wallet.dat prior to the getnewaddress call.