2

My P2P is a bit rusty, but as far as I understand; if we're running a full node, other nodes will connect to us to share blocks. So I can see why it would be useful to be able to see how far behind other nodes's blockchains are with the getpeerinfo command.

However, what's the practical difference between synced_headers and synced_blocks?

For example, what does it mean if a peer has synced_headers equal to the height of our own blockchain, but a synced_blocks of -1?

2

Bitcoin clients can have headers without having blocks. (However, Bitcoin Core never has a block without a header.)


A synced_blocks of -1 means that the best block for the other node is unknown.

synced_blocks is set here:

https://github.com/bitcoin/bitcoin/blob/b3e42b6d02e8d19658a9135e427ebceab5367779/src/main.cpp#L557

stats.nCommonHeight = state->pindexLastCommonBlock ? state->pindexLastCommonBlock->nHeight : -1;

A synced_headers of -1 means that the best header for the other node is unknown.

synced_headers is set here:

https://github.com/bitcoin/bitcoin/blob/b3e42b6d02e8d19658a9135e427ebceab5367779/src/main.cpp#L556

stats.nSyncHeight = state->pindexBestKnownBlock ? state->pindexBestKnownBlock->nHeight : -1;
  • Thanks again, Nick. So would it be correct to say that if the nCommonHeight is -1, then the other node isn't attempting to send or receive block data with our node? – inersha May 17 '16 at 12:56
  • @inersha I think so, yeah. – Nick ODell May 17 '16 at 18:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.