Less getblocks zeros #3990

Change these lines:

getblocks 293326 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500

to these lines:

getblocks 293326 to end limit 500

(i.e. no need to display an expanded hash of NULL)

@laanwj @sipa @gmaxwell Some comments/ACKS would be appreciated. Thanks.

I like printing always the full hash. It used to be different in earlier versions but at a certain point it was decided to change this.

Indeed. It allows easy copy pasting entries from the log file into RPCs or other services.

Please can you look at what this pull request does. It doesn't change the way hashes are displayed as the assumption seems to have been. It simply doesn't display a long line of ONLY zeros when there is NO hash as it does currently.

@laanwj please can you re-open this pull request, as it was misunderstood what it does. thank you.

I still don't really see the point of making a special case for 0.

@laanwj because 0 isn't a hash, it's like a NULL, so it seems wasteful to fill debug.log with an expanded hash of NULL, when it's not a hash.

Right, uint256(0) is a special case here. It's a pity that things were done this way in the protocol, but you can't help that. Reopening.

If we're special-casing anyway, what about using a string such as "end" or "last" instead of "0"? "To 0" reads like it's trying to requests the blocks to the beginning instead...

@laanwj ah, yes, "end" is more clear. Changed.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/p3990_0dd5d3a00906d8a0f16d6eac62b63c9bb2da1391/ 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.

ACK