transaction not being broadcasted

[Jakub Suder]

I have a transaction that I sent (or so I thought) 10 days ago from Hive. I've started Hive many times since then, and the transaction is still pending. I've checked the stats and it seems the number of peers that have received it (numBroadcastPeers()) is 0.

What is going on?

On startup I get something like this:

2014-08-21 07:49:54 +0000 [Wallet setTransactionBroadcaster] (Wallet.java:3699)

INFO: New broadcaster so uploading waiting tx 3ea4a44cf02efc9b3bf27259b0f62175cf1a77e727106846576070abeaf6ad3c

2014-08-21 07:49:54 +0000 [TransactionBroadcast broadcast] (TransactionBroadcast.java:67)

INFO: Waiting for 2 peers required for broadcast ...

2014-08-21 07:49:54 +0000 [PeerGroup recalculateFastCatchupAndFilter] (PeerGroup.java:789)

INFO: Recalculating filter in mode SEND_IF_CHANGED

...

2014-08-21 07:50:01 +0000 [PeerGroup setDownloadPeer] (PeerGroup.java:1065)

INFO: Setting download peer: [59.127.51.243]:8333

...

2014-08-21 07:50:02 +0000 [TransactionBroadcast$EnoughAvailablePeers run] (TransactionBroadcast.java:104)

INFO: broadcastTransaction: We have 2 peers, adding 3ea4a44cf02efc9b3bf27259b0f62175cf1a77e727106846576070abeaf6ad3c to the memory pool and sending to 1 peers, will wait for 1: [59.127.51.243]:8333

...

2014-08-21 07:50:03 +0000 [PeerGroup setDownloadPeer] (PeerGroup.java:1058)

INFO: Unsetting download peer: [59.127.51.243]:8333

2014-08-21 07:50:03 +0000 [PeerGroup setDownloadPeer] (PeerGroup.java:1065)

INFO: Setting download peer: [131.155.102.182]:8333

What does this mean? Are they rejecting the transaction, or is bitcoinj unable to broadcast it properly for some reason?

One detail that might be important: this is a very small transaction, sending just 100 bits with the standard 100 bits fee (200 total).

Also: I've just tried to send another with 500 bits, it got broadcasted immediately and confirmed in about 10 minutes. The previous one is still waiting.

Kuba

[Andreas Schildbach]

If Hive didn't change anything compared to upstream Bitcoin Wallet, this
means that none of your peers have echoed this transaction back. This
can have two causes:

1) You have never been connected to peer. Go to the network manager and
see if it connects. While you're there, is the block chain up to date?

2) You're connected but peers reject your transaction. Until recently,
there was no dedicated "reject message" in the P2P network. Now there
is, and we should implement it in bitcoinj. To debug this case, set up a
trusted peer to a full node your run yourself, with debug logging
enabled. Make the app connect to your node and read the error messages
in the log. You can use my node 85.10.195.44 if you want. Tell me the
time you connected and the transaction ID and I'll look it up for you.

> --
> You received this message because you are subscribed to the Google
> Groups "bitcoinj" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to bitcoinj+u...@googlegroups.com
> <mailto:bitcoinj+u...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Kuba Suder]

Well, I am connected to the network, because I’ve been able to send another transaction and it was confirmed.

I’m only wondering about that "Unsetting download peer” - could this mean that I’m first connecting to one peer, same one every time, broadcasting that transaction to them, and then immediately disconnecting, reconnecting to another, but not rebroadcasting the waiting transaction again?

Kuba

You received this message because you are subscribed to a topic in the Google Groups "bitcoinj" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoinj/j3u-lIDSAaM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoinj+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
Kuba

[Andreas Schildbach]

On 08/21/2014 11:50 AM, Kuba Suder wrote:

> Well, I am connected to the network, because I’ve been able to send
> another transaction and it was confirmed.

If you don't follow instructions I can't help you. Transactions can be
send in multiple ways, not only via the P2P network.

> I’m only wondering about that "Unsetting download peer” - could this
> mean that I’m first connecting to one peer, same one every time,
> broadcasting that transaction to them, and then immediately
> disconnecting, reconnecting to another, but not rebroadcasting the
> waiting transaction again?

Setting a trusted peer is just an intermediate measure to debug things.
If you're finished, you should clear the trusted peer from your preferences.

