Cant send coins

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start 2.18 Bitcoin Wallet. 
2. Establish several peers and download blockchain.
3. Attempt to send coins.
4. Fail.
5. Phone shows pending, blockchain.info and recipient never see transaction.

Original issue reported on code.google.com by imsa...@gmail.com on 11 Jul 2012 at 10:45

[GoogleCodeExporter]

Before producing this bug, has there been an unconfirmed outgoing transaction 
in your wallet?

What do you mean by "4. Fail."? Is there a message appearing? Can you send your 
logfile (aLogcat)?

Original comment by andreas....@gmail.com on 12 Jul 2012 at 1:01

[GoogleCodeExporter]

4. Fail means it doesn't send the coins.  No error, no anything.  It goes grey 
like its transmitted, but it hasn't.  I went so far as to restore to the 
previous night's backup to revert the pending transactoin, connect my wallet as 
a trusted peer (yes, I know about restarting after changing the setting) 
directly to my own bitcoind, and sending to one of its addresses.  My bitcoind 
never shows the transaction.  Essentially, the transaction is never transmitted.

Original comment by imsa...@gmail.com on 12 Jul 2012 at 2:58

[GoogleCodeExporter]

Oh, there weren't any pending transactions either way before this bug. 

Original comment by imsa...@gmail.com on 12 Jul 2012 at 2:59

[GoogleCodeExporter]

Ok, so now you have one pending outgoing tx in your wallet, and it has a proper 
fee attached to it, right?

