Total amount of hashes

[Adam_xx]

Is it possible to somehow calculate how many SHA-256 hashes have all the miners calculated for the entire history of Bitcoin?

Last numbers I have seen from Pieter Wuille are from 2020:
With block 632874, around a day ago, the expected cumulative work in the Bitcoin blockchain surpassed 2^92 double-SHA256 hashes (with a standard deviation around 1.4*2^83).

[mocacinno]

theoretically, you could make an estimation by using the formula:

The expected number of hashes we need to calculate to find a block with difficulty D is therefore

D * 2**256 / (0xffff * 2**208)

That could be found on page https://en.bitcoin.it/wiki/Difficulty

There's even an example written on this page

OFfcourse, it'll take a lot of grunt work... You'll have to find the difficulty for every batch of 2016 blocks, then calculate the number of hashes to find one block (and multiply by 2016), then do this for every group of blocks per retarget period.

[bitmover]

theoretically, you could make an estimation by using the formula:

The expected number of hashes we need to calculate to find a block with difficulty D is therefore

D * 2**256 / (0xffff * 2**208)

That could be found on page https://en.bitcoin.it/wiki/Difficulty

There's even an example written on this page

OFfcourse, it'll take a lot of grunt work... You'll have to find the difficulty for every batch of 2016 blocks, then calculate the number of hashes to find one block (and multiply by 2016), then do this for every group of blocks per retarget period.

It is also important to note that there is competition between mining pools.

So you have to multiply this number by the number of pools, as they also calculated hashed, but that work was lost as someone found the nonce first

[tromp]

So you have to multiply this number by the number of pools, as they also calculated hashed, but that work was lost as someone found the nonce first

This is wrong in so many ways, I can't even

[garlonicon]

OFfcourse, it'll take a lot of grunt work... You'll have to find the difficulty for every batch of 2016 blocks, then calculate the number of hashes to find one block (and multiply by 2016), then do this for every group of blocks per retarget period.

We have "chainwork" for that. Just check the current chainwork, and estimate it based on that. You don't have to sum all difficulties from all blocks, it is already done by each full node, just to check which chain is the strongest one.

[DaveF]

So you have to multiply this number by the number of pools, as they also calculated hashed, but that work was lost as someone found the nonce first

This is wrong in so many ways, I can't even

I think I get what bitmover was trying to say.
There are 2 answers to the question, depending on how you look at the question.

1 answer, which you can get a reasonably close guess to is how much work of SHA-256 hashes has gone into the blockchain that we can calculate. That you can get a reasonably close answer to.

What we can NEVER know, is how many miners spent how much time hashing away never finding a hash that solved a block. Can't even reasonably guess since we don't know what we don't know. i.e. I could have 1PH sitting here mining to a private solo pool for a year and never found a bock so nobody outside of me would know it existed. And if it DID find a block you would never know if I had a massive farm or 1 USB stick and just got really really lucky.

-Dave

[garlonicon]

I could have 1PH sitting here mining to a private solo pool for a year and never found a bock so nobody outside of me would know it existed. And if it DID find a block you would never know if I had a massive farm or 1 USB stick and just got really really lucky.

Of course, you don't know with mathematical certainty, but when it comes to 1 PH, it is 10^15 hashes. For such huge numbers, mathematical probability is very close to reality. So, based on chainwork, you know that it is very unlikely that there are million solo miners with 1 PH each, because it would be 1000 EH, so some of them would find at least some blocks (and they would collectively have more power than the whole network).

Also, SHA-256 is not a pure random hash function, based on ideal conditions. It is pseudorandom. You can test it, and you will discover, that when you calculate a lot of hashes, then doing it in a brute force way will give you results, that are close to pure luck. And of course, it is possible to find some faster way than brute force, but then we would need a new hash function, rehashing the chain, and things like that.

So, even if it is impossible to reach 100% accurate results, it is possible to estimate. And that estimation should be sufficient for everything we need. Because you don't need to know, how many physical particles are in a ton of sand. You know that it has 1000 kg, for example with 1 kg accuracy, and you don't need the exact result in the smallest physical unit.

[odolvlobo]

Probability and statistics are your friend.

What we can NEVER know, is how many miners spent how much time hashing away never finding a hash that solved a block. Can't even reasonably guess ...

We can't know the actual number but we can come up with a reasonable estimate. The chainwork value is a good estimate and a standard deviation value tells us how good that estimate is.

... I could have 1PH sitting here mining to a private solo pool for a year and never found a bock so nobody outside of me would know it existed. And if it DID find a block you would never know if I had a massive farm or 1 USB stick and just got really really lucky.

The chainwork estimate and standard deviation values account for those possibilities.

[DaveF]

Probability and statistics are your friend.

What we can NEVER know, is how many miners spent how much time hashing away never finding a hash that solved a block. Can't even reasonably guess ...

We can't know the actual number but we can come up with a reasonable estimate. The chainwork value is a good estimate and a standard deviation value tells us how good that estimate is.

... I could have 1PH sitting here mining to a private solo pool for a year and never found a bock so nobody outside of me would know it existed. And if it DID find a block you would never know if I had a massive farm or 1 USB stick and just got really really lucky.

The chainwork estimate and standard deviation values account for those possibilities.

