2

I've written some code for connecting to the network, receiving inventories, and requesting data. What I am noticing is that my local node never sends me inventory messages with blocks in them unless I specifically request blocks.

So if I do a getblocks call with a zero stop hash I will get all of the blocks up to the tip, but never any inventory messages after that. Is there some kind of signalling necessary to tell the node i am connected to that I want inventory block messages to stream to me when new blocks are found?

I am connecting with protocol version 70002, relaybool is 1, nodeservices is 1.

I don't see other mentions of this issue so I'm wondering if there is a negotiation issue that isn't being caught or some other problem.

There is no visible ban score, connection is from localhost, I get a verack and normal tx inventory messages are streamed. This happens regardless of whether -whitelist is used. I just never get block inventory updates or unsolicited block messages unless I request blocks via getblocks. After I've retreived blocks up until tip streaming does not commence.

Update: The code has no problem syncing with a bitcoin-core instance on another computer, but the local bitcoin core instance will never send block inventories or respond to getheaders requests. Problem only occurs on localhost to localhost initated connections.

MattyB
  • 91
  • 6

2 Answers2

2

You need to issue a getdata on the last entry in the returned invs. This is used as trigger that you have processed the response, and the remainer will be sent automatically.

Note that since version 0.10, Bitcoin Core does no longer use the getdata/inv/getdata/block cycle to synchronize, but getheaders/headers (for synchronizing headers). Actual blocks are then fetched asynchronously from different peers after the headers are discovered.

Pieter Wuille
  • 98,249
  • 9
  • 183
  • 287
  • In the case where my nodes height is equal to the local peer, if I ask for blocks none are returned (which makes sense), and no inv messages are sent that I can issue a getdata for. I understand that I can switch to the headers first mode, but for compatibility I would like to support blocks signalled via inv messages. – MattyB Dec 27 '15 at 03:25
  • I appreciate the answer though, I feel like in the base case I should be getting those inv messages after a getblocks where I am tip of chain. That isn't happening which leads me to believe there is some other condition that is preventing it from happening. Is there something else I could be missing? – MattyB Dec 27 '15 at 05:45
2

Bitcoind's block directory was corrupted. (0.11.0)

After exhaustive testing, it turns out that bitcoind's block directory was in some way corrupted, and so even though everything indicated it was at the correct chain tip it was not serving blocks to peers without an explicit getblocks request. It would ignore getheaders requests, and not relay block inventories. A complete resync solved the problem.

The key was realizing that the same code could connect to foreign nodes without issue, and that during wireshark dumps the localnode never relayed blocks onto the network at all.

MattyB
  • 91
  • 6