something i didn't realize when backing up my wallet

[DeathAndTaxes]

It would make backups before the pool exhausts useless.

isn't that a good thing

Backups should always be periodic.

No, if data is critical (lots of money) it should not be periodic it should be backuped at each change, if I do weekly backup I risk loosing some coins.

Strangely I have never lost any coins with periodic backups.  Like I said fork the QT client and implement a different backup system.  I was advising the OP on how to increase the keypool and on how it works.

[1715428494]

1715428494

[1715428494]

1715428494

[1715428494]

1715428494

[auzaar]

bitcoind is often used in automated processes, far easier to just regularly perform backups.

If bitcoind could generate event for backup then that can be backed up exactly when needed, for now it will generate event every transaction which I think is a bad design, wallet should change state and generate event periodically and user should have option to be alerted, ignored, or run a command.

Long term is long term away

[BitThink]

It seems multibit sometimes send change back to the origin address. What's the problem of this? Does this mean in this case no new change address is created?

[jim618]

It seems multibit sometimes send change back to the origin address. What's the problem of this? Does this mean in this case no new change address is created?

You are correct.

MultiBit does not create new change addresses. The only private keys in the wallet are for the addresses you see in the 'Request bitcoin' tab.

This is not very good for privacy, but does make the backups life longer.
If you create new receiving addresses (i.e. new private keys) then you need to make new backups.

(The next version of MultiBit - MultiBit HD - will have a deterministic wallet)

[Barek]

Address reuse issue.

