A small piece of logic that will be needed in headersfirst: knowing up to which point each peer is synchronized. As we no longer react on specific messages to trigger fetching blocks, but instead actively & asynchronously fetch what we're missing, we must know what we can ask from whom.
This is not very useful now, except that it adds 'syncheight' to getpeerinfo (which is much more meaningful than startingheight, imho).
'syncheight' looks like very useful information, will merge this into my testing nodes.
Looks OK to me... but it makes me nervous to add additional places in the code where a "valid hash equalling zero" may accidentally trigger undesired behavior.
There was some discussion on IRC of separating uint256 and opaque_hash types. If such were the case, this code would not compile.
ACK after code review and compiling/running/syncing a week's worth of blocks on OSX.
4498 | @@ -4453,6 +4499,9 @@ bool SendMessages(CNode* pto, bool fSendTrickle) 4499 | pto->fDisconnect = true; 4500 | } 4501 | 4502 | + // Update knowledge of peer's block availability.
I have problems wrapping my head around this one. Why is the knowledge of block availability of the node set to 0 here at this point in SendMessage?
There is no new information in this case, but hashLastUnknownBlock may after a while refer to a known one, so we want to update hashBestKnownBlock in that case. It's just done here because SendMessages is called periodically.
@sipa Another option would be to split the function in two, an UpdateBlockAvailablity(node) for the first part and a ProcessBlockAvailability(node, hash) for the second part (or better names). That would remove the need for special-casing uint256(0) as well.
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/p4407_aa815647005bc8467f467c35a9e617794446cd64/ for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.