I'm working on an application in which we'd like to know if the current node is sufficiently synced to be able to handle RPC requests. The method we would like to use is to see if our node has at least 2-4 peers and if a majority of the peers are reporting the same best height / best block hash.
- I know the
versionnetwork call gets the height of the peer at that time, but it isn't updated. In addition, any further
versionrequests result in an increase of the ban score of a node, so this cannot be used frequently.
- Bitcoinj (https://github.com/bitcoinj/bitcoinj/blob/cd7dc3e535a06d10c010aa63d20ffeab294dd61b/core/src/main/java/org/bitcoinj/core/PeerGroup.java#L1737-L1743) keeps track of the height of the best known peer by using the height given in the version message and then incrementing whenever the peer processes an
invmessage showing they have a new best-block height. This seems fast, but tricky/error prone.
- This question (https://bitcoin.stackexchange.com/questions/32578/would-it-be-possible-to-add-an-rpc-call-to-be-able-to-determine-if-a-node-is-ful) is similar, but it asks about how to do this with RPC calls, and it doesn't seem to want to use the same method for determining whether the node is synced as the one I've proposed.
- This question (https://bitcoin.stackexchange.com/questions/32578/would-it-be-possible-to-add-an-rpc-call-to-be-able-to-determine-if-a-node-is-ful) helped provide a temporary solution (calling get work and seeing if it fails), but this method is not accurate enough.
Is there a way to just ask a peer what the height of its best block is without getting banned?
Could I just make multiple
getheaders requests and see if the peer returns any headers later than the header I have, or would the peer ban me for requesting the same headers again and again?