Topic: Mac Bitcoin-Qt Transaction Bug (Read 878 times)

use symbolic links, they are insanely easy to use on a mac, and I use them for my wallet, to make sure it always backed up.

http://gigaom.com/2011/04/27/how-to-create-and-use-symlinks-on-a-mac/

While I am on the issue, what is the preferred way for using a single wallet across multiple machines?

It seems there is no easy way to avoid problems like this were coins end up in limbo unless you are very careful to backup every time you make a transaction and copy your wallet over each time.

At first I believed I was safe as long as my wallet didn't need to generate new addresses, but not I realize thats not good enough unless each machine is completely up to date with the blockchain.

I wish Bitcoin-Qt had a way where you could specify a different location for your wallet. Putting the whole directory on a USB drive isn't possibly because of the huge blockchain data files. There has got to be an easier way.

I'll try this. I suppose there is the possibility it is from double spent coins. I very rarely use another machine to send transactions but keep my wallets in sync using a USB drive. If one of the machines was not up to date with the blockchain and didn't have the newest wallet (even though they were essentially the same) I could see how it could try to double spend the same coins if it didn't realize they were already spent. It makes sense that that is the issue I've seen as I think I used a different machine for my last transaction and this one wasn't completely up to date. It would be nice if the client would cancel transactions that contained double spent coins instead of letting them sit there with all of the coins in the transaction unusable. Or at least there should be some way to manually cancel the transaction. Or at the very least, some indication of what is going on.

In the meantime I will look at the debug log and see what I can learn. Thanks.

I do not believe that I've heard of this being reported and there is nothing like it described on the issue tracker.

I completely believe that you may fail to broadcast initially if, for example, you transmit immediately after starting. But if your node is synced up you should be rebroadcasting with a random delay after every block that lacks your transaction. I'm quite sure that this has worked in the past but there is always a possibility of a bug.

Are you sure that you were not ending up with a double spent transaction in your wallet?— say from running the same private keys in another wallet? I ask this because it would have behavior like you described and be cured by doing what you describe, but is currently the expected behavior. In a double-spend case it will also still wedge some of your coins but it will be hopeless: the wallet will rebroadcast the conflicted transaction forever and the only way to recover any non-double-spent inputs will be to blow away the transaction just as you did. (This can be more easily done by backing up the wallet and then starting with salvage wallet).  But outside of a double spend this would be very unexpected.

Do you have a debug.log from a wallet running in this state?

If you get wedged again a debug log from the wallet running with debug=1 and logtimestamps=1 in the bitcoin.conf would be very useful.  If it is merely stuck needing a rebroadcast the transaction can be extracted by typing getrawtransaction in the debug console and then manually broadcast.

Every once in a while I send a transaction on my Mac with Bitcoin-Qt and the transaction just sits there and never gets broadcast out to the network. I'm not sure why this happens but it seems to happen more often if I send the transaction right away without letting the client sit for a little while first.

What happens is the transaction gets stuck in limbo. It never gets broadcast so it never gets confirmed. But my wallet thinks those coins have already been sent so the money is unspendable. It doesn't matter how many times I restart bitcoin-qt or wait (I've waited hours if not days), the transaction will sit there and never get broadcast.

The only solution I've found has been to delete my wallet and restore from a backup of the wallet that was made before the transaction. This is not an acceptable solution though as it is possible the old wallet may not include all the addresses the new wallet has and I could lose coins.

I suppose I could only try using pywallet although I haven't tried that yet.

In my opinion, this is a very serious bug and I don't understand why it has not been fixed yet. I've had this happen to me three times in the past couple of months and I've written posts here and on the technical discussion forum before.

Have others had this bug happen to them? I imagine it must be fairly common. Finally, how can I report this bug more directly to the developers so that it can get fixed.

In my opinion, any bug that causes you to lose coins without resorting to complicated wallet hacks (like pywallet) should be considered a very critical bug.