There were some very good points made in this thread and just so that they aren't overlooked I'm putting in a recap / summary:
Keep a copy of your current wallet before doing this, of course.
Yes, step 1 of any offers given to help someone in a scenario like this should include:
Before you try reverting to an old wallet, or performing pywallet surgery on your wallet, make sure that you make a backup (or two) of your current wallet.In this instance, Jeremy made over 100 transactions. Had he reverted to an old wallet, and wasn't using a large keypool already, there is the possibility that he would have given out Bitcoin address and received payments to them where these addresses didn't exist yet when the most recent backup was made.
Hopefully everyone actively using Bitcoin at these levels is well aware of the keypool and has adjusted the keypools size to be large enough so that the backup and recovery strategy will make it so there is not ever result in lost bitcoins because of not having backups that include new keys.
Here's notme's mention of that:
I think the default keypool is only 100. If you're doing this many transactions you should set the keypool size to 1500 or some other high number so your backups are at least valid for a few days.
The Bitcoin.org client isn't clogged up to accommodate every use case out there, so merchants should know that the -keypool=
configuration setting and a good backup strategy require proper attention to prevent the situation where there are lost bitcoins. If your backup strategy is to take a nightly snapshot (shut down the client & copy the wallet.dat) and retain that backup copy for each night over the past 7 days, then you probably want a key pool of multiple days worth of transactions (or, more specifically large enough for multiple days worth of addresses that are consumed from the keypool). As notme suggests, 15X daily usage is not rediculous (they're really cheap so why not!).
To the devs: isn't this a bug in the Satoshi client? Shouldn't the client try to rebroadcast unconfirmed transactions once in a while? If it does rebroadcast, just not fast enough for Jeremy's needs, then isn't this an enhancement issue that should be logged anyway?
The client will rebroadcast within in a half hour. The normal use case is for this to not occur on startup as that lessens the transaction anonymity. The ability to force a rebroadcast was discussed but the conclusion was that the range of zero to 30 minutes was sufficient so the ticket was closed:
- https://github.com/bitcoin/bitcoin/pull/421
So after the cosmetic problem where there are 0/unconfirmed transactions is resolved for Jeremy it would be useful to try to understand what might have caused this to occur in the first palce. There is an attack in which this exact situation could be the result (the vector76 attack or "one confirmation attack") but that probably isn't what happened here. Further information on this attack here:
- https://github.com/bitcoin/bitcoin/issues/1428
Ending up in this situation where you have these 0/unconfirmed spend transactions that will never confirm isn't something that is easy to do unless either you are doing something wrong (e.g., either purposely trying to double spend, or accidentally double spent by using the same wallet on multiple nodes and unwittingly created a double spend in the process) or you happened to not only be the target of a double spend but you happened to also use funds from that double spend for a spend transaction yourself.
Any guess as to what might have happened here? 
