<p>SHA256 uses a compression function that maps a 64 byte input block and a 32 byte chaining state to the next chaining state. It divides the message into 64 byte blocks and hashes those sequentially.</p>

<p>The bitcoin proof of work uses <code>SHA256(SHA256(block_header))</code>. Between each hashing attempt only 4 bytes in the last block of the header change, so for each hashing attempt you only need to compress that last block of the message and then one compression for the outer hash.</p>

<p>So one bitcoin hash corresponds to two SHA-256 compressions. In definition of "Hash/s" says how many nonces can be evaluated per second which is a meaningful definition in this context.</p>

<p>The header contains the (root of a tree)hash of the actual block. But since the actual block only changes every 4 billion nonces, the cost up updating it is small compared to the cost of hashing the header. That's why it's neglected in those performance claims.</p>

<p>To compare different hardware you need to use miners specialized for that hardware. There are CPU, GPU, FPGA and ASIC based miners. <a href="https://en.bitcoin.it/wiki/Mining_hardware_comparison" rel="nofollow">Mining hardware comparison on the bitcoin wiki</a> lists the performance of many different kinds of hardware. Nowadays only ASIC is competitive, for other kinds of hardware the cost of buying and electricity exceeds the earned bitcoins.</p>

CC BY-SA 3.0
2014-04-30T19:12:54.480Z
It's worth emphasizing that the data to be hashed repeatedly is the block header alone, which is always 80 bytes.  See also https://en.bitcoin.it/wiki/Block_hashing_algorithm.  The "hashes per second" statistics are understood to assume such 80-byte inputs, such that the only work to be done between hashes is to increment the nonce.
Nate Eldredge
CC BY-SA 3.0
2014-04-30T08:20:52.923Z
2014-04-30T08:27:11.273Z
CodesInChaos
<p>Computing preimages (nonces) that satisfy a hash output with known property (minimum number of prefixed zeroes) is the foundation of bit-coin mining and block-chain validation. For this purpose, all available hardware, whether general purpose PCs and servers or custom ASICs that specifically target bitcoin mining, is rated for performance in terms of "Hashes/sec, Mega Hashes/Sec, or Giga Hashes/Sec". </p>

<p>Without specifying the length of the data  that is hashed, I find this rating of HW in terms of 'Hashes/Sec' to be vague at best. All hashing algorithms input messages of arbitrary length  and computed an fixed length message digest. So, a processing power that performs a "million hashes per second" over input blocks of length 100 bytes is not quite the same of another HW that can perform 'million hashes per second' with input blocks where the block length is 4 kilo bytes. </p>

<p>Questions:</p>

<ol>
<li><p>What does it mean to say 'my HW can perform x hashes/sec'? Does each 'hash' refer to the block size of SHA256 algorithm, which is 512 bits? </p></li>
<li><p>Or, does a hash refer to hashing a block chain, whose length is highly variable subject to the transactions that define a block-chain? </p></li>
<li><p>Is there is a well known benchmark program that can measure the 'hashes/sec' supported by any piece of HW? </p></li>
</ol>

<p>Without clarifying the above details &amp; publishing a benchmark that everyone can look up to, vendors' claims of "Hashes/Sec" seems like a marketing ploy to me. </p>

<p>[Added Later]
I have a further question on the details of how a valid nonce is searched. As I understand it, the search is determined by 3 parameters</p>

<p>(a) The block header
(b) target string
(c) nonce</p>

<p>A representative pseudo code that searches for the nonce can be written as:</p>

