<p><strong>No correlation</strong> between <em>any</em> input bit or combination of bits and <em>any</em> output bit or combination is acceptable for any cryptographic hash. SHA256 is an accepted cryptographic hash.</p>

<p>Anyone can (and many do) <strong>verify</strong> a valid block by doing one hash operation, rather than the huge number it takes to find by brute-force, currently on the order of 1,000,000,000,000,000,000,000.</p>

<p>EDIT: I somehow computed 4 bits per byte not 8 (BIG difference), plus forgot the prevhash prefix. Corrected and also clarified some.</p>

<p>In addition to nonce, miners can tweak a few bits in time and use maybe 20-40 bits worth of choice in the Merkle root (by changing extranonce and/or transactions) in the time available. Plus part of prevhash is always the same (namely zeros) -- at least as long as the database 'shortcut' doesn't work, and it doesn't. Let's call it <strike>80</strike> 160 bits total, meaning <strong>a complete database would be about <strike>2^{240}</strike> 2^{480} entries</strong>. But we can't store that much, especially not since it must be accessed in significantly less than the normal mining time of 10 minutes. And since we can't know in advance <em>which</em> entries will be needed, no matter what subset of the database we store it's a "roll of the dice" for each block header whether it is in the database and thus "pre-mined".</p>

<p>If you use all of the roughly 2^{190} atoms in the Solar System (and move them close enough) and can store one header per atom which is many thousands of times denser than any known storage technology, your database will 'hit' (contain the desired solution) with probability one in 2^{290} which (since trials are independent) will occur for (rounding slightly) about one block every <strike>20,000,000,000</strike> 20,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years, which is <strike>probably</strike> almost certainly longer than the universe will exist. (And certainly not often enough for you to make any profit from it.)</p>

<p>See also <a href="https://crypto.stackexchange.com/questions/1013/is-it-feasible-to-build-an-index-of-prime-factors">https://crypto.stackexchange.com/questions/1013/is-it-feasible-to-build-an-index-of-prime-factors</a> for several discussions why a similar approach for breaking RSA is ludicrously infeasible even <em>without</em> the short time limit needed for Bitcoin.</p>

CC BY-SA 3.0
2016-09-08T12:01:32.363Z
You almost went a little Douglas Adams there at the end. What do you mean with `will 'hit' about one block per...`. You mean when you would try to brute force it?
BlockChange
CC BY-SA 3.0
2016-09-11T04:29:37.707Z
@BlockChange thanks for drawing me back to this -- I realized my numbers were much too optimistic. Corrected and expanded a bit to explain what I mean by hit.
dave_thompson_085
CC BY-SA 3.0
2016-09-08T11:50:03.300Z
2016-09-11T04:28:43.693Z
2017-04-13T12:48:25.933Z
dave_thompson_085
<p>What exactly prevents a miner from presenting a random <code>nonce hash</code> of the block with enough <code>zeroes</code> at the start to get chosen?</p>

<p>How is the <code>new hash</code> verified by the other nodes? Since as I understand there is no 1 valid hash outcome, but multiple? What are the conditions other than having a <code>number of zeroes</code> at the start?</p>

<p>Instead of incrementing the <code>nonce</code>, could you intelligently pick a random higher <code>nonce</code> and see the amount of leading zeroes increase? Or is there never any direct relation between the nonce value and the resulting hash? (Probably, but I need to have this confirmed)</p>

<p>Mainly, what prevents a miner from having a pre-calculated database of sufficiently difficult but random nonces/hashes that <em>could</em> be presented instantly and <em>could</em> be accepted? </p>

<p>If the new hash only has to be <code>equal or lower</code> than the <code>target</code>? How do you verify that work has been done, without doing the same work yourself?</p>

CC BY-SA 3.0
2016-09-08T12:05:38.227Z
You might find [What are bitcoin miners really solving?](http://bitcoin.stackexchange.com/q/8031/5406) an interesting read.
Murch
<proof-of-work><nonce>
What prevents a miner from faking nonce hash
BlockChange
# What prevents a miner from faking nonce hash

(Asked by: username_0 on 2016-09-08)

What exactly prevents a miner from presenting a random `nonce hash` of the block with enough `zeroes` at the start to get chosen?

How is the `new hash` verified by the other nodes? Since as I understand there is no 1 valid hash outcome, but multiple? What are the conditions other than having a `number of zeroes` at the start?

Instead of incrementing the `nonce`, could you intelligently pick a random higher `nonce` and see the amount of leading zeroes increase? Or is there never any direct relation between the nonce value and the resulting hash? (Probably, but I need to have this confirmed)

Mainly, what prevents a miner from having a pre-calculated database of sufficiently difficult but random nonces/hashes that *could* be presented instantly and *could* be accepted?

If the new hash only has to be `equal or lower` than the `target`? How do you verify that work has been done, without doing the same work yourself?

**Tags:** proof-of-work, nonce

> **Comments:**
> **username_1**: You might find [What are bitcoin miners really solving?](http://bitcoin.stackexchange.com/q/8031/5406) an interesting read.  

---

## 1 answers

### Answer by username_2 on 2016-09-08. Score: 2

**No correlation** between *any* input bit or combination of bits and *any* output bit or combination is acceptable for any cryptographic hash. SHA256 is an accepted cryptographic hash.

Anyone can (and many do) **verify** a valid block by doing one hash operation, rather than the huge number it takes to find by brute-force, currently on the order of 1,000,000,000,000,000,000,000.

EDIT: I somehow computed 4 bits per byte not 8 (BIG difference), plus forgot the prevhash prefix. Corrected and also clarified some.

In addition to nonce, miners can tweak a few bits in time and use maybe 20-40 bits worth of choice in the Merkle root (by changing extranonce and/or transactions) in the time available. Plus part of prevhash is always the same (namely zeros) -- at least as long as the database 'shortcut' doesn't work, and it doesn't. Let's call it 80 160 bits total, meaning **a complete database would be about 2^{240} 2^{480} entries**. But we can't store that much, especially not since it must be accessed in significantly less than the normal mining time of 10 minutes. And since we can't know in advance *which* entries will be needed, no matter what subset of the database we store it's a "roll of the dice" for each block header whether it is in the database and thus "pre-mined".

If you use all of the roughly 2^{190} atoms in the Solar System (and move them close enough) and can store one header per atom which is many thousands of times denser than any known storage technology, your database will 'hit' (contain the desired solution) with probability one in 2^{290} which (since trials are independent) will occur for (rounding slightly) about one block every 20,000,000,000 20,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years, which is probably almost certainly longer than the universe will exist. (And certainly not often enough for you to make any profit from it.)

See also <https://crypto.stackexchange.com/questions/1013/is-it-feasible-to-build-an-index-of-prime-factors> for several discussions why a similar approach for breaking RSA is ludicrously infeasible even *without* the short time limit needed for Bitcoin.

> **Comments:**
> **username_0**: You almost went a little Douglas Adams there at the end. What do you mean with `will 'hit' about one block per...`. You mean when you would try to brute force it?  
> **username_2**: @username_0 thanks for drawing me back to this -- I realized my numbers were much too optimistic. Corrected and expanded a bit to explain what I mean by hit.  

---