> On 21 Aug 2014 at 11:42:41, Andreas Schildbach (and...@schildbach.de

[Kuba Suder]

> Well, I am connected to the network, because I’ve been able to send 
> another transaction and it was confirmed. 

If you don't follow instructions I can't help you. Transactions can be 
send in multiple ways, not only via the P2P network. 

Wait, so how else does bitcoinj send transactions (by default)?… (excluding BIP70, that’s not the case here, I've sent a normal transaction to my other address)

Kuba

[Mike Hearn]

One detail that might be important: this is a very small transaction, sending just 100 bits with the standard 100 bits fee (200 total).

Also: I've just tried to send another with 500 bits, it got broadcasted immediately and confirmed in about 10 minutes. The previous one is still waiting.

What is a "bit"? Perhaps your previous transaction was dust?

bcj 0.12 prints reject messages to the log so you can see if your tx failed to relay due to an explicit rejection by the peers. However 0.11.3 does not. 

[Kuba Suder]

What is a "bit"? Perhaps your previous transaction was dust?

A different name for uBTC, more and more wallets are switching to that, and we’ve recently changed that in Hive too.

The transaction is spending a 49.8 mBTC output from a transaction confirmed back in June, sending 49.6 mBTC back as change, 0.1 mBTC to the recipient, and leaving 0.1 mBTC as a fee.

Kuba

[Jakub Suder]

Hi,

I've finally got around to checking that. I've connected to my fully synced peer on another computer, but I don't see anything interesting in the logs. I get a "receive version message: /BitCoinJ:0.11.3/BitcoinJKit:0.9/", and then nothing. There are some "inputs already spend" that appear later, but I assume these aren't mine, they appear every couple of minutes anyway.

I've also tried your peer 85.10.195.44, could you check the logs? Timestamp around 2014-11-10 17:11 to 17:13 +0000, my IP is 89.66.140.241.

Kuba

[Andreas Schildbach]

I see these lines, its indeed not very helpful:

2014-11-10 17:11:37 receive version message:
/BitCoinJ:0.11.3/BitcoinJKit:0.9/: version 70001, blocks=329436,
us=127.0.0.1:8333, them=127.0.0.1:8333, pe
er=89.66.140.241:49855
2014-11-10 17:11:37 Added time data, samples 200, offset +9 (+0 minutes)
2014-11-10 17:11:38 ERROR: AcceptToMemoryPool : inputs already spent
2014-11-10 17:11:42 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:11:42 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:11:43 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:11:45 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:11:45 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:11:46 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:11:46 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:11:47 ERROR: AcceptToMemoryPool : inputs already spent
2014-11-10 17:11:49 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:11:49 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:11:50 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:11:50 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:11:51 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:11:53 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:11:53 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:11:54 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:11:54 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:11:55 ERROR: AcceptToMemoryPool : nonstandard transaction:
dust
2014-11-10 17:12:26 receive version message:
/BitCoinJ:0.11.3/BitcoinJKit:0.9/: version 70001, blocks=329436,
us=127.0.0.1:8333, them=127.0.0.1:8333, peer=89.66.140.241:49877
2014-11-10 17:12:32 receive version message: /Satoshi:0.9.2.1/: version
70002, blocks=329436, us=85.10.195.44:8333, them=24.59.241.65:8333,
peer=24.59.241.65:51398
2014-11-10 17:12:32 Added time data, samples 200, offset +9 (+0 minutes)

I wonder why bitcoin core doesn't print transaction ids any more.

Maybe do you want to ask on #bitcoin-dev how to debug such issues with
bitcoin core?

> <https://groups.google.com/d/optout>.

[Jakub Suder]

Actually, you gave me an idea, there's apparently a command-line "-debug" option... This generates a lot of noise, and unfortunately doesn't tag the lines with the IP address, so it's hard to tell which messages are relevant. But I can see the transaction there:

2014-11-10 17:57:52 stored orphan tx 3ea4a44cf02efc9b3bf27259b0f62175cf1a77e727106846576070abeaf6ad3c (mapsz 17 prevsz 23)

2014-11-10 17:57:54 received: inv (37 bytes)

2014-11-10 17:57:54   got inventory: tx 3ea49fb68d7a3e8a8a2921b4e1d459a438bbd8e7deec392e769f78b67eedf71d  new

2014-11-10 17:57:54 askfor tx 3ea49fb68d7a3e8a8a2921b4e1d459a438bbd8e7deec392e769f78b67eedf71d   0 (00:00:00)

2014-11-10 17:57:54 sending getdata: tx 3ea49fb68d7a3e8a8a2921b4e1d459a438bbd8e7deec392e769f78b67eedf71d

2014-11-10 17:57:54 sending: getdata (37 bytes)

2014-11-10 17:57:54 AcceptToMemoryPool: 78.91.98.234:8333 /Satoshi:0.8.5/ : accepted 3ea49fb68d7a3e8a8a2921b4e1d459a438bbd8e7deec392e769f78b67eedf71d (poolsz 138)

That would mean a different peer accepted this transaction, am I right? But somehow it wasn't transmitted further (https://blockchain.info/tx/3ea49fb68d7a3e8a8a2921b4e1d459a438bbd8e7deec392e769f78b67eedf71d)... :|

Kuba

[Mike Hearn]

2014-11-10 17:57:52 stored orphan tx 3ea4a44cf02efc9b3bf27259b0f62175cf1a77e727106846576070abeaf6ad3c (mapsz 17 prevsz 23)

Did it appears in the output of getrawmemorypool or whatever the rpc is called? Seems like this tx is missing a parent transaction so it doesn't get relayed.

[Jakub Suder]

Ok, I think I have some kind of idea what happened...

The transaction 3ea4* was created on 2014-08-11. It's trying to spend a 0.049792 BTC output. That output was from https://blockchain.info/tx/2e89a6c07c0165ef1b77839222f60c4dccc59193c97ab8332951491b54542a4c made on 2014-06-26, and in my bitcoinj debug output it's marked as spent by 3ea4*. However, blockchain.info says that output was already spent in https://blockchain.info/tx/9a3785e972d7f62af0e047911b5c991480a9a0cb9bf37dab4dfe9c46deca19c2 on 2014-07-18, so a couple of weeks earlier. And 9a37* is not listed in my bitcoinj wallet info at all for some reason. So something must have went wrong when I was sending that transaction on 2014-07-18 that it ended up not being recorded in the wallet, and that's why the newer transaction is rejected.

So do I understand correctly that 0.12 handles this more explicitly instead of just failing silently?

Kuba

[Mike Hearn]

There's in general no way to know if a tx fails to propagate because of a double spend, it's an unfortunate artifact of how Bitcoin Core works. That's why there's a need to track propagation.

--
You received this message because you are subscribed to the Google Groups "bitcoinj" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+u...@googlegroups.com.