Potential overflow of the network's hashrate indicator in the JSON-RPC API #7476

I was calling the getnetworkhashps and getmininginfo RPCs via some Java code the other day and realized that the hashrate is getting pretty close to overflowing a signed 64-bit integer. Hence, I decided to check how bitcoind handles things (with some help from Luke Jr) and it turns out that a signed 64-bit integer (int64_t) is used indeed (at least in mining.cpp (see here)) -- potentially elsewhere as well?

As you all know, the max value for a 64-bit signed integer is 2^63-1, or about 9223372036854775807. With the sharp increase in hashrate these past few weeks, we seem to be up to about 12.5% of the datatype's full capacity at this point. To illustrate this:

9 223 372 036 854 775 807 (maximum value of a 64-bit signed integer) 1 126 516 160 438 311 092 (current network hashrate -- as of 2016-02-07 12:20:07 UTC)

According to historical data, the value could wrap in maybe 1 - 1.5 years (or however long it'll take for a 1-order-of-magnitude increase in hashrate).

Luke Jr advised me to create a PR on this in the #bitcoin-dev IRC channel the other day. However, as I don't know the codebase that well and am not very well-versed in C++ specifics & caveats, I decided to create this issue instead.

Maybe someone smarter can take a quick look at this and prove me wrong if that's the case :).

Looks like it should be a pretty contained fix if you want to take a stab at it. The function doesn't seem to be used anywhere else except for RPC. Best way to learn the codebase is fix something.

It's an approximation anyway. Just turn it into a floating point result.

Agree with @sipa. This doesn't warrant overhauling the entire RPC system to support larger integers. Floating point should never be used for monetary values, but limited-precision approximations is exactly what it was invented for.