The next step would have to be what a 'reasonable estimate' is for the hashpower that is out there that we don't know about.
I really think it's a lot more then people think OR can be proven. But, I [wait for it] can't prove it.

We know about the big pools, we know about the small pools, we know about the occasional unknown block that pops up.

Most people think that the number of people solo mining to pools they setup themselves is small as in dozens at most. I think it's way higher then that. But we never see them because the "paranoid tinfoil hat brigade" that does not trust mining pools and thinks they can do better themselves because all the pools are out to get you are a lot more common then we see here.

But, we will never see them get a block or even know they exist because their crap setups could never find a block even with all the hash in the world. But they are doing it themselves because they know better. You see these people pop up in the hardware and pool board now and then.

In terms of BTC itself they really do not matter, but and I guess we will have to disagree here, saying that you can use stats to find them is not a realistic thing because they are hashing to find a block but they never will and cannot and there is no way to even know they exist.

I can take you to a data center in NY where someone is paying probably close to $1k a month to run a bunch of S19 that mine to his super special custom coded pool that is going to get a block real soon now.......

-Dave

[odolvlobo]

The next step would have to be what a 'reasonable estimate' is for the hashpower that is out there that we don't know about.
I really think it's a lot more then people think OR can be proven. But, I [wait for it] can't prove it.

All of the hash power that is out there is hash power that we don't know about. Miners don't report their hash rates. They only way we can estimate network hash rates is by looking at how fast blocks are being produced.

We can infer that the expected number is relatively close to the actual number because, for example, if the actual number were twice as much, we would expect to have twice as many blocks.

Think of it this way: The difficulty determines the expected number of hashes needed to find a block, regardless of who is doing the hashing.

Here is a simple example: suppose you have a group of people, each rolling a 6-sided die as fast as they can, and in order to win a round a 1 has to be rolled. Because the probability of rolling a 1 is 1/6, we know that it takes an average of 6 rolls to roll a 1. It doesn't matter who is rolling their die, or how fast they are rolling it. It will take an average of 6 rolls. Sometimes it takes more and sometimes it takes less, but the expected number of rolls is 6 for each round.

Now, the actual number of rolls is probably very different from 6 for each round, but as more and more rounds are played, the actual number is likely to get closer and closer to the expected value. That is the purpose of the standard deviation. The standard deviation measures the probability the actual number of rolls being different from the expected number of rolls by a certain amount.

Again, none of this is actual measurement. It is all probability. When you can't know the actual count, you can still compute the expected count and you can compute the quality of that value (in terms of probability).

[bitmover]

So you have to multiply this number by the number of pools, as they also calculated hashed, but that work was lost as someone found the nonce first

This is wrong in so many ways, I can't even

I think I get what bitmover was trying to say.

The question was how many hashes have all the miners calculated in bitcoin history.

Just because the miner didn't find a block, this doesn't mean that this miner didn't calculate anything. He was not asking cumulative chainwork (although it is the best anwser)

Is it possible to somehow calculate how many SHA-256 hashes have all the miners calculated for the entire history of Bitcoin?

Here is a simple example: suppose you have a group of people, each rolling a 6-sided die as fast as they can, and in order to win a round a 1 has to be rolled. Because the probability of rolling a 1 is 1/6, we know that it takes an average of 6 rolls to roll a 1. It doesn't matter who is rolling their die, or how fast they are rolling it. It will take an average of 6 rolls. Sometimes it takes more and sometimes it takes less, but the expected number of rolls is 6 for each round.

This a nice example. However, if there are 10 people rolling dices, more dices will be rolled. An average will take 6 times to find the answer, but the answer to "how many SHA-256 hashes have all the miners calculated for the entire history of Bitcoin" is not just 6.

[odolvlobo]

This a nice example. However, if there are 10 people rolling dices, more dices will be rolled. An average will take 6 times to find the answer, but the answer to "how many SHA-256 hashes have all the miners calculated for the entire history of Bitcoin" is not just 6.

It is not just 6. It is 6 per round. That is not the actual number, though. That is the average number. And, as there are more and more rounds, the actual number is likely to get get closer (in relative terms) to the average. That likelihood is measured by the standard deviation.

However, there is a relatively small source of error. The chainwork value does not account for stale blocks. A stale block indicates work that has been done but does not contribute to the main chain.

[bettercrypto]

theoretically, you could make an estimation by using the formula:

The expected number of hashes we need to calculate to find a block with difficulty D is therefore

D * 2**256 / (0xffff * 2**208)

That could be found on page https://en.bitcoin.it/wiki/Difficulty

There's even an example written on this page

OFfcourse, it'll take a lot of grunt work... You'll have to find the difficulty for every batch of 2016 blocks, then calculate the number of hashes to find one block (and multiply by 2016), then do this for every group of blocks per retarget period.

For what you said was correct,

  Just compute the number of hashes that required to find once block at that difficulty, and of course multiply this
number by the number of blocks for every batch. This is actually time consuming and computationally intensive task
anyway.

[BlackHatCoiner]

Just because the miner didn't find a block, this doesn't mean that this miner didn't calculate anything.

Correct, but miners don't report their total hashes, and even if they did, there would be zero manners to verify they're telling the truth. The closest answer that is undoubtedly true is the chainwork. That's the solution to the Byzantine generals in the end; not having unreliable factors. Chainwork speaks for itself and is as objective as possible.