<p>Start by computing the total amount of work. Work is defined as the expected number of hashes that were necessary for a particular block. If a block's target is <code>Target</code>, its amount of work is <code>Work = 2**256 / (Target + 1)</code> (follows from the fact that <code>Target + 1</code> in <code>2**256</code> hashes have a value lower or equal to <code>Target</code>). As the difficulty <code>Diff</code> is defined as <code>MaxTarget / Target</code> with <code>MaxTarget = 65535 * 2**208</code>, it follows that <code>Work = Diff * 2**48 / 65535 = Diff * 4295032833</code>.</p>

<p>So, for each block, look at its difficulty, and compute <code>Diff * 4295032833</code>. Compute the sum of all those values for all blocks in your time range.</p>

<p>Now divide that sum-work by the number of seconds your interval lasted. The result is your average number of hashes per second during that interval.</p>

<p>For very short intervals (less than a few hours), it is possible for block timestamp inaccuracy to be relevant. One way to avoid this problem is by starting off not with a range of blocks, but a range of timestamps, and choosing all blocks within that range, rather than estimating the time range from the range blocks.</p>

CC BY-SA 3.0
2014-08-27T00:34:01.900Z
2014-08-27T00:45:34.993Z
2014-08-27T00:45:34.993Z
Pieter Wuille
<p>You can look at the range's first and last block, if they match exactly you can just calculate the average hash-rate from time elapsed, height difference (number of blocks) and difficulty.</p>

<p>If they don't match, you will have to create the weighted average over each difficulty section. You calculate the average hash-rate for each section then multiply it with the duration, add all the results together, divide by total time.</p>

<p>You could find the sections by binary search between your range's first block and last block, but it would be much easier to just look at every 2016th block, because the reset happens on schedule. ;)</p>

<p>Better yet, you can actually tell immediately that way how many changes in difficulty exist in your range by looking at the height of first and last block. </p>

<p>Update:<br>
As pointed out by Pieter, it is possible for blocks to be timestamped inconsistently, making it possible for a block to have a lower timestamp than their predecessor. Any implementation should probably check for corner-cases such as this one. In general the result will be better if a larger interval is taken into account, unless the interval is so large that the hashing-power has increased significantly within it.</p>

CC BY-SA 3.0
2014-04-26T11:54:09.277Z
This will deal badly with cases where time goes backwards between two blocks.
Pieter Wuille
CC BY-SA 3.0
2013-10-28T07:32:48.540Z
2014-04-28T22:40:53.323Z
2014-04-28T22:40:53.323Z
Murch
<p>Not sure if the title is poorly worded, but here's what I'm looking to do.</p>

<p>If I have a range of blocks and I want to calculate the hashrate, I can do something similar to what is found <a href="https://bitcoin.stackexchange.com/questions/11139/how-is-the-network-hash-rate-calculated">here</a>.</p>

<p>To take it a step further, I'd like to be able to calculate hashrate for a given number of blocks from the current block. Using the example provided above, this is rather trivial.</p>

<p>However, I'm running into issues doing this when the difficulty changes somewhere within the range of blocks.</p>

<p>Take last night as an example. Difficulty changed to roughly ~390M. Prior to that it was roughly ~267M. </p>

<p>How would I go about calculating an average network hashrate for a given range where the difficulty has changed within that range?</p>

<p>Thank you for the help!</p>

<difficulty><hashpower>
How can I calculate network hashrate for a given range of blocks where difficulty changes somewhere within the range?
Ian P
# How can I calculate network hashrate for a given range of blocks where difficulty changes somewhere within the range?

(Asked by: username_0 on 2013-10-26)

Not sure if the title is poorly worded, but here's what I'm looking to do.

If I have a range of blocks and I want to calculate the hashrate, I can do something similar to what is found [here](https://bitcoin.stackexchange.com/questions/11139/how-is-the-network-hash-rate-calculated).

To take it a step further, I'd like to be able to calculate hashrate for a given number of blocks from the current block. Using the example provided above, this is rather trivial.

However, I'm running into issues doing this when the difficulty changes somewhere within the range of blocks.

Take last night as an example. Difficulty changed to roughly ~390M. Prior to that it was roughly ~267M.

How would I go about calculating an average network hashrate for a given range where the difficulty has changed within that range?

Thank you for the help!

**Tags:** difficulty, hashpower


---

## 2 answers

### Answer by username_1 on 2014-08-27. Score: 4

Start by computing the total amount of work. Work is defined as the expected number of hashes that were necessary for a particular block. If a block's target is `Target`, its amount of work is `Work = 2**256 / (Target + 1)` (follows from the fact that `Target + 1` in `2**256` hashes have a value lower or equal to `Target`). As the difficulty `Diff` is defined as `MaxTarget / Target` with `MaxTarget = 65535 * 2**208`, it follows that `Work = Diff * 2**48 / 65535 = Diff * 4295032833`.

So, for each block, look at its difficulty, and compute `Diff * 4295032833`. Compute the sum of all those values for all blocks in your time range.

Now divide that sum-work by the number of seconds your interval lasted. The result is your average number of hashes per second during that interval.

For very short intervals (less than a few hours), it is possible for block timestamp inaccuracy to be relevant. One way to avoid this problem is by starting off not with a range of blocks, but a range of timestamps, and choosing all blocks within that range, rather than estimating the time range from the range blocks.


---

### Answer by username_2 on 2013-10-28. Score: 0

You can look at the range's first and last block, if they match exactly you can just calculate the average hash-rate from time elapsed, height difference (number of blocks) and difficulty.

If they don't match, you will have to create the weighted average over each difficulty section. You calculate the average hash-rate for each section then multiply it with the duration, add all the results together, divide by total time.

You could find the sections by binary search between your range's first block and last block, but it would be much easier to just look at every 2016th block, because the reset happens on schedule. ;)

Better yet, you can actually tell immediately that way how many changes in difficulty exist in your range by looking at the height of first and last block.

Update:  
As pointed out by username_1, it is possible for blocks to be timestamped inconsistently, making it possible for a block to have a lower timestamp than their predecessor. Any implementation should probably check for corner-cases such as this one. In general the result will be better if a larger interval is taken into account, unless the interval is so large that the hashing-power has increased significantly within it.

> **Comments:**
> **username_1**: This will deal badly with cases where time goes backwards between two blocks.  

---

