Missing transaction because of "bitcoinj does not seem to care"

[GoogleCodeExporter]

Here is an uncommon case of a missing transaction. The user gets this pending 
transaction, and its his address:

https://blockchain.info/tx/87000ffea0db0f9539a90054bd0189351eae517a0c95306f75dc9
9637f5ab348

According to the log, he gets the tx announced but the wallet doesn't do 
anything. See full log in the attachment, but here is the line:

16:43:04.402 [NioClientManager] MemoryPool - [88.152.60.25]:8333: Peer 
announced new transaction [1] 
87000ffea0db0f9539a90054bd0189351eae517a0c95306f75dc99637f5ab348
16:44:00.059 ......

His address is 1CK6x8Am2QXVzePg5N7HGWYZE6aL3SMkva

bitcoinj 0.11.3

Original issue reported on code.google.com by andreas....@gmail.com on 18 Jul 2014 at 1:36

Attachments:

• wallet.-345734033.log

[GoogleCodeExporter]

Seems like the remote node didn't respond to a getdata, perhaps? Not sure what 
could cause that other than a broken remote peer.

Original comment by mh.in.en...@gmail.com on 18 Jul 2014 at 3:34

[GoogleCodeExporter]

How can we deal with this? Sooner or later, there will be all sorts of broken 
peers (intentionally or not).

Original comment by andreas....@gmail.com on 18 Jul 2014 at 3:55

[GoogleCodeExporter]

I think a good first step would be to log a warning if a peer doesn't respond 
to a getdata within a reasonable timeout.

Original comment by andreas....@gmail.com on 18 Jul 2014 at 3:57

[GoogleCodeExporter]

Yes, obviously, the right fix is to timeout and retry on another peer.

The types of peer breakage bitcoinj is currently written to handle are limited. 
Basically it assumes that a peer might be deliberately tampered with for some 
kind of evil end and tries to mitigate where possible, but arbitrary pointless 
brokenness isn't dealt with.

Let's wait and see how often this comes up. It should have been fixed once the 
user restarted the app or the tx got confirmed anyway.

Original comment by mh.in.en...@gmail.com on 18 Jul 2014 at 4:01

[GoogleCodeExporter]

Actually no, the issue wasn't fixed for the user when the tx was confirmed.

In order to see how often this comes up, we'd need that log message. It's 
painful, if not impossible, to grep for missing messages...

Original comment by andreas....@gmail.com on 18 Jul 2014 at 4:11

[GoogleCodeExporter]

Then I think the issue must lie elsewhere, and is not that getdata timed out. I 
notice that a reject message was sent later on, but unfortunately support for 
printing them is only in git master. Will have a think about it.

Original comment by mh.in.en...@gmail.com on 18 Jul 2014 at 4:29

[GoogleCodeExporter]

I've also had this happen twice in the last month- the log reports a 
transaction but my listener functions aren't called. I was using bitcoinj 11.2 
a wallet with 15k addresses and several hundred transactions. I upgraded to 
11.3 and started a new wallet and haven't seen this since (yet).

Let me know what other debugging data I can get you next time this happens.

Original comment by yayits...@gmail.com on 19 Jul 2014 at 3:10

[GoogleCodeExporter]

There were bug fixes in 0.11.3 that resolved cases where transactions would get 
incorrectly dropped. So I suspect that's a different issue.

Original comment by mh.in.en...@gmail.com on 19 Jul 2014 at 3:25