<blockquote>
<p>Modern miners on the market have up to 110 TH/s. Is this the true hash rate (singular SHA-256 hashes per second) or the net hashes relating to Bitcoin specifically (since Bitcoin involves double hashes 'SHA256(SHA256(x))'.</p>
</blockquote>
<p>It refers to the number of block hash candidates the miners can try per second. While you can think of those as double SHA256, that is actually very far from what the hardware does.</p>
<p>It doesn't actually compute two hashes, in the sense that:</p>
<ul>
<li>it cannot take as input anything but a block header (with some specific structure, of which some parts are precomputed, in the case of ASICBoost),</li>
<li>it doesn't output the result of the first hash,</li>
<li>it doesn't actually even compute the full second hash result (only whether or not it has a certain number of zero bits up front)</li>
</ul>
<blockquote>
<p>If so, that would set its true hash rate of 220TH/s.</p>
</blockquote>
<p>You could say that, but it's a meaningless metric. The hardware cannot actually perform 220 tera-SHA256's per second, for the reasons above.</p>
<p>The only thing it can do is try 110 tera-Bitcoin-block-candidates per second.</p>

CC BY-SA 4.0
2022-12-15T07:55:35.073Z
do you have some details about HW optimizations for hashes with leading zeros? Do mining HW implementations take advantage of the fact that for valid proof of work block hashes the first N bits are zero? If they skip part of the second hash computation they can save a few % of transistor and thus have better efficiency. Or do they actually compute only the first N bits to be able to decide if they have certain number of zeroes?
OptOut
CC BY-SA 4.0
2022-12-15T14:13:25.387Z
I stopped paying attention to mining internals probably somewhere around 2011, but even back then, (GPU) mining implementations had lots of optimizations to skip bits of computation here and there. I can only imagine that's become a lot of extensive since then. ASICBoost is one particular impactful example.
Pieter Wuille
CC BY-SA 4.0
2022-12-14T05:08:14.747Z
2022-12-14T16:37:13.473Z
2022-12-14T16:37:13.473Z
Pieter Wuille
<p>Modern miners on the market have up to 110 TH/s. Is this the true hash rate (singular SHA-256 hashes per second) or the net hashes relating to Bitcoin specifically (since Bitcoin involves double hashes 'SHA256(SHA256(x))'. If so, that would set its true hash rate of 220TH/s.</p>
<p>Thanks</p>

<hash><mining-hardware><sha256>
Are miners advertised hash rate single or double hash speeds?
Matt Tainsh
# Are miners advertised hash rate single or double hash speeds?

(Asked by: username_0 on 2022-12-14)

Modern miners on the market have up to 110 TH/s. Is this the true hash rate (singular SHA-256 hashes per second) or the net hashes relating to Bitcoin specifically (since Bitcoin involves double hashes 'SHA256(SHA256(x))'. If so, that would set its true hash rate of 220TH/s.

Thanks

**Tags:** hash, mining-hardware, sha256


---

## 1 answers

### Answer by username_1 on 2022-12-14. Score: 8

> Modern miners on the market have up to 110 TH/s. Is this the true hash rate (singular SHA-256 hashes per second) or the net hashes relating to Bitcoin specifically (since Bitcoin involves double hashes 'SHA256(SHA256(x))'.

It refers to the number of block hash candidates the miners can try per second. While you can think of those as double SHA256, that is actually very far from what the hardware does.

It doesn't actually compute two hashes, in the sense that:

* it cannot take as input anything but a block header (with some specific structure, of which some parts are precomputed, in the case of ASICBoost),
* it doesn't output the result of the first hash,
* it doesn't actually even compute the full second hash result (only whether or not it has a certain number of zero bits up front)

> If so, that would set its true hash rate of 220TH/s.

You could say that, but it's a meaningless metric. The hardware cannot actually perform 220 tera-SHA256's per second, for the reasons above.

The only thing it can do is try 110 tera-Bitcoin-block-candidates per second.

> **Comments:**
> **username_2**: do you have some details about HW optimizations for hashes with leading zeros? Do mining HW implementations take advantage of the fact that for valid proof of work block hashes the first N bits are zero? If they skip part of the second hash computation they can save a few % of transistor and thus have better efficiency. Or do they actually compute only the first N bits to be able to decide if they have certain number of zeroes?  
> **username_1**: I stopped paying attention to mining internals probably somewhere around 2011, but even back then, (GPU) mining implementations had lots of optimizations to skip bits of computation here and there. I can only imagine that's become a lot of extensive since then. ASICBoost is one particular impactful example.  

---