Would you try to connect your phone to "adb" and view the logfile (adb logcat)? 
Let the app connect to your trusted peer while looking at the logfile. It 
should immediately (re-)transmit the pending transaction (watch for "...Sending 
transaction..."). Does this happen?

FYI: You can look at the transaction details by enabling in Preferences->Labs 
and then clicking on the tx and selecting "Details" from the overflow menu.

Original comment by andreas....@gmail.com on 12 Jul 2012 at 3:10

• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

There's no fee.  It has input of 34 btc from days ago, it should have enough of 
a priority that a fee isn't required. I'm sending you a copy of the logcat from 
the startup.

Original comment by imsa...@gmail.com on 12 Jul 2012 at 3:22

[GoogleCodeExporter]

Your logcat contains the line

W/System.err( 4878): 44976308 [PeerGroup-5-thread-1] INFO com.google.bitcoin.cor
e.PeerGroup - [192.168.2.102]:8333: Announcing 1 pending wallet transactions

That should send an "inv" to your trusted peer. Look at your trusted peers 
logfile to see what it does with that inv. Most probably it already knows about 
the tx (so it will not request again) and will drop it because of no fee.

(I was wrong about the "Sending transaction" line, that's only logged the 
moment you send)

Original comment by andreas....@gmail.com on 12 Jul 2012 at 3:32

[GoogleCodeExporter]

So a 50 btc tx with 4 inputs ranging from 5 to 35 btc require a mandatory fee?  
How is that spam like?

Original comment by imsa...@gmail.com on 12 Jul 2012 at 3:40

[GoogleCodeExporter]

https://en.bitcoin.it/wiki/Free_transaction_relay_policy

Try adding that node as a trusted peer until your tx is confirmed. Don't forget 
to remove that trusted peer from your config afterwards. Let us know if this 
helped.

Original comment by andreas....@gmail.com on 12 Jul 2012 at 3:48

[GoogleCodeExporter]

I take it the origin problem has been solved.

Original comment by andreas....@gmail.com on 13 Jul 2012 at 8:23

• Changed state: Invalid

[GoogleCodeExporter]

I have the same problem and none of the above solutions made any transaction go 
out. Resetting the transaction history gives me back my coins though... but 
they remain stuck in the phone. I am using a Samsung Galaxy Mini GT-S5570. 
Android 2.3.5 (updated yesterday). It's a cheap phone not having much RAM or 
internal Flash. The bitcoin client is frequently crashing.

Connecting it directly to the recipient via "trusted peer" leads to the 
following lines in debug.log (192.168.1.5 is the Android phone):

accepted connection 192.168.1.5:41334
askfor tx 0e33f7377b9636d1d559   0
sending getdata: tx 0e33f7377b9636d1d559
askfor tx 0e33f7377b9636d1d559   1343458118000000
askfor tx 0e33f7377b9636d1d559   1343458238000000
addUnchecked(): size 170
CTxMemPool::accept() : accepted 0e33f7377b
Added time data, samples 10, offset -43 (+0 minutes)
version message: version 31800, blocks=191163
getblocks -1 to 00000000000000000000 limit 500
askfor tx 8dfaa5ce1d493f81a576   0
askfor tx f9a3516ad6258ab08514   0
askfor tx fb27f32459ab6665e2a5   0
sending getdata: tx 8dfaa5ce1d493f81a576
sending getdata: tx f9a3516ad6258ab08514
sending getdata: tx fb27f32459ab6665e2a5
Added 1 addresses from 85.114.7.70: 397 tried, 12089 new
ERROR: ConnectInputs() : f9a3516ad6 VerifySignature failed
ERROR: CTxMemPool::accept() : ConnectInputs failed f9a3516ad6
disconnecting node 192.168.1.5:41334
Disconnected 192.168.1.5:41334 for misbehavior (score=100)
connection from 192.168.1.5:56945 dropped (banned)
askfor tx d29ea1f2c78224cf1b0f   0
sending getdata: tx d29ea1f2c78224cf1b0f
connection from 192.168.1.5:55476 dropped (banned)
addUnchecked(): size 171
CTxMemPool::accept() : accepted d29ea1f2c7
connection from 192.168.1.5:41635 dropped (banned)

Original comment by ist.das....@gmail.com on 28 Jul 2012 at 7:06

[GoogleCodeExporter]

Thanks for reporting this. I took your report about the failed signatures to 
BitCoinJ, see this issue:

http://code.google.com/p/bitcoinj/issues/detail?id=239

When you say the client is frequently crashing on your phone, what's the 
exception? Did you mail error reports?

Original comment by andreas....@gmail.com on 30 Jul 2012 at 9:11

[GoogleCodeExporter]

You said "I am using a Samsung Galaxy Mini GT-S5570. Android 2.3.5 (updated 
yesterday)."

Do you mean you updated the phones operating system? What version of Android 
were you on previously? When did you create that transaction?

The failure you're seeing suggests the transaction was created on an earlier 
version of Android that is known to be buggy.

Original comment by hearn@google.com on 30 Jul 2012 at 9:17

[GoogleCodeExporter]

All transactions are made 07/27/2012. After updating the phone's firmware using 
Samsung kies. The problem happened before updating too but I did reset the 
whole blockchain and updated Android aftwerwards to try the same thing again 
with the new Android version.

Unfortunately I can't tell you right away what Android version it hat before 
updating. Maybe it can bee looked up somewhere; I might be able to say 
something more (if still needed) when I am back home and able to look into kies.

Original comment by ist.das....@gmail.com on 30 Jul 2012 at 9:29

[GoogleCodeExporter]

To answer Comment 11: I did mail some error reports through K9 (2 at least) and 
a dozen reports through the reporting system (where I have no idea where those 
reports are ending).

I am a developer, but I don't do Android so I didn't put that much effort into 
finding out what it's internally doing. From my general experience I wouldn't 
be surprised if it was mainly a memory issue or something similar.

Regards
   Peter Guhl (now you should know which of the mail reports are mine ;)

Original comment by ist.das....@gmail.com on 30 Jul 2012 at 9:33

[GoogleCodeExporter]

I looked through your crash reports; none of those is memory related. Two 
month-old reports should be fixed by now, and the last one (filed on 27/7) is a 
bug in BitCoinJ still trying to write to a closed block store.

