Yes; in fact, the wallet format remains compatible as long as no new-style keys are generated. As soon as a new key in generated in 0.6.0 onwards, the wallet will not be compatible anymore with pre-0.6.0 clients.

Note that 0.6.0rc1 does not yet prevent old clients from opening such a new wallet, potentially corrupting the wallet. The next release candidates will do so.

This looks like some sort of strange corruption occurred in your wallet; can you provide any more details, for example what you did to get it in this state?

Certainly; most keys are (and should) only be used once or a limited number of times. For the purposes of this "attack" all that matters is how many addresses exist with a non-zero balance.

The original question is what would happen if you accidentally generate a private key corresponding to an address that already exists. Simple: you get access to any remaining funds available to that key. In case a rescan is done (typically not done when generating a new key, as the software assumes it is fresh), you would indeed see earlier transactions that key's address was involved in.

There are only 2^160 possible addresses, but that hardly matters for the conclusion

Since 0.3.21, -rescan is only necessary is exceptional cases.

You can swap your wallet.dat just fine without it.

Start with -rescan

This was fixed in commit 38067c1.

One of the two what? You seem to be talking about transactions instead of keys here.

The keys don't need to be identical by the way - only their corresponding addresses.

Or you can store everything in binary, without the base58 whatsoever. 32 bytes for a privkey, 20 bytes for an address.

Down to 5742252960529749071145716877414485176439322664845761613895220154201014272 MiB.

11705361804156796183489345942421835167357080816800975597555641083563606016 MiB.

Assume the entire bitcoin network's computational power is used for generating addresses, we'd see about 1000 billion addresses generated per second (it's around a factor 10 slower at least than hash testing). Assume this speed is maintained for as long as bitcoin mining is subsidized (until around 2140), we'd see about 4*10^17 addresses.

Since there are around 1.4*10^48 possible addresses, the chance that a duplicate is found can be calculated using the birthday problem as 1-exp(-(4*10^17)^2/(2*1.4*10^48)), or approximately 0.000000000005%, which means one in 20000 billion.

For all intents and purposes this chance can be considered 0.

Jim,

that feature is called "determinstic wallets" usually - it is specifically designed for ease of backup and the ability to have several clients share the same (piece of) wallet without them diverging from eachother. Using some EC math tricks, you can do very nice things, such as a "read only" version that does not allow spending.

Read more here.

Except you don't know which input sendmany is going to use, so you don't know how much to send back.

Nothing, but there are hardly any miners on the testnet network. This may result is very large variations in confirmation speed.

This is not correct. There is no way to spend just part of a single transaction output ("coin"), but the balance of an address may consist of several transaction outputs, in which case they can be spent individually.

It is not a GUI tool, running the exe will start it without arguments, so it will just show its help text and exit immediately.

What you want to do is start a command-line (start -> execute -> "cmd" or something in windows), go to the directory the program is in (using cd [dirname]), and then type "vanitygen", and see what it tells you about what arguments it accepts.

I believe makomk is right here: old clients only use "only pushes" as criterion for validating an input's standardness.

Still, as soon as BIP16 is deployed with a supermajority of miners behind it, the other miners already have a large incentive to upgrade. This is one extra reason they will want to do so.

However, if switching happens at exactly 55% support, there still exists a 0.83% chance to have 6 consecutive blocks by old miners, which means a small but reasonable chance old nodes see an invalid from-BIP16 transaction with 6 confirmations. This is an extra reason for requiring significantly more than 55% support, imho.

You probably want to run it from a command-line, so you can give it information about what it needs to search for.

What about
$ ./bitcoind importprivkey xxxxx
? (bitcoin v0.6)