Lost BTC

[RocketSocks]

I was getting my BTC wallet set up on Tails using Electrum when I decided to do a test transfer of 0.01BTC. I sent it from Multibit, but in the transaction history, the transaction has not been confirmed and only seen by one peer... for the last 8 hours. Now, that's ok. 0.01BTC is no big loss. However, Multibit is telling me that my balance is 0.435248 (my actual balance) and my AVAILABLE balance is only 0.097642. Somehow, in my test transfer of .01 I lost 0.337624. ... Looking around, I see in the transaction details (Raw Transaction section) 2 lines of info. The first is the amount I sent. The second is the amount I lost.

I also looked up the transaction on blockexplorer.com which just says "No such transaction".

Update: Looking around for a method of fixing this, I came across a suggestion to reset the blockchain (found here: https://multibit.org/en/help/v0.5/help_support_sentBitcoinFromMultibitButTheyAreStuck.html). Now even the bad transaction is gone. My balance is now .097642. My money better not have simply vanished. That's a $50 loss from out of nowhere.

Please, please respond to me. I need my money back.
drpudding@hushmail.com

[jim618]

You've got a few points/ questions.

The 'seen by one peer' is normally caused by a peer dropping out or network problems. It indicates the signed transaction has not been sent out to the Bitcon network successfully.
If you have a read of :
https://multibit.org/en/help/v0.5/help_availableToSpend.html
(Spendable and available to spend mean the same).

When you do a reset transactions multibit syncs the transactions for your wallet's addresses to what is in the blockchain.

The 'second amount' you mention in the transaction window is the transaction change. If you are not familiar with this concept, have a read of : https://en.bitcoin.it/wiki/Change

I'm not terribly familiar with Tails but if you are running MultiBit on it and using a RAM disk you have to be VERY CAREFUL you don't inadvertently delete your multibit wallet and the automatically generated backups.

From your description I cannot tell 100% but what may have happened is:

1. you install multibit
2. when you start multibit for the first time it generates a wallet for you called multibit.wallet and saves this in your user data area. (You can see where this is by looking in the Messages tab when you start up - it is logged on the first line). You also get backups written in the multibit-data directory. This is also in the user data directory.
3. you send some money to the wallet generated in 2.
4. after the bitcoin confirms, you send some bitcoin to your electrum wallet, and the remainder is sent as change to the address in the multibit.wallet.
5. If your Tails installation automatically deletes user generated files (the whole 'Leave no trace' ethos) it may very well have deleted the wallet with the change address private keys AND all the wallet backups.

Then if you start multibit again it sees that it has no wallet (as it has just been deleted by Tails) and creates another one. This new wallet has a different address in.

This is only a scenario as I don't know exactly what your set up is.
To recover your bitcoin you need the wallet that has the private keys in for the change address for your transaction you sent to electrum.

[RocketSocks]

This all happened on Multibit 0.5.13 running on Windows 7 SP1 64bit. My wallet file is well and truly backed up. I've got it loaded up right now and there isn't even a record of the transaction in the client anymore after I reset the blockchain. All I have is the screenshot I posted.

The Tails OS and Eletrum wallet (which I was trying to migrate to) never got a hint of that transaction from what I can tell. I'm not fully convinced Electrum is the best client to use at this point. It seems a bit under-cooked. Still, is there any chance it could have messed up this transaction on the receiving end?

[jim618]

If you get that 'seen by one peer' it normally means that the transaction did not make it to the peer MultiBit was sending to, or that the transaction was not then propagated on.

In that case Electrum probably would not see it (and that that would be expected behaviour).

Also, make sure you do a reset blockchain and transactions right from the first transaction (the first checkbox on the reset blockchain page) to make sure it syncs the whole wallet.

[RocketSocks]

I did a blockchain reset going back a couple days before the bad transaction. Since then I've done a reset from the first transaction. Still no sign of the bad transaction or the BTC.

[jim618]

You might want to have a look at the automatic backups that are created to find the wallet with the private key for the change address in your OP. If you look in the help in 'File Descriptions' it describes what is available.

[RocketSocks]

I've loaded a number of backup files, but they all give me the same result. No sign of the vanished transaction.

I've noticed something else that might steer this little investigation in a different direction. I went through all my past transactions and manually did all the add/subtract math to see if my current balance reflects them accurately, and it does. I don't think there are any other missing transaction (to the best of my memory). So now I'm wondering if the error (prior to the bad transaction) could have been in my overall balance statement. Perhaps I actually didn't have as much as it said and the history didn't add up before that transaction. Has that error ever occurred before?

[jim618]

Hi RocketSocks,
In Bitcoin there is a 'sliding scale' of how much confidence you can have in any particular transaction:

1. Is it sent to a single bitcoind node ok
2. Has it propagated across the network / has it been seen by several nodes ?
3. Is it confirmed a single time ?
4. Is it confirmed several times (i.e say 2 or 3) ?
5. Is it confirmed lots of times (e.g. over 100)

At any point in the above a transaction can have problems (they get less likely as you go down the list).
That is the main reason you have two balances "Balance" is how much you have if every transaction is perfect, "Spendable" is how much is fully available now.

This is part and parcel of how bitcoin works and so is worth learning about if you are not familiar with it.

It sounds like your manual crosschecking against the transactions in MultiBit and on the blockchain all match so I think I can close this now.

[ssadler]

Might want to re-open this, it just happened to me. It went something like this. Let's say I have keys A (0.9 btc) and B (0.1 btc). I try to send 0.05 BTC which the client takes from B, and it sends the change to A, but the transaction never gets confirmed. I try it again, and this time it takes, however I need to reset the blockchain and transactions in order to get back the balance associated with the pending/unconfirmed transaction. Plus, now my balance is showing that I have 0.05 spendable btc (I think). I do the reset, and once it finishes, it shows 0 for my actual balance. Obviously freak out... Export private keys and luckily the balance is there.

[fwends]

This has just happened to me, sent a transaction out and it was in the transaction list with 1 peer.
Waited and waited and nothing happened so i reset the block chain, the transaction vanished from history and the funds are no where to be seen!.

[ssadler]

fwends: export your keys in multibit, they should be there. i used bitaddress.org to get the qr code from the key, then mycelium / other app to sweep the balance.

[gary-rowe]

Do the following:

1. identify the first transaction you made in MultiBit in the transactions view
2. note the date then take off a day (e.g. 2013-01-02 becomes 2013-01-01)
3. use Reset transactions from Tools using that date (e.g. 2013-01-01)

MultiBit will then resynch and rebalance as required.

[fwends]

@gary-rowe Tried all that it does not work, i did what @ssadler said and that worked. To me looks like multibit has issues sending.

[ssadler]

@fwends: looks like you got dumped into the deep end there! Well done tho...

[ComplicateSimplify]

Having the same situation. My wallet appears empty but I can find it under transactions that it is "received". I have reset the Blockchain but it hasn't worked. I am trying to withdraw the money from blockchain to another account but it keeps telling me, 'Insufficient funds'.
Can anyone help me with this issue?

[ComplicateSimplify]

Never mind, problem has been solved. Thanks again though.

[hughht5]

Hi

I had a similar but different issue: I sent 0.35BTC to a customer and it got stuck with 'seen by only 1 peer'. I reset the transactions and blockchain and the transaction disappeared and my balance was there.

3 hours later I sent 0.35BTC again to the same customer. That got confirmed. An hour later, my first transaction rocks up on the network as is also confirmed.

This means I've sent 0.7 not 0.35BTC. Client can't send it back because he donated directly to a charity. I like that charity, but I am still out of pocket.

My question is this: can a miner not propagate transactions, then decide to send them on hours, perhaps days later?

[jim618]

In theory the random chosen peer you connected to could hold onto your transaction and send it later yes. This would obviously be very non-standard behaviour.

For the scenario you outlined to work you would also have to created a new transaction that happened to not reuse any of the unspent outputs consumed in the first transaction (as then one transaction would be double spending part of the other and hence would not get on a block.)

You could always explain to the final recipient of the money - the charity - what happened and ask for the erroneous send back.
When people accidentally send bitcoins to the wrong address (which happens rarely, but does happen) if they can identify the recipient address most of the time the recipient sends it back.

[hughht5]

I support the charity in question so I'll just leave it this time round. There are a few edge cases though like this that I think need sorting out before bitcoin is widely adopted.

Would it not be more sensible for multibit to broadcast to 2 peers from the start, and monitor the others? rather than broadcast to only 1? It would solve this edge case.