Your "memory class" is 64, which is not that bad.

If the app crashes in future, feel free to alway report using the crash 
reporter. The market reporting is not very useful for individual analysis.

According to
http://www.gsmarena.com/samsung_galaxy_mini_s5570-3725.php
your phone was originally released with Froyo.

Original comment by andreas....@gmail.com on 30 Jul 2012 at 9:56

[GoogleCodeExporter]

So Froyo is 2.2 which is the one having the hash calculation bug... well, the 
debug-log definitely is from after upgrading to 2.3. But the transactions are 
still stuck. I'll probably give it another try with resetting the blockchain. 
In a few days, when the phone did again catch up the 52 weeks, I'll try to do 
another transaction.

The original idea was to transfer the coins *before* updating the Firmware.

Original comment by ist.das....@gmail.com on 30 Jul 2012 at 10:14

[GoogleCodeExporter]

BTW: A common behaviour of my bitcoint client is to report "Blockchain 
blockiert" for half a day and more even though the phone is online.

Original comment by ist.das....@gmail.com on 30 Jul 2012 at 10:15

[GoogleCodeExporter]

Oh... and another BTW: When I got the question if I want to report using e-Mail 
normally it was after a couple of crashes only bringing up the market crash 
reporter. So it's quite possible those errors in the mails only refer to stuff 
happening because a half-crashed process was still locking some files etc.

Original comment by ist.das....@gmail.com on 30 Jul 2012 at 10:19

[GoogleCodeExporter]

Its important to know when you *created* the tx and not when you've been trying 
to re-send. If that was with Android 2.2, we are most likely dealing with the 
known BigInteger problem.

You can look at "adb logcat" to see what your phone is doing if it is trying to 
update the blockchain.

Original comment by andreas....@gmail.com on 30 Jul 2012 at 10:22

[GoogleCodeExporter]

Currently I have not the slightest idea what adb logcat is. My phone isn't 
rooted or something... to play around I bought a Nokia N900 (didn't find a 
bitcoin wallet for maemo yet though... if I had found one I would be using it).

I am 90% sure that at least some of the transactions have been created after 
the update. Well, 10% unsure can be quite a lot. Therefore I did reset the 
blockchain now and will create new transactions as soon as the phone has been 
catching up. That will make it 100% sure and eliminate some things which might 
be connected to the fact that the blockchain was loaded using the older version 
of Android.

I'll let you know here if this did fix the problem or not.

Original comment by ist.das....@gmail.com on 30 Jul 2012 at 11:16

[GoogleCodeExporter]

OK, I have to admit my memory wasn't very accurate. Now I can send coins. After 
updating Android from 2.2 to 2.3 and resetting the blockchain to get rid of all 
transactions still stuck.

The strategy to send the coins to my PC using Android 2.2 to make sure they 
don't get lost if the Update to 2.3 bricks the phone turned out to be a good 
idea in theory... but only in theory.

It may be that having transaction created with 2.2 *and* some with 2.3 makes 
them all get stuck but that's not entirely sure. But it definitely was the 
BigInteger problem causing all the trouble I had.

Sorry for bothering you then. And many thanks for your help! For me the 
discussion was very helpful since I was neither aware that my phone really was 
one with the BigInteger problem nor that the *creation* of the transaction is 
causing the trouble since it is and stays to be a broken one nobody accepts; no 
matter how I send it out.

Reloading 52 weeks of blockchain was much faster now than it was before when I 
still had Android 2.2. And there was no crashing! Could it be that the 
BigInteger-Stuff did affect loading the blockchain too? Causing peers to ban me 
etc.? Or did 2.2 just have a couple of other bugs affecting it's stability and 
reliability in general?

Anyway; problem solved, I'd say.

Regards
   Peter

Original comment by ist.das....@gmail.com on 31 Jul 2012 at 6:05