It is much more secure (not just more anonymous) to never re-use an address (and yes - am aware of my sig and you'll notice there a no unspent outputs on that address).

The reason being that once you have signed a tx for any unspent output that was sent to that address (i.e. once you "spend from it" and with the standard client you can't easily control how it chooses which unspent outputs to "spend from") then you have "released" your "public key" (prior to that only the Base58 encoded RIPEMD hash of it was publicly known - also known as the "address").

Now if the ECDSA that Bitcoin uses ever becomes found to be "crackable" then the "private key" to your "address" could be feasibly be cracked and any "remaining" unspent outputs to that address could now be spent by the cracker.

And another pointer to Amory's deterministic wallet. One paper backup is enough to restore all future private keys.

[BitThink]

Address reuse issue.

It is much more secure (not just more anonymous) to never re-use an address (and yes - am aware of my sig and you'll notice there a no unspent outputs on that address).

The reason being that once you have signed a tx for any unspent output that was sent to that address (i.e. once you "spend from it" and with the standard client you can't easily control how it chooses which unspent outputs to "spend from") then you have "released" your "public key" (prior to that only the Base58 encoded RIPEMD hash of it was publicly known - also known as the "address").

Now if the ECDSA that Bitcoin uses ever becomes found to be "crackable" then the "private key" to your "address" could be feasibly be cracked and any "remaining" unspent outputs to that address could now be spent by the cracker.

And another pointer to Amory's deterministic wallet. One paper backup is enough to restore all future private keys.

As far as I know, it is not feasible to deduce the private key from the public key. That's the basic requirement of any asymmetric encryption algorithm. If this is cracked, then many networking protocol is not safe any more. For example, ssh and https are both based on SSL (yes they are RSA or DSA based, not exactly ECDSA but quite similar).

But I agree exposing only 'address' is a good idea anyway if it is really a cold storage.

[Barek]

I agree that it is a little on the paranoid side.

However, think back on the recent Android RNG debacle. Had those wallets not reused addresses, the private key could not have been computed.

[TippingPoint]

I backup automatically once a week with sequentially named backups.  The likelihood of losing any keys is essentially zero.

I agree.

Backup1a
Backup1b
Backup1c
etc.

appears to be much better than

Backup
overwrite Backup
overwrite Backup
overwrite Backup
etc.

[Barek]

As long as you don't do more than 100 transactions between backups, you should be fine.

Backup integrity checks?
Backup at different locations?
Backup encryption?
Boot to the head type memory loss?

Paper backup with deterministic wallet ... yay.

[unk1911]

as bitcoin becomes more popular,  you can't expect people without a computer science degree to understand the intricacies of the algorithm.  i think the most sensical thing to do is to warn someone who is creating a backup about what will happen with default settings if 100 keys are exhausted...

as someone WITH a computer science degree,  and as someone who has been around bitcoin since 2011,  i didn't really start backing up my wallet until recently.  i used to hold the coins in my mtgox account until mtgox disappointed me with a certain transaction went sour. the manner in which they handled it (i got my money back eventually but it was quite the agonizing 2 weeks), i have decided to part ways with them and decided to use the physical client (bitcoin-qt) as the primary store of the coins.  i started backing up my wallet and one day decided to run through a COB scenario in which i imagined what i would do in the event my computer had crashed... and then i realized the whole keypool=100 issue...   

at the time of creating the backup, i understood the concept of private keys and the idea that the backup of the wallet.dat file essentially stores the private key, along with my addresses i used, which is all that is really needed to store the value of the coins-- however,  at that time, i wasn't privy to the implementation details inside bitcoin-qt involving the keypool size=100,  and that once you run out of those keys, the new keys that are generated will not be in the old backup file... so that seems like an implementation detail that the user shouldn't really be concerned with or exposed to,  in the same way that when i use dollar bills,  i do not know all the intricacies involved in the various inks and paper types used to create the bills... i just transact with the bills without giving it a second thought...  isn't this an obvious flaw/issue with the bitcoin-qt?

[Barek]

In an interview, the lead developer of Armory says that the reference client bitcoin-qt will adopt the deterministic wallets, similar to those Armory uses.

Theoretically the concept is simple. If the seed for the pseudo random number generator is saved, all the generated addresses will always be the same. For example, given a certain seed, the 10th private key will always be the same.

Interview:
http://letstalkbitcoin.com/e55-happy-birthday-bitcoin/#.Unj_z-VX98E (around 16:00)

[AgeraS]

as bitcoin becomes more popular,  you can't expect people without a computer science degree to understand the intricacies of the algorithm. 

.....isn't this an obvious flaw/issue with the bitcoin-qt?

To me it is obvious that in order for Bitcoin to be used as a day-to-day currency it must appeal to the lowest common denominator, otherwise people will just continue using cash and credit-cards, ceteris paribus. In order for Bitcoin to succeed as a day-to-day currency it must be simplistic enough to the point at which all one needs to know is, "send coins to (address)," "receive coins at (address)."

[DeathAndTaxes]

as bitcoin becomes more popular,  you can't expect people without a computer science degree to understand the intricacies of the algorithm.  i think the most sensical thing to do is to warn someone who is creating a backup about what will happen with default settings if 100 keys are exhausted...

I am pretty sure long before Bitcoin is mainstream there will be no "random key" wallets outside of niche applications used by professionals.   Deterministic wallets are far easier to understand, and safer for the average user.   Remember the QT client is the reference client and as such it is rather conservative at adopting enhancements.  In time I am sure it will either be deterministic as well.  With a deterministic wallet one simply needs to backup and/or print the deterministic seed once and the backup is valid forever.

Given enough time you probably will even see hardware deterministic wallets which are completely "user proof" in that the deterministic wallet comes with a preprinted "THIS IS YOUR WALLET RECOVERY DOCUMENT.  PLACE IT IS A SAFE PLACE.  TREAT IT LIKE CASH AND ENSURE IT IS NOT STOLEN. IF YOUR WALLET FAILS YOU FUNDS CAN NOT BE RECOVERED WITHOUT THIS DOCUMENT."   User buys the wallet, puts the recovery doc in a safe, and if their wallet fails buy another one, scans the QR code on the recovery doc and is back up and running with no loss of funds.


Bitcoin isn't mainstream yet.
QT client is the reference node and increasingly not the best choice for casual users.
There has to be a complete, solid, well tested reference node to ensure the network operates as expected.  It probably will always be "rougher" than clients designed for casual users.  The need for full blockchain is probably going to drive casual users to more "friendly" (SPV) wallets anyways.