getblockcount() and getblockhash() functions return conflicting results

[edwardlouissullivan]

Issue overview

The getblockcount() and getblockhash() functions return inconsistent results when run from the zcash4mac client. I suspect that the bug is inside the daemon, because the daemon defines the two aforementioned functions.

Detailed bug description

When I ran the commands "./zcash-cli getblockhash 0" and "./zcash-cli getblockhash 219417" back to back, I received hash values for both, which implies that, at that moment, there were are at least 219418 blocks on the best block chain.

Next I ran the command "./zcash-cli getblockcount", which returned the value 219417.

Do you see the inconsistency? 219418 > 219417. The two methods suggest different values for the total number of blocks in the longest chain.

Both commands, getblockhash and getblockcount, in their "help" documentation, claim to refer to the longest or best block chain. I assume that "longest" and "best" mean the same thing in this context.

bulbasaur% ./zcash-cli help  getblockcount
getblockcount
Returns the number of blocks in the longest block chain.

bulbasaur% ./zcash-cli help  getblockhash
getblockhash index
Returns hash of block in best-block-chain at index provided.

Also, as shown above, the documentation for getblockcount specifically states that it returns the "number of blocks", not the index of the highest block.

For reference, these are the commands that I ran, presented in the same order that I ran them:

bulbasaur% ./zcash-cli getblockhash 219417
0000000014517fdeb0b61dbcd9501fc47b9f8bbd7198dd0ab1ea44fa420d2f1d
bulbasaur% ./zcash-cli getblockhash 0
00040fe8ec8471911baa1db1266ea15dd06b4a8a5c453883c000b031973dce08
bulbasaur% ./zcash-cli getblockcount
219417

Disclaimer

This "bug" might just be a minor case of imprecise language in the documentation.

Also, I don't know the details of the zcash protocol, so what I perceive as a bug might actually be the desired behavior.

[daira]

I believe you're correct that getblockcount is supposed to return the number of blocks in the best block chain, not necessarily the longest. [Edit: minus one, as explained below.]

[daira]

Blocks are indexed from 0 for the genesis block. getblockhash uses this zero-based index, while getblockcount actually returns the index (also called height) of the best block, not the number of blocks. Alternatively, it excludes the genesis block from the count.

We should change the documentation for getblockcount to clarify this. It should say:

getblockcount

Returns the height of the most recent block in the best valid block chain (equivalently,
the number of blocks in this chain excluding the genesis block).

Result:
n    (numeric) The height of the most recent block.

[elijahhampton]

Updated the CLI with the correct help message: @daira

#6767

[daira]

Fixed by #6767.