Bitcoin Forum

Since it was pointed out that I "clearly [didn't] understand" the forking situation after I made reference to the idea that lots of people might lose money due to reversed transactions, I'd like to know if something similar happened to you yesterday.

I was running my Bitcoin client and Armory together when I learned about the fork.  After I received word of the "all clear," I sent a small test transaction from one wallet to another.  After I sent the funds, my wallet indicated that the funds had left, but I received no confirmation that my other wallet had received the transaction.  Within seconds, Armory told me it was no longer synced to my Bitcoin client, and within a few minutes after that, Armory crashed.

I quit my client and Armory and rebooted both of them and let them both resync.  After the resync, my BTC balance returned to what it was prior to the test transaction as if I had never sent it to begin with.  I checked blockchain, and there was no record of the test transaction despite my client indicating that the transaction had cleared.

So, wtf?  How did this happen?

Sounds like you were on the dead chain still?

I was running Bitcoin 0.8.

What you are describing is not a "reversed transaction" but simply a transaction that apparently never got broadcast.

The Bitcoin-Qt/bitcoind client does not send out a spend transaction until it has reached sync.  So it could have been perfectly bad timing where just before when your transaction was communicated to bitcoind (which is what Armory uses underneath I believe), that client discovered a block at a greater height and did not send the transaction. 

Now when the client is restarted it does not automatically re-broadcast a transaction.  The bitcoind needs to remain running, sometimes a half hour or (or longer maybe) for any transactions to get re-broadcast.

So, at this point -- make sure you've left everything running for a long enough period to make sure no spend transaction is just waiting to get re-broadcast.

If that doesn't change anything then I'm pretty much out of suggestions.  If the Bitcoin network doesn't know of your transaction (e.g., blockchain.info doesn't have any knowledge of it) and your client isn't re-broadcasting it then either the transaction was invalid and no peers will relay it or it somehow never got saved. 

The bitcoind wallet uses BDB so I suppose if that got taken down with a crash and the database wasn't closed that a rollback in the local BDB wallet.dat database could have occurred to the point it was at prior to you sending the payment.

If this is to an address in your own wallet, there's nothing really to worry about if the transaction were somehow later be re-broadcast.  If it was to some other party, one way of ensuring that the lost transaction becomes moot is to spend those coins with a new transaction.  So if your wallet has 1.123456 BTC, send a payment to an address you control with all 1.123456  (less transaction fee) so that even if that missing transaction were somehow to resurface at some later time it would not be a valid transaction (as you've since re-spent those funds).

Semantics.  Reversed is a good enough word to describe it because the funds appeared to actually leave the wallet as indicated by a decreased balance and a transaction listing on my sending client showing 0 confirmations.  When the client rebooted, that transaction was no longer listed in my client and the "sent" Bitcoins were still there.  Although it apparently was never broadcast to the network, my client initially acted as though it had been broadcast.


It seems that "somehow [the transaction] never got saved" appears to be what happened.  I can't think of any reason why no peers would relay it.

But the software version of what? It is the miner who creates the block, and some miners (for instance deepbit) run on 0.3.x.

Sounds like Armory crashed before broadcasting the transaction. It's not a reversed transaction in all likelyhood- it just failed to broadcast in the first place.