Topic: Restoring addresses from old backup (Read 878 times)
Is there some way to tell with the standard client / rpc interface if a new backup is necessary, i.e. when the keypool was exhausted?
Thanks for replies.
I think at least you should get up an alert in Qt, saying that "you've now added some new addresses, and you should take a new backup."
I've taken backup now because of this, and my computer didn't crash before I got it done. Have to say I like armory better when it comes to backup and stuff like that.
I think at least you should get up an alert in Qt, saying that "you've now added some new addresses, and you should take a new backup."
I've taken backup now because of this, and my computer didn't crash before I got it done. Have to say I like armory better when it comes to backup and stuff like that.
As I understand, and to my experience, in Armory you can take a single backup, and the program will be able to regenerate all addresses in a wallet based upon this one backup. It means that you can take one backup when you create the wallet, and that's all you need. It will use the information from the first address as a seed to generate the next, so you don't risk loosing the other private keys.
Is there something similar implemented in the Qt client? Or do I have to back it up every time I create a new address?
What information is used as seed when I generate a new address in the Qt client?
Is there something similar implemented in the Qt client? Or do I have to back it up every time I create a new address?
What information is used as seed when I generate a new address in the Qt client?
BIP 32 was developed by the Bitcoin-Qt devs, and will hopefully make it's way into Bitcoin-Qt in 0.8. But it's looking like it'll be a later release. This will provide multi-chain deterministic addresses (create multiple wallets built from one seed). I plan to implement the same thing in Armory so it will be compatible.
But at the moment, you are correct: this cannot be done in Bitcoin-Qt, and it's a real shame because requiring-regular-backups-at-the-cost-of-losing-your-money is a real problem in the world of end-user software. It's never worth dealing with backups until it's too late, i.e. "ehhh, I'll set it up next week." Plus, that means that your backup solution can't be extremely secure, because it still needs to be convenient since you're doing it multiple times. At least with a deterministic wallet, you can backup once, drive to the bank and put it in your safe-deposit box. Once.
Personally, I think this is the number one reason to use these alt clients, because the ability to backup once, forever is such a powerful feature.
Note that it is possible to increase the size of this pool if you wish.
A completely random seed is used for generating addresses in the Bitcoin-Qt reference client.
However, by default it generates (and keeps hidden from you) 100 additional addresses. When you request a new address (or the client needs a new address for "change" in a transaction), the client pulls from this pool of 100 addresses, creating a new address to add to the pool.
This means that you only need to create a backup of the wallet every 100 transactions or so (although more frequent backups wouldn't necessarily be a bad idea).
Note that if you have an un-encrypted wallet, the addresses in this pool are discarded and new ones are generated upon encryption of the wallet. This means that the addresses in the pool from a pre-encryption backup are useless for recovering coins from transactions after the encryption. In other words, if you encrypt your wallet it would be a good idea to immediately back it up.
However, by default it generates (and keeps hidden from you) 100 additional addresses. When you request a new address (or the client needs a new address for "change" in a transaction), the client pulls from this pool of 100 addresses, creating a new address to add to the pool.
This means that you only need to create a backup of the wallet every 100 transactions or so (although more frequent backups wouldn't necessarily be a bad idea).
Note that if you have an un-encrypted wallet, the addresses in this pool are discarded and new ones are generated upon encryption of the wallet. This means that the addresses in the pool from a pre-encryption backup are useless for recovering coins from transactions after the encryption. In other words, if you encrypt your wallet it would be a good idea to immediately back it up.
The Qt client does not use deterministic addresses. It pre-generates a pool of keys and uses them, so you don't have to back up after each new address, but you DO need to back up: a) after every 100 operations which use an address from the pool (new address, or transactions that send change to a new address), b) after you encrypt your wallet (the old key pool is flushed).
As I understand, and to my experience, in Armory you can take a single backup, and the program will be able to regenerate all addresses in a wallet based upon this one backup. It means that you can take one backup when you create the wallet, and that's all you need. It will use the information from the first address as a seed to generate the next, so you don't risk loosing the other private keys.
Is there something similar implemented in the Qt client? Or do I have to back it up every time I create a new address?
What information is used as seed when I generate a new address in the Qt client?
Is there something similar implemented in the Qt client? Or do I have to back it up every time I create a new address?
What information is used as seed when I generate a new address in the Qt client?
Jump to: