How are Bitcoin’s difficulty and hash rate calculated? Bitcoin’s difficulty is adjusted bi-weekly to speed up or slow down the block pace to a rate of one per ten minutes. And, hash rate is an estimate based on the block pace and difficulty target.
Yet, Bitcoin’s block pace always varies despite having a target. As a result hash rate estimates also vary. So, which hash rate reading is the correct one? Let’s investigate.
In this article we describe how Bitcoin’s difficulty and hash rate are calculated. We then show why it is important to understand how sample time windows, distributed systems, and miner luck could create hash rate bias. We end with a few examples of how a misinterpretation of Bitcoin’s hash rate provokes undeserved fear or elation, which may trigger a BTC price change.
Bitcoin’s Difficulty and Block Pace
In this first section we describe the purpose of Bitcoin’s difficulty, and its calculation. We also look closer at block pace and its behavior. This information will help us to better understand how Bitcoin’s hash rate is found in the following section.
Difficulty and Protocol
Bitcoin’s difficulty level is the estimated number of hashes required to mine a block. And, because the difficulty calculation is deterministic everyone can calculate the target independently. This means that all bitcoiners come to the same difficulty target without relying on a centralized authority.
The purpose of difficulty is to keep the rate of coin issuance and block confirmation intervals steady over time. The difficulty target also enforces protocol rules.
For example, miners need to have consensus on the current difficulty, in order to achieve the correct nonce so that they can hash a viable proof-of-work solution. Likewise, a full node will reject a block submitted by miners that does not have a double SHA-256 hash value less than the difficulty target.
How Difficulty is Calculated
Bitcoin’s difficulty calculation uses hexadecimal notation, meaning a set of numbers and letters. Although, there are various ways to measure difficulty. Here is the most basic formula:
Difficulty Level = Difficulty Target / Current TargetIn the equation above the Difficulty Target hexadecimal is the highest possible target to be reached with a block hash, with a difficulty of 1. The Current Target is the hexadecimal difficulty derived from the 256 bit number in a block header.
So, when the two hexadecimal numbers are divided, it results in the Difficulty Level which is a whole number. For instance, Bitcoin’s current difficulty is 24 trillion (T). And, as previously mentioned, the difficulty level is the approximate amount of hashes miners need to perform to find a block.
Difficulty Adjustments
Each 2016-block interval is known as a difficulty epoch. At the beginning of every epoch the Bitcoin network recalculates the Current Target.
The network does this by summing the total minutes it took to mine the last 2,016 blocks. It then compares this total to a desired rate of 20,160 minutes (10 minutes times 2,016 blocks). This ratio is multiplied by the current difficulty level, resulting in a percent change up or down.
The protocol limits the lowest possible difficulty level to 1, yet the is no upper limit. And, to prevent abrupt changes, Bitcoin’s difficulty correction factor has a maximum of 4 times its value, and a minimum of 1/4. So, the difficulty adjustment is limited to +300% (4x), or -75% (1/4) per epoch.
Difficulty Fun Facts
Interestingly only 2015 blocks are actually included in the difficulty calculation. The interval between blocks 0-1 is left out. This protocol bug may speed up coin issuance by about two years in total, but fixing it would require a hard fork.
Additionally, 2016 blocks backwards is 6102. This coincidence may reference the United States’ Executive Order 6102, which called for the confiscation of privately owned gold in 1933.
Furthermore, for reference, Bitcoin’s largest upwards difficulty adjustment was the maximum of +300% on July 16th, 2010. This was because the hash rate grew from 300 to 1,300 MH/s in the previous epoch. The smallest adjustment was -27.9% on July 3, 2021, following the Sichuan shutdowns. Between May and July of 2021, Bitcoin’s hash rate dropped ~ 50%, from 180 EH/s to 98 EH/s, due to China’s mining bans.
Block Pace and the Poisson Distribution
Results when Bitcoin’s difficulty and hash rate are calculated depend on the randomness of the Poisson process. Generally the block pace follows a Poisson distribution, where the majority of blocks are found within a 10 minute window. See the histogram below.
However, as with any random process, block intervals are sometimes very small or very large. For example, see below how the daily block pace in blue varied much more than the 2,016-block average in green the past year.
Difficulty, Block Pace, and Hash Rate as a System
Now, let’s look at how the difficulty mechanism works as a system.
Notice above that when the block pace in green exceeds the target of 10 minutes, the difficulty in blue drops thereafter to make it easier to mine a block. On the other hand, when the block pace is too fast and below the red line, the difficulty in blue goes up in the next epoch.
Difficulty and block pace are directly affected by the amount of miners online. If more miners join the network during an epoch, then block pace speeds up. Vice versa, if many miners leave the network, then block pace may slow until the difficulty readjusts. Read more about miner trends here.
Curiously, Bitcoin’s hash rate and difficulty have the exact same behavior in the graph above? This is because of how Bitcoin’s difficulty and hash rate are calculated. The difficulty is derived from the block pace, and the hash rate is estimated from the difficulty.
On that note, let’s now discuss Bitcoin’s hash rate.
Bitcoin’s Hash Rate
In this next section we look closer at Bitcoin’s hash rate calculation. We then explain why ASIC miner running patterns, time windows, behaviors of distributed systems, and miner luck can create hash rate estimate variance.
But first let’s review units of measure.
Hash Rate Units
Bitcoin’s network is the accumulation of hashes per second from the miners currently online. Each guess a miner makes toward solving for the next block is called a hash. In other words, one hash per second (H/s) equals one double SHA-256 computation attempt (i.e. (SHA256(SHA256))).
However, when we talk about machines, mining pools, and the network size, we use different SI-Prefixes which can be confusing.
The main hash denotations are as follows:
- Bitcoin mining machines hash in terahash per second (TH/s).
- Mining pool sizes are listed in petahash per second (PH/s).
- The network’s total hash rate is described in exahash per second (EH/s).
So, in order to solve for the next block, an AvalonMiner A1246 at 90 TH/s performs about 90 trillion double SHA-256 attempts per second. Pretty crazy, right?
Network Hash Rate to ASICs
Additionally, we can use the network hash rate to estimate the number of machines currently online. We can take the network size of 180 EH/s, and divide by an average of 70 TH/s per machine. We find that there are about 2.5 million machines hashing on Bitcoin’s network. See the steps below.
Convert 180 EH/s to TH/s:
180 EH/S * 1,000,000 H/s = 180,000,000 TH/s
And, 180,000,000 TH/s to ASIC units is:
180,000,000 TH/s / 70 TH/s = 2,571,429 machinesNode Query of Miner Info
Now let’s talk about how Bitcoin’s hash rate is found. One way is by making a Bitcoin Core node query. Try this command:
> getmininginfoIt returns the following object with updated stats:
{
"blocks": 715528,
"difficulty": 24195286980613.253,
"networkhashps": 1.776723108374626e+20,
"pooledtx": 1327,
"chain": "main",
"warnings": ""
}This json object reads: the current block height; the difficulty level; the network hashes per second in scientific notation; the amount of transactions waiting for confirmation in the mempool; the network name; and any warnings on the network or blockchain. (Scientific notation means that you move the decimal place to the right x amount of times for e+x).
But, if you were to type the ‘getmininginfo’ node command over and over again, the hash rate would change each time a new block is found. This is because the network’s hash rate is not accurate at any given instance.
Only hash rate measurements collected over longer periods of time are indicative of change.
ASIC Miner Hash Rates
This same principle holds true for ASIC miners. When a miner analyzes a machine’s overall performance, they look at the 24h change over several days. This is because Real Time and Hourly TH/s rates oscillate continuously.
For example, notice that the S19 Pro machine has specs of 110 TH/s, but can hash between 85-130 TH/s at any one time.
So, like the hash rate returned by the node command, an ASIC hash rate reading is only accurate when averaged over longer periods of time.
Network Hash Rate Readings Differ
If we look around at Bitcoin explorer websites, we also find that Bitcoin’s network size varies. For example, at the time of writing we find that from a handful of websites today’s hash rate is between 149-175 EH/s. This is a 26 EH/s difference!…
To put this in to perspective, 26 EH/s is equivalent to ~ 260,000 new generation ASICs worth $3 billion dollars. Or, 900 MW, which is the size of an entire nuclear power plant.
The chance of 26 EH/s joining or leaving Bitcoin’s network in one day, or even in a few days, is just not feasible. Unless of course a huge event like a natural disaster or policy change occurs in a location that is highly concentrated with miners.
So, why are Bitcoin’s hash rate readings so different?
Because each websites uses their own simplified metrics and data from arbitrary time windows. And, shorter time windows create more variance.
So, continuing on with how Bitcoin’s difficulty and hash rate are calculated, let’s now look closer at Bitcoin’s hash rate. In particular we will discuss why time windows affect the network size.
How Hash Rate is Calculated
Hash rate is an estimate because Bitcoin is permisonless and miners do not need to identify themselves. Only Bitcoin’s block timestamps and the current difficulty target are recorded on the blockchain. And it is this data that is used to estimate the hash rate.
So if we know the difficulty, the network’s hash rate calculation can be simplified to:
Hash Rate = Current Difficulty * 2^32 / 600In this equation the probability that a miner finds a block is 1/(2^32), meaning that the average unique hash attempts to find a block is approximately 2^32. This hash work is then multiplied by the current difficulty, over the 600 second (10 minute) target block pace.
But this equation is very general. It does not compare the actual block pace to the expected block pace. Thus, to find a better estimate of the current hash rate, we take the actual rate of finding a block versus the expected rate of finding a block. We then multiply this ratio by the difficulty and hash work to find a block, over the ten minute target. See below:
Hash Rate = (Blocks Found / Blocks Expected) * (Difficulty * 2^32) / 600Let’s do an example over a 12-hour period. In 12 hours we would expect 72 blocks to be found at a rate of one every ten minutes, but only 65 are found. And, the current difficulty is 24,272,331,996,979. So,
Hash Rate = (65/72) * (24,272,331,996,979 * 2^32) / 600 =
0.90 * 104,248,870,000,000,000,000,000 / 600 =
1.5685594e+20 H/s
And we convert units,
156,855,940,000,000,000,000 H/s / 1,000,000,000,000,000,000 H/s =
12h Hash Rate = 157 EH/sFrom this calculation we find that the block pace is slow at 90% (0.90) of the expected 100% rate. And, after converting units, Bitcoin’s network is about 157 EH/s over the past 12 hours.
Sample Time Windows
Moving average hash rate measurements can be based on data from the previous 12-hours, 24-hours, 3-days, 7-days, or 14-days. But, as previously discussed, the shorter the time window, the more variance is present.
To show how time windows matter, we compare the 24-hour hash rate to the 7-day average over the past year below.
The 24h hash rate in green deviates up to about 25 EH/s from the 7-day change in blue. And, as discussed before, it is not physically possible for 25 EH/s, or 250,000 ASICs, to join or leave the network in one day unless a serious incident occurred.
Why is there such a large discrepancy? Because when we look at a 24h hash rate reading we are only looking at 7% of the epoch’s size. So a small variance can create a large discrepancy. Whereas a 7-day hash rate averages data equivalent to 50% of the epoch size, making it a more reliable estimate. See an illustration of this concept below.
Reasons for the Variance
So far we have discussed external reasons why hash rate readings differ, including miners coming and going from the network, oscillating hash rates from ASICs, as well as the fact that hash rate readings use arbitrary time windows.
But, because Bitcoin is a distributed system, irregularities exist from within which can also affect hash rate estimates. For instance, not all nodes are directly connected to one another which creates lag. Blocks may be timestamped inconsistently. Furthermore, the block pace may speed up or slow down temporarily due to miner luck. Let’s briefly discuss these factors.
Distributed System of Nodes
Bitcoin is a distributed ledger on a dynamic peer-to-peer network. This means that updates of the blockchain performed by each node are not the exact same as all other nodes at any one time.
However, over time the blockchain guarantees consistency. For example, transactions are only confirmed once two or more subsequent blocks have been found. Also, one hundred blocks must be mined before a miner can spend their rewards.
In other words, Bitcoin’s byzantine fault tolerant protocol guarantees that eventual consensus is always reached by the majority of the nodes. Yet, replicas of Bitcoin’s ledger may be temporarily inconsistent in the last few blocks. This means that hash rate estimates which use small time windows, like 12h, may be bias due to a minor lag in nodes updating their blockchain.
Timestamp Inconsistencies
Additionally, block timestamps can sometimes be out of order. This is because each node uses their computer’s clock to set the timestamp. Thus it becomes possible for a block to have a lower timestamp than its predecessor. Although rare, this phenomenon may create variance in shorter block time analyses and hash rate estimates.
More specifically, the consensus rules state that timestamps must be greater than the median of the past 11 blocks, and less than the network-adjusted time plus 2 hours.
The network-adjusted time is the median of timestamps returned only by the nodes directly connected to the one measuring at that instance. To imagine this subnetwork, look at the green lines in the Distributed Decentralization image above.
Luck of the Block
Lastly, it is important to understand how luck affects hash rate readings.
Usually block times follow a Poisson Distribution where the majority of blocks are found around the 10 minute mark. However, sometimes many blocks are found in quick succession due to a period of high luck. Other times no blocks are found for a period due to bad luck. Although, mining pools define luck a little differently. If a pool finds more shares than they predicted given the amount of hash rate they have online, they are experiencing high luck.
Periods of high luck may speed up the block pace temporarily, resulting in hash rate estimates becoming higher than they truly are. Here is an example of this phenomenon from earlier this month:
On December 8th, 2021, pool luck was about 20% more than expected. On the same day you can see that the 24h hash rate reading was 28 EH/s greater than the 7-day. As luck subsided over the following days, the 24h hash rate reading dropped back down by 18 EH/s. And as previously mentioned, the hash rate cannot really change this much in one day unless a huge event occurs. Therefore it was miner luck which caused the 24h hash rate reading to be artificially amplified.
Summary
To review, Bitcoin’s difficulty and hash rate are calculated using block intervals. Whilst block pace usually follows a Poisson distribution, a large variance can sometimes occur due to the random nature of Bitcoin mining’s hashing algorithm and its decentralized system. Temporary block pace variance may create hash rate reading bias, especially when small time windows are used.
Why is it important to understand how Bitcoin’s difficulty and hash rate are calculated? Because bias hash rate estimates are sometimes sensationalized by the media, and could have an affect on the BTC price. Lastly, we supply some examples.
Incorrect Hash Rate Affects Price
In 2017 it was reported that up to 50% of bitcoin miners left the main chain to join Bitcoin Cash (BCH). Yet in reality the block pace was slow for BTC, and fast for BCH, due to randomness and luck. Accordingly, this small variance had a large affect on the 12h time window used to measure the hash rates in the report. The perceived fear of miners moving to BCH may have been the reason that BTC’s price dropped 6% on the same day.
Again in 2019 a news outlet theorized that a 40% drop in Bitcoin’s one-day hash rate could be due to a downturn in miner profitability and S9s turning off so that they could update firmware. However, 41 EH/s, equivalent to 3 million S9s, could not just disconnect in one day. These undue fears were based on temporary variance in the block pace, which lead to an inaccurate 24h hash rate reading. The BTC price dropped about 9% in the days following this perceived loss of hash rate.
Lastly, over the years many have prematurely announced that Bitcoin’s hash rate reached an ATH. Unfortunately their information was based on 12h, 24h, or 3-day hash rate readings, at a time when Bitcoin’s block pace was experiencing high variance. Depending on the source, these claims may have caused an increase in the BTC price.
In conclusion, remember that it is best practice to use 7-day or 14-day averages when interpreting changes in Bitcoin’s hash rate.
We hope you enjoyed this exploration of how Bitcoin’s difficulty and hash rate are calculated. Have you read our analysis about whether BTC’s price follows hash yet? Check it out.
