"broadcastTransaction: TX xxx seen by 1 peers", but tx not sent

[GoogleCodeExporter]

It may be just a coincidence, but today I've had two users complaining their 
transactions do not confirm. New Bitcoin Wallet version using bitcoinj 0.10.2.

In both cases, the log claims several dozend times the tx has been seen by one 
peer, but blockchain.info does not know about the tx. I validated the tx from 
this example manually and IMHO it looks ok and should be confirmed.

See attached log and pending tx in the wallet dump.

Original issue reported on code.google.com by andreas....@gmail.com on 26 Oct 2013 at 9:07

Attachments:

• wallet.-732974680.log
• wallet-dump.-727496369.txt

[GoogleCodeExporter]

OK. Then I think we have the same issue as on the mailing list, where some 
(bad?) p2p node is rejecting or ignoring the transaction for some reason and so 
it never gets a chance to propagate. And we don't notice and do something 
intelligent because the stupid p2p protocol has no error message (yet), and 
there are no timeouts that trigger retries.

If this is indeed a real problem on the main network then the change to not 
announce transactions to all new peers could have made it worse, as there are 
fewer chances for the tx to become broadcast to lots of peers.

Once there's a real P2P error message, all this should get a lot simpler.

Were these users using the Bluetooth support?

I've added logging of the confidence change reason in the broadcast confidence 
listener. You could help avoid problems by NOT using sendCoinsOffline in your 
app but rather just using the normal sendCoins. That way, the transaction would 
only be committed to the wallet if it was seen propagating across the network. 
If it never propagated, it'd be as if the spend didn't happen and the user 
could try again themselves.

Original comment by hearn@google.com on 27 Oct 2013 at 2:37

[GoogleCodeExporter]

Actually I suspect this issue is probably more general than just one bad 
behaving node. If you look at the logs, it tried to send to many different 
nodes over a timeframe of at least 3 hours.

He wasn't using Bluetooth. He signed the tx himself. I'll add the earlier log 
when he initiated the payment.

sendCoinsOffline vs. sendCoins: It would be very destructive to the user 
experience if outgoing transactions would go missing just because there is some 
network issue. If you really think we need an "uncommitted" state, I suggest 
adding a new pool where I can immediately persist transactions to.

I'll watch the issue more closely and keep adding to it. Today, no such bug was 
reported so I still hope its not a regression at least.

Original comment by andreas....@gmail.com on 27 Oct 2013 at 4:06

[GoogleCodeExporter]

Original comment by andreas....@gmail.com on 27 Oct 2013 at 4:07

Attachments:

• wallet.2013-10-25.-1434362903.log

[GoogleCodeExporter]

I have now set up a bitcoind that can be reached by public ip. I instructed the 
users bitten by this problem to set my node as a trusted peer.

A first observation: It looks like the transaction is indeed not sent. I cannot 
find the txid in the debug.log. Unfortunately, after the quick test the user 
got impatient and reset his blockchain (the bitcoind setup already took 2 days).

I'm waiting for feedback of the other users.

Original comment by andreas....@gmail.com on 29 Oct 2013 at 12:28

[GoogleCodeExporter]

The next user claimed he broadcasted his tx to my node for 30 minutes, but I 
don't see his txid in my log.

It looks like those transactions are not being sent currently.

Original comment by andreas....@gmail.com on 29 Oct 2013 at 4:48

[GoogleCodeExporter]

Well I ideally needs logs from both a user and the bitcoind side. If you see 
the "adding to memory pool and sending" then pretty much the next thing that is 
supposed to happen (after attaching a confidence listener) is the message 
hitting the wire and that is supposed to yield a message in the debug.log file 
if the tx wasn't already seen before. So if you don't see any reference to the 
tx hash at all .... hmm. There isn't a lot of wiggle room for things to go 
wrong there. I don't know of any reason a message would simply vanish like 
that, so this is puzzling.

At any rate, I'll change the broadcast algorithm to always broadcast to half 
the peers, or something like that.

Original comment by mh.in.en...@gmail.com on 30 Oct 2013 at 10:45

[GoogleCodeExporter]

The bitcoind side does not have a trace of that tx, which is why I did not 
attach the log and mentioned the fact instead.

Original comment by andreas....@gmail.com on 30 Oct 2013 at 10:59

[GoogleCodeExporter]

For the affected people, reverting f867998c52719e38213176b2616438b50a2d8b89 
fixes the issue.

Original comment by andreas....@gmail.com on 3 Nov 2013 at 7:15

[GoogleCodeExporter]

Original comment by mh.in.en...@gmail.com on 24 Nov 2013 at 11:12

• Changed state: Fixed

[GoogleCodeExporter]

I am seeing this too on a head revision as of 23rd Sept so before the above 
commit (f0b258b40dde6e7723ea429a10ae0cd51cfc7972).

Although symptom is the same - repeated "seen by 1 peers", my case cleared 
itself after about 12 hours. Although was just after I disconnected from 3 
peers - so could be that disconnect cleared it?

Original comment by murexcon...@googlemail.com on 25 Nov 2013 at 7:31

[GoogleCodeExporter]

You're over a month out of date. The bug tracker tracks the status of git 
master, not anything else.

Original comment by hearn@google.com on 26 Nov 2013 at 9:26