Add getnetworkhashps to get the estimated network hashrate #2888

This call is useful to mining pools and miners. It lets you get the estimated network hashrate at the current block (or any previous block) with a specified number of blocks to use to calculate the estimate.

This can be implemented much more accurately by computing the nChainWork difference divided by time difference.

Should this also be squashed into a single commit for Bitcoin?

I think the commits here look logical (and don't need to be squished)

Does @sipa insist on the rewrite to use nChainWork difference?

@wtogami Yes, I think it's trivial to do right.

Beyond also sharing pieter's concerns wrt doing the calculation with pow() instead of directly. I think the default (no parameter) call having a variable integration window is weird. This means if you call it right after a difficulty change you'll get some insane random number. Had I implemented this I likely would have just had a default of 2016 blocks and no options.

Agree w/ feedback. Would like to see this merged, after revision.

@coblee Any progress on this? Seems to be a nice feature.

I will get to it in a few days. Thanks for all the feedback.

https://github.com/litecoin-project/litecoin/pull/69 @pooler has implemented sipa's requested change. coblee wants to write tests before submitting this to Bitcoin. I suggest squashing it a bit to have fewer, cleaner commits for Bitcoin.

Sorry for the delay, the change is tested and pushed. Please take another look. @sipa, thanks for the suggestion. @gmaxwell, the default behavior is to use the previous 120 blocks.

Thanks @pooler for the fix.

Code change looks good.

One idea (to be discussed, perhaps): shouldn't be use max(block.time for block in blocks) - min(block.time for block in blocks), to avoid weird edge cases with small numbers of blocks and non-causal timestamps?

That's a fair point. I will make that fix. Will also need to handle a divide by zero edge case

Hmm, I made the change, but looking at it now, I'm not sure it's a good change. Making sure we get correct results for weird edge cases is probably not worth the extra cost in keeping tracking of a min/max over all the blocks, since people won't be calling this method with a small number of blocks. @sipa, what do you think? We can always just do a sanity check to make sure min < max.

Another idea (just up for discussion, don't rush implementing this): use the median-of-11 as timestamp for the begin and end block, which guarantees monotonicity (by network rule) and is likely a better estimator for actual time as well. The question is of course which window-of-11 to use; if you use 5-before-until-5-after, it's not usable for the last 5 blocks, but likely unbiased. If you use 10-before-0-after, you get a slight bias if blocks are speeding up/slowing down, but I doubt that'd be noticable on such a short time frame.

@sipa How does the estimator you use on sipa.be work?

I still think there's no need to be so precise with getting the time right since this is just an estimate. With a large enough block count, the difference between each of these solutions (just GetBlockTime, min/max, median-of-11) will be minimal. So not worth the extra cpu cycle to get it "right".

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

@gmaxwell Exponential window that measures rate and average timestamp of past blocks (which seems to be what you need for a most likelyhood estimator for an poisson process whose rate is an exponential function; I'm certainly not able to do the math for that again, but the resulting formula's became ridiculously simple), which is used to guess the parameters of the hashrate growth curve in every point, which on its turn is used to extrapolate the the speed at the current time. Way too complex (and probably too unstable) for using inside the program.

ACK