Topic: Increasing the number of keys in key pool (Read 3813 times)

Wow, necro! hehehehe..

What I plan to do now is maybe make a new wallet once a year. With the just released 0.9.0 core client, you can use a brand new wallet by using the -wallet switch. If you're like me, you might want to put either zero keypool, or keep it at 100.

I just simply archive my old wallets, keeping them safe, just in case coins get sent there. What I will probably do is create a plain-text backup of all the private keys so I can import them any time, and use blockchain or an app to check on address balances every now and then.

IMO instructions should be something like:

1. Keep backup of wallet prior to encryption in case anything goes wrong.

2. Encrypt wallet (and *verify* that you know your pass phrase).

3. Backup encrypted wallet (don't throw away the old backup when doing this and make more than one such new backup).

4. Verify that the new backup works and that you still "know your pass phrase".

5. Once satisfied your new backups are find and that *know* your pass phrase then for better security send your entire balance to a "new addresses" (after this point the "old backup" will be useless).

And this is very misleading because if somebody copies your wallet.dat before you encrypt is, he will still be able to spend the coins you have on your addresses which are not empty and thus not purge during the encryption process (otherwise, you would obviously loose your coins...).

I think this is actually worse than having no further notes after finishing the encryption.

This text should be reviewed!

Since we are talking mostly about new users, they will not have any wallet yet at all.

How about giving them the option to start with an encrypted wallet? From the start? New User!

Or, without any other data, on a freshly installed computer, allow the client the option to NOT create a wallet or NOT to use a wallet at all. New users will not be generating coins. New users just need to download the block chain, and you don't need a wallet for this. Besides, new users will probably not have any coins to begin with.

And old users (or experienced users) may want to start like new. New computer, new OS, new bitcoin client, new wallet that is already encrypted. So there would never be an unencrypted wallet at all.

I think it's a valid concern that users might read the part of the message that says "[...] previous backups of the unencrypted wallet file will become useless as soon as you start using the new, encrypted wallet." as meaning that the unencrypted backup is now of no use for a hacker if one were to get hold of it, instead of meaning that the backup cannot be relied upon as a replacement for the encrypted wallet.

The thing is, we need to convey both the following facts, without confusing the user too much:

1. The user cannot rely on the old, unencrypted backups as a replacement for the new, encrypted wallet file
2. At the same time, the old, unencrypted backup can still contain keys that are in use with the encrypted wallet

I think the best solution, as has been mentioned, is simply to move over all coins, that are associated with the keys from the unencrypted backup, to a new key from the encrypted wallet. Would there be any problems in doing this (besides finding someone to implement it)?

How about changing the message to the following as step in the right direction for now?:

It seems like no one is sharing my opinion here, still I would like to explain why I think it would be better to simply encrypt the wallet without changing anything else:

- the argument is that all keys that existed unencrypted are considered "not safe", but the keys for addresses that have allready received coins still exist in the encrypted wallet. So your security situation has not improved until you send coins from the encrypted wallet and even then only the change from the transaction is "safer" than before.

- the procedure as it is now complicates things. For example, I can make backups from an unencrypted wallet and encrypt this backups later and everything will be fine (because the old key pool still exists in the encrypted wallets but is marked "unsafe"). But if I make my backups and then encrypt my "main" wallet", I risk losing coins should I ever need my backups. (By the way, this is what I would like to have: encrypted main wallet and unencrypted backups)
Of course a message after the encryption will improve the situation but my concern is that people will either ignore this message or they might mistake it in a way that they assume that their wallet is automatically safer now and they don't have to take care of old unencrypted backups (and delete them).

My current level of Satoshi client patching is "MODYFYING STRINGS", so while this is definitely a good idea (and should probably be done by default), I can't implement that with my current knowledge.

Make it simple:

Warning: After encryption, make a backup of your new wallet and discard all previous backups. See *insert*webpage* for detailed explanation.

You have 17.29382 bitcoins from your previous unencrypted wallet, would you like to send them to a new address in your new encrypted wallet? (click yes / no / maybe / i'm not sure.)

I considered making the message longer and more descriptive. But I'm afraid people will just ignore it if a giant wall of text appears.

Please feel free to compose a better message, and post it on the Github page for the issue. I think you are right, but I'm not quite sure how to get it across without the message becoming too verbose.

I prefer random keys too, but realistically speaking, cracking the master seed is equivalent to either 1) breaking all EC math, including bitcoin, or 2) stealing your wallet and cracking your password.  (I'm pretty sure armory encrypts the master seed at least as well as the reference client encrypts the private keys.)

In either case, you have big problems.  EC wallets have plenty of advantages, and only insignificant theoretical disadvantages.  They should probably be the default.

The risk with deterministic wallets is obvious. If someone cracks the deterministic seed used, he has all your money, now and into the future, for that particular wallet. With a randomly generated wallet, someone would have to crack or bruteforce every private key. Of course, if someone cracks the passphrase used for encrypted wallets, he has everything in your current wallet up to the key pool maximum (or future 100 transactions) but not your 101st transaction. (for default keypool=100).

I say, give the user the choice. I prefer randomly generated wallets.

I think an option for the client would be to set a maximum number of keys used, so that, for example, if you have already 1000 keys, and you have made 1000 transactions, the client would just re-use an old key. This way, you can keep a backup of your wallet once (after generating 1000 keys).

Take the example of BitcoinSpinner. It only uses 1 key. That's an extreme, but you can have the satoshi client fix your maximum keys to an arbitrary number of your choice (and probably force it to pre-generate that number already.)

To prevent the client from generating too many keys and taking over your computer, maybe the satoshi client will also have a hard coded limit on what the maximum wallet size would be, like 65000 keys is pretty large for one wallet, for one person.

Weird.  Maybe CIYAM is right.   To avoid losing funds in the event a key was used in a non-standard way (say from a keydump) it probably doesn't delete them just marks them so they will never be used in future tx by the client.  

I didn't notice another part of your question.  You can make the keypool smaller if you wish.  100 is the default (IMHO should be larger given the trivial amount of space) but you can set it to any value even 0.  With keypool=0 you have no keypool the only keys in the wallet will be existing keys and new keys (when needed) will be "created on the fly".  NOOB WARNING (not you dabs but anyone who happens to read this): with a keypool of 0 you would need an updated backup after every tx involving a new key ("new address button", or spend w/ change) to avoid the risk of irrecoverable loss of funds.

Still all of this is somewhat academic.  Deterministic wallets are the future.  The ability to backup and/or print an encrypted deterministic seed and thus avoid a whole category of potential data loss scenarios provides huge value in making bitcoin "easier to use" while providing no real risk/downside. 

From what I've gathered it doesn't throw away those keys but after the encryption doesn't use them (at least for change addresses) either (I guess in the off chance somehow you managed to get funds sent to one of those addresses).

If the satoshi client discarded unused keys, then I would not have all the old unused keys inside the new encrypted wallet. My experiment had 108 old keys (I think I have 8 transactions). The new encrypted wallet has 208 keys, 108 from the old wallet including used and unused keys, and 100 more new keys.

I used bitcoin version 0.7 (the one just released) for Windows, and pywallet to export the keys from both the old unencrypted wallet, and the new encrypted wallet.

The difference between the two is I just encrypted the wallet, then I made a backup of the encrypted wallet.

Or maybe it's just my wallet since I created it when it was version 0.5 or so at the time (March 2012). Maybe the behavior for new wallets is different than for old wallets created with an old client? But I remember upgrading my wallet to a newer format (maybe it was version 0.6)

Not exactly it is important to understand there is a difference between keys in the "active/used" wallet and keys in the keypool.

The keys (i.e. used keys) in the wallet transfer over.  Obviously they would have to or you would lose all coins associated with those keys.   The entire keypool is erased and new keys generated.  The Satoshi client always uses the next key in the keypool for change.   It is never up to chance.   Also a larger keypool doesn't increase your administrative burden.  If you are doing manual extraction/key work on a wallet the keypool represents "future" keys.  100 or 10,000 it doesn't really matter.  If you only have a dozen active keys you simply need those keys.  

TL/DR
Used/active keys =/= keypool.
The satoshi client always uses the "next" key from the keypool for change and new addresses.

Actually, I prefer that the default keypool be made smaller. But that's just me, I don't have 100 transactions, and it is convenient for me to just take care of a dozen keys.

In my experiment, which anyone can duplicate, the newly encrypted wallet contains all the old keys AND 100 more new keys. The old keys are not useless, but the new keys will not yet have been backed up.

It's possible that the client just picked a key at random to send the change and it just so happens that it was not one of the old keys.

The keys existed on your disk in an unencrypted state.  They are not safe, they should not be used.  Marking them and generating new ones is the right thing to do.  Key encryption has been around for something like a year, and we are just now noticing that a few people have lost keys in strange situations.

1. +1 to this whole backup/encrypt wallet issue. I think this is really important, especially to people who are new with bitcoins (but apparently not only for them)

2. I do not think that flushing the key pool when the wallet is encrypted is a good idea. I understand why it's done, but when a program gives you the option to encrypt something I expect it to do right that: encrypt. I don't expect it to somehow modify/change my data.

That warning isn't quite right because it implies that the old backups won't be dangerous in the wrong hands, but they will until you have used all existing inputs.

Should the instructions really be to "replace" your old backups?

Instead you might want to describe how no prior backups will have the new encrypted keys and thus it is recommended to make new backups now.  Or something to that effect.