[SOLVED] I think I broke my wallet?

[CERN]

So, a couple days ago I decided to send the entire balance of one of my wallets to another wallet using ./bitcoind sendtoaddress

I made sure to account for the transaction fee and left that much out of the transaction

Okay, so it creates the transaction!  getbalance is now a healthy 0.0 BTC (and "" was a negative amount until I moved all acount balances to ""), yet... My transaction never made it into blockexplorer

It remains unconfirmed, and blockexplorer agrees that it does not exist at all  I have deleted my block chain and let it re-download, but my balance remains 0.0 BTC, the transaction remains at 0 confirmations (and remains unsent entirely), and I'm broke...

Does anybody have any idea how I can fix this?  I'd appreciate any help!

thx

[JoelKatz]

First, you're not broke. Your client only thinks you're broke. If the transaction never hit the network, the coins never actually left. Second, just leave the client running. Under unusual cases, it can take several hours for a transaction to hit the network. While you're doing that, see if it's already out there at this link which shows transactions that are on the network but not yet included in a block:
http://bitcoincharts.com/bitcoin/

[CERN]

Thx for the help JoelKatz!

It sadly isn't on bitcoincharts.com though   I forgot to mention that I was checking that for several hours after making the transaction, and that it never appeared there...

I wonder, is it possible for me to "undo" this transaction since it's been so long (days) without the network taking notice of it?  For all intents and purposes, it seems as though the transaction simply doesn't exist except in my local bitcoin client...

[JoelKatz]

You can manually edit it out of your wallet file, but that's a painful process. If you have a backup of your wallet from before you did the transaction, that's the easiest way. Otherwise, you can leave the client running for awhile and it should rebroadcast the connection every 30 minutes.

If you must remove the transaction, the only way I know of is to compile a build of the Berkeley DB tools using the exact same version as your build of the client. Back up your wallet. Then 'db_dump' it to a text file. Search the text file for the transaction ID byte-reversed. (So if it's 012345... search for ...452301.) When you find it, delete the line starting with '02' and the following line such that one of those two lines includes the transaction ID. Then 'db_load' the edited text file into a new Berkeley DB file and use that as your 'wallet.dat' file. It's painful.

We need 'delete transaction' function!

[CERN]

I'll do just that and see how it goes, thanks for the tip

Now, to compile a compatible version of berkdb...

[omarabid]

Well. This is not the first time I read that someone has issues with the Bitcoin software especially when sending/receiving. Isn't this a hint that the software or the bitcoin architecture needs an improvement?

[CERN]

I compiled Berkeley DB 4.7.25 (no patches) with -m32, and sure enough, it worked

I did it exactly like JoelKatz said...  The transaction is no longer reported by `./bitcoind listtransactions "" 1000` !  I still have to wait for the entire block chain to re-download before I can tell whether or not it saved the coins (I'm betting it did; I deleted the chain earlier when I was messing around with other ways to do this)

I'll update this post if it doesn't work, but until then, I'd say that it's solved

Thx JoelKatz

[CERN]

Bad news!  It didn't work. 

The transaction is indeed removed, but the bitcoins aren't ever returned.  Something must be missing...

I did another test on a fresh wallet just to make sure, too.  I started with a wallet that I deposited 1.0 BTC to (after letting it download the entire block chain freshly), sent a small amount to an address in another wallet, and then emptied the rest with a second transaction (this reproduces the bug I'm trying to solve in my main wallet!)

Then, I modified the wallet.dat using db_dump and db_load as JoelKatz specified.  The transaction disappears (picture below), but the bitcoins are never refunded...

http://img833.imageshack.us/img833/4307/43969381.jpg

Something in the wallet has to be telling the client that the bitcoins are in use for a transaction, but I can't find enough information about the wallet format to figure it out...  I'd appreciate any insight!

[bitnotifications]

It is sometimes really intransparent what is stored exactly inside of the wallet. I wish there was a comprehensive viewer/editor for wallets.

[Tril]

Run bitcoind with the -rescan option.

[CERN]

Run bitcoind with the -rescan option.

No luck, sadly...  I tried it with a copy of my original, un-edited wallet.dat, and with the wallet.dat I've removed the transaction from.  I'm just puzzled...

If anybody would like to play around with this, the steps to reproduce the bug(?) are thus:

1.  Back up your existing files!
2.  Create a fresh wallet.dat and generate an address to receive funds at (maybe on Testnet :p)
3.  Use an account from a different wallet to send a small amount of bitcoins to the new wallet
4.  Transfer 100% of the funds from the new wallet to somewhere (TX fee size doesn't matter, but make sure you'll wind up with exactly 0.0 BTC from this transaction)

The transaction will never propagate through the network at this point, and the funds will reside in... well... limbo?  If anybody feels like experimenting, I'd be very appreciative of any help to figure out how to retrieve the coins!

[CERN]

I fixed it!

For the curious, technically inclined:

The problem appears to be that when a transaction is created, the keys of the bitcoins being used are added to the transaction itself inside of the wallet.  Therefore, deleting the transaction in the raw db of wallet.dat will also delete the keys of the bitcoins that the transaction had allocated for itself!

I fixed this by using Sipa's fork of the Bitcoin client, which is a client modified in such a way as to detect and fix conflicts between a wallet's tx's and the blockchain.  However, I had to modify it for my purposes, since there really is no conflict -- the transaction is just the result of an unrelated bug

What I did was add an RPC command to revert a transaction using Sipa's functions:  all I did was call wtx.MarkConflicting(true), and then wtx.WriteToDisk() for my buggy transaction.  This gracefully did all the magic of removing the transaction from the wallet, as well as restoring the bitcoin keys to their original, un-tx'd selves

I am reading about more and more people who have the same problem as me, where sending the entire contents of a wallet results in placing the bitcoins in limbo for all eternity.  Sipa's got a good thing with his fork; I highly suggest to the powers that be that they merge it, as well as a debug RPC command to revert any transaction which has zero confirmations -- why not make it easier for people?

[joulesbeef]

is there a way to get a windows copyof this fork without doing the compiling yourself?

[jackjack]

I have the same problem (I left 0.007 BTC in my account though)
I don't know if it will fix that but I now have some hope

I looked at the files and:
1) current Sipa's fork doesn't contains MarkConflicting()
2) the commit you are linking to have many conflicts with newer code

So how did you manage to use Sipa's fork? Did you use his version of May 23rd?
Anyway, do you mind sharing the modified source you used as it would be easier?