Hacker News Reader

Comment by deepblueocean | Hacker News Reader

How do you calculate the hash rate?

I have spent some time trying to understand the various hash rate estimates people come up with. Basically, I've determined that they're all 100% bogus. People like to work from the difficulty using bad/incorrect statistics since that's the most obvious way to get to something in the units of hashes/s, but I can never understand exactly what the process is. I'm genuinely curious to know what people do in practice, since I'm genuinely curious to know the "real" answer.

View on HN

100% bogus? I'm not sure what bad/incorrect statistics you are referring to since it's relatively straight forward to find.

The current target hash is "0x000000000000022FBE0000000000000000000000000000000000000000000000"

This means that to solve a block, you must find a SHA-256 hash of that block's transactions + nonce that hash to a value equal or below that target. Since the output of a SHA-256 hash is essentially random, the probability of finding a nonce that evaluates to hash at or below that target is roughly [target]/[possible sha256 outputs] or 3.51e60/2^256, or 3.034e-17. On average, that means it takes 1/3e-17 or 3.3e16 hashes per block. To calculate average hashes per second of the network, we look at number of blocks solved in the last x unit of time (if you want a 24 hour average, take the number of blocks in the past 24 hours). As of the time of this post, 170 blocks have been solved in those 24 hours. This implies an expected 24*3.3e16 or 8e17 hashes have been computed. Divide by 86400 (seconds in a day) and you get 9.26e12, or 9.26 TH/s. The site reports 6.5 TH/s, presumably because it uses a longer window than 24 hours (probably 7 days).

Just because it's a statistical average instead of the exact rate doesn't mean it's 100% bogus. If you want, you can use fairly standard statistical models to find an acceptable error margin.

You have errors. 170 blocks have been found so 170*3.3e16 = 5.6e18 hashes have been computed. Divided by 86400 = 64.9 Thash/s (and the site currently reports 65.2 Thash/s, not 6.5).

Ah oops, you are correct. Looks like I cannot edit my post otherwise I would fix it :/

It doesn't bother you that your method counts only unique hash values tested? Or that this value is being used on the site to talk about power expenditure (which is clearly related to total hashes per second, not unique hashes)?

You're right that you can compute the N-second average rate easily. But nobody reports the "network hash rate" as such. And since the denominator matters a lot in determining what the number means, pretty much all the numbers you find out in the world are (1) misreported and (2) bogus.

It does count only unique hash values, but why should that bother me? People don't randomly generate the same 256 bit number very often (in fact, the probability is so low that it has almost certainly never happened)

When I search for "bitcoin network hashrate" on google, the first link is http://bitcoin.sipa.be/, which does in fact report the N-second average rate. It reports the 7-days, 14-day, and 30-day average rate.

Duplicate hashes are an issue because of the birthday problem: http://en.wikipedia.org/wiki/Birthday_problem

The chance of two hashes being equal is small but the number of two hash pairs grows exponential to the number of hashes.

No, it's still not an issue. Check out the table for 256 bit numbers in the article you linked. To get a 0.1% probability of even a single collision, you need to generate 1.5e37 hashes. At 10 TH/s, that would take 3e17 years. 10 million times longer than the age of the universe.

The birthday paradox basically says that you can expect a collision when you've explored the square root of the problem space. For birthdays, you expect a collision in a group of sqrt(365) ~= 19 people.

For a 256-bit hash, you expec a collision in a group of 2^128 hashes. That is still huge. Absent a weakness in the hash being found, it's unlikely anyone will ever generate two colliding hashes.

The network collaborates to adjust the mining difficulty, to keep the rate of new coins approximately the same over time:

https://en.bitcoin.it/wiki/Difficulty

There is a linear relationship between the hash rate and the difficulty (there is further discussion at that link).

I'm aware of that. rwinn, can you tell me if this is what you're doing?

It's in your last sentence that you go wrong. There's a relationship between the number of expected hashes per new block and the difficulty. That tells you something about the hash rate, but not the rate itself. Actually, it tells you something about the number of unique hashes being tried per new block (in expectation). And for some applications, that may, in fact, be what you care about.

Specifically, the appearance of new blocks is, if you like, a random variable with an exponential distribution. You can, in principle, estimate the rate parameter for this distribution using the difficulty and the timestamps in the Bitcoin log, but it's not straightforward. The last time I got into it, I was halfway through building a Bayesian estimator for the rate parameter using the log before I had to give up and move on to real work. I'll do it soon.

I don't see how a hash (as a token of bitcoin work) would be anything other than unique (for the result to be useful to me it has to include my address in the input).

In what applications would the likely immediate hash rate be more useful than the historical average hash rate? I guess the obvious one is turning some bit of mining hardware on and off.

Reply on news.ycombinator.com