<p><strong>while</strong> (hash_256(hash_256(block_header, nonce) >= target_string) <strong>do</strong></p>

<pre><code>      nonce = nonce + 1
</code></pre>

<p><strong>end_while</strong></p>

<p>I have modeled the above pseudo code from this <a href="http://www.righto.com/2014/02/bitcoin-mining-hard-way-algorithms.html" rel="nofollow">blog</a> of Ken Schriff. It is not clear how this code models the 'difficulty' parameter. Above loop (as well as the one found in the <a href="http://www.righto.com/2014/02/bitcoin-mining-hard-way-algorithms.html" rel="nofollow">blog</a>) iterates through all nonce values from 0 through (2^32-1). Or, exactly 4 billion iterations of the hash function. Even a PC with a 12 year old Pentium 4 CPU that performs at 1 MHashes/Sec (cf. <a href="https://en.bitcoin.it/wiki/Mining_hardware_comparison" rel="nofollow">Mining Hardware Comparison</a>) can crack this in 4000 seconds, or in about an hour. Custom ASICs with GHashes/sec performance will crack it in a second. </p>

<p>What is the correction needed to reflect the 'difficulty' parameter in this pseudocode? Does the size of the nonce have to be related to the difficulty ?</p>

CC BY-SA 3.0
2014-05-08T23:49:54.403Z
Ask a new question instead of editing an existing. Here is the difficulty:  >= target_string.  There is no guarantee that a solution will be found in any of the 2^32 nonces (in fact most likely not).
Jannes
<performance>
Bitcoin Performance: What does Hashes/Second Mean?
user13311
# Bitcoin Performance: What does Hashes/Second Mean?

(Asked by: username_0 on 2014-04-30)

Computing preimages (nonces) that satisfy a hash output with known property (minimum number of prefixed zeroes) is the foundation of bit-coin mining and block-chain validation. For this purpose, all available hardware, whether general purpose PCs and servers or custom ASICs that specifically target bitcoin mining, is rated for performance in terms of "Hashes/sec, Mega Hashes/Sec, or Giga Hashes/Sec".

Without specifying the length of the data that is hashed, I find this rating of HW in terms of 'Hashes/Sec' to be vague at best. All hashing algorithms input messages of arbitrary length and computed an fixed length message digest. So, a processing power that performs a "million hashes per second" over input blocks of length 100 bytes is not quite the same of another HW that can perform 'million hashes per second' with input blocks where the block length is 4 kilo bytes.

Questions:

1. What does it mean to say 'my HW can perform x hashes/sec'? Does each 'hash' refer to the block size of SHA256 algorithm, which is 512 bits?
2. Or, does a hash refer to hashing a block chain, whose length is highly variable subject to the transactions that define a block-chain?
3. Is there is a well known benchmark program that can measure the 'hashes/sec' supported by any piece of HW?

Without clarifying the above details & publishing a benchmark that everyone can look up to, vendors' claims of "Hashes/Sec" seems like a marketing ploy to me.

[Added Later]
I have a further question on the details of how a valid nonce is searched. As I understand it, the search is determined by 3 parameters

(a) The block header
(b) target string
(c) nonce

A representative pseudo code that searches for the nonce can be written as:

**while** (hash\_256(hash\_256(block\_header, nonce) >= target\_string) **do**

```
      nonce = nonce + 1

```

**end\_while**

I have modeled the above pseudo code from this [blog](http://www.righto.com/2014/02/bitcoin-mining-hard-way-algorithms.html) of Ken Schriff. It is not clear how this code models the 'difficulty' parameter. Above loop (as well as the one found in the [blog](http://www.righto.com/2014/02/bitcoin-mining-hard-way-algorithms.html)) iterates through all nonce values from 0 through (2^32-1). Or, exactly 4 billion iterations of the hash function. Even a PC with a 12 year old Pentium 4 CPU that performs at 1 MHashes/Sec (cf. [Mining Hardware Comparison](https://en.bitcoin.it/wiki/Mining_hardware_comparison)) can crack this in 4000 seconds, or in about an hour. Custom ASICs with GHashes/sec performance will crack it in a second.

What is the correction needed to reflect the 'difficulty' parameter in this pseudocode? Does the size of the nonce have to be related to the difficulty ?

**Tags:** performance

> **Comments:**
> **username_1**: Ask a new question instead of editing an existing. Here is the difficulty:  >= target_string.  There is no guarantee that a solution will be found in any of the 2^32 nonces (in fact most likely not).  

---

## 1 answers

### Answer by username_2 on 2014-04-30. Score: 4

SHA256 uses a compression function that maps a 64 byte input block and a 32 byte chaining state to the next chaining state. It divides the message into 64 byte blocks and hashes those sequentially.

The bitcoin proof of work uses `SHA256(SHA256(block_header))`. Between each hashing attempt only 4 bytes in the last block of the header change, so for each hashing attempt you only need to compress that last block of the message and then one compression for the outer hash.

So one bitcoin hash corresponds to two SHA-256 compressions. In definition of "Hash/s" says how many nonces can be evaluated per second which is a meaningful definition in this context.

The header contains the (root of a tree)hash of the actual block. But since the actual block only changes every 4 billion nonces, the cost up updating it is small compared to the cost of hashing the header. That's why it's neglected in those performance claims.

To compare different hardware you need to use miners specialized for that hardware. There are CPU, GPU, FPGA and ASIC based miners. [Mining hardware comparison on the bitcoin wiki](https://en.bitcoin.it/wiki/Mining_hardware_comparison) lists the performance of many different kinds of hardware. Nowadays only ASIC is competitive, for other kinds of hardware the cost of buying and electricity exceeds the earned bitcoins.

> **Comments:**
> **username_3**: It's worth emphasizing that the data to be hashed repeatedly is the block header alone, which is always 80 bytes.  See also https://en.bitcoin.it/wiki/Block_hashing_algorithm.  The "hashes per second" statistics are understood to assume such 80-byte inputs, such that the only work to be done between hashes is to increment the nonce.  

---

