rpcserver: Modify getnetworkhashps -1 blocks logic.

[davecgh]

Now that the target difficulty is calculated every block as opposed to on an interval, the logic in the getnetworkhashps RPC that treated a negative number of blocks as a signal to calculate back to the most recent difficulty change no longer makes sense.

Thus, this updates the getnetworkhashps RPC to ignore negative values so that the default number of blocks is used instead.

It also updates the RPC server help description accordingly to remove mention of the previous behavior.

[jholdstock]

Silently transforming a negative input to the default value is non-intuitive to the caller. IMO that behaviour should either be clearly documented, or negative input should be treated as invalid and an error should be returned.

[davecgh]

Silently transforming a negative input to the default value is non-intuitive to the caller. IMO that behaviour should either be clearly documented, or negative input should be treated as invalid and an error should be returned.

I updated the RPC help to call out the behavior. While I agree that theoretically negative values would be better as invalid and rejected, as I've never really liked that particular inherited feature, changing it now would be a breaking change the API. You're right to call out that it should be documented (and now it is).

Also, as it stands, "-1" (or really negative values in general) have always had a dynamic and ambiguous nature to them since the number of blocks it represented changed with every block. As a result, it has always been best interpreted as "give me a useful value" since values across retarget intervals when those intervals are large are otherwise significantly skewed and not particularly accurate.

However, now that the difficulty changes with every block, that longer applies and therefore treating "-1" as the default number of blocks can still be interpreted as "give me a useful value".

Given that, I decided to avoid breaking the API and keep the spirit of it.

In some unspecified future if we ever create a per-version RPC where the legacy versions are still available but callers can opt into newer versions, I would be in favor of disallowing negative values.