user119103: How does a blockchain verify that the hash provided (the one with the leading zeros that is supposed to be unique, computed using lots of processing power) is indeed unique and that it wasn't just a random number some one came up with and then just added the expected leading zeros to it?

user113254: The hash of a block is not simply a unique string; rather, it is a unique string generated using a hashing function.
A hashing function is a one-way algorithm that cannot be reversed. Due to this, in order to generate a desired output, you have no choice but to modify your desired input over and over until you find one that works.
This is the process of mining, where computers (1) take transaction data, (2) modify a small part of it and (3) generate billions of hashes per second in an attempt to find a given small modification that, taken in conjunction with the rest of the transaction data, will generate a hash with X amount of zeros.
Now that the hash has been generated, the full transaction data along with the nonce can be submitted to the BTC network. Although it took an unfathomable number of tries to find the correct nonce - to "reverse" the one-way hashing function, it is trivial to verify it by simply passing it and the transaction data through the hashing function.

user5406: A block is valid when:

its hash is lower than the difficulty
it only includes valid transactions

The hash is produced from the 80-byte blockheader. The resulting hash is then interpreted as a number to compare it to the difficulty target.
It is difficult to find a block whose header meets the difficulty: the Bitcoin network currently is currently about 163 EH/s, i.e. globally there are 163 quintillion attempts per second to find a valid every ten minutes in average.
On the other hand, it is trivial to recognize a made-up solution. The successful miner must provide the complete blockheader in their announcement. Its peers simply repeat the hash calculation from the blockheader to verify that the block meets the difficulty. Only then do peers check that the remaining content of the block is valid as well. If the block is valid, they relay the block to their peers in turn. Otherwise, they discard it (and in some cases drop the peer that provided the invalid data).

user109555: @Sprout Coder The winning miner does not supply the hash to the network to be verified. He supplies the block. The first 80 bytes of a Bitcoin block are the block header. The block is not valid if the hash of the header is greater than the target hash. The miners hash the 80-byte header repeatedly, making a small change each time. When a miner finds a header which has a hash which is small enough, he sends the entire block to one or more Bitcoin nodes. If the block is not valid, the nodes drop it, and do not propagate it to their neighbours

user112077: 
How does a blockchain verify

Blockchains do not verify anything; the network does. But blockchains can be used to verify things (in fact, that is the whole point of them).

that the hash provided (the one with the leading zeros that is supposed to be unique …) is indeed unique

Hashes are unique, by definition, in the sense that each block header has exactly one hash.
If by “unique”, you mean “different to every other block”, then:

This is not explicitly part of Bitcoin’s rules.
Even if it were, it would be trivial to verify, at least compared to all the other calculations required to verify the blockchain.
This is virtually guaranteed to be the case anyway, because a good hash function like the one used by Bitcoin (SHA256) makes it virtually impossible to find two values with the same hash.

“Unique” is probably not the right word for this question.

that the hash provided (the one … computed using lots of processing power)

The hashes used by Bitcoin are easy to compute (and therefore easy to verify). The difficulty comes in finding a block header whose hash is less than the target value.

and that it wasn't just a random number some one came up with and then just added the expected leading zeros to it?

No one can verify where the provided hash came from, and it does not matter. All that matters is that:

It is in fact the hash of the provided header.
It is less than the target value.


user13866: Because

Everyone can quickly use the transaction data to re-calculate the hash and check that it matches and is less than the target value.

Computing the hash is not what takes time, it is altering the transactions details (e.g. the "nonce" value) until you find an arrangement that hashes to a value less than the target. On average this takes an enormous number of attempts, altering the transaction data a little between each attempt. It therefore takes an enormous number of calculations of the hash. But only the last calculation needs to be verified, not the vast amount of failed attempts.



user119121: A Hash Function maps "data of arbitrary size to fixed-size values". As an incredibly simple hash, consider a function only works on numbers and simply returns the last 3 (decimal) digits (ie., the 1s, 10s, and 100s places).
Using this simple hash, 5 would hash to 005, and 123,456 would hash to 456.
A Bitcoin block contains a handful of fields (source):

Version
Previous block hash
Merkle root
Time stamp
Difficulty bits
Nonce

All of those can be represented by numbers (the time stamp is Unix time (source), which means it's basically the number of seconds since 00:00:00 UTC on 1 January 1970).
Of those values, only the nonce can be freely changed without invalidating the block. The timestamp can take a range of values (roughly "1 hour ago" to "2 hours from now" (source)), and the version number has a great deal of flexibility (ibid). I'll focus on the nonce since that's the easiest for me to talk about.
Proof of work, in this simplified scenario, is accomplished by adding all of those numbers together and finding a nonce that results in the hash being 000. In this simplified scenario, that's trivial to do: you can just add the other numbers together, hash that partial sum, then set the nonce to 1,000 - that partial hash. So, it's not a very good hashing algorithm for this purpose.
Instead, Bitcoin uses SHA256. SHA256 has a couple of advantages which stem from its being a cryptographic hash function; the big three are that calculating the SHA256 hash of a given value is "cheap" but generating a value that will produce a given SHA256 hash is hard, and that tiny changes in the input will produce large changes in the output (the avalanche effect).
In fact, to the best of our collective knowledge, the only way to generate an input that produces a given SHA256 hash is to keep trying inputs until you find one that works.
So: unlike the simple hash at the beginning, we can't figure out what the nonce should be just by looking at the rest of the data. And, we can't just tweak the nonce to get the hash we want: the avalanche effect means that every small change to the input will have large changes to the output. Therefore, the only way to find a nonce that produces a valid SHA256 hash is to start at 0 and work up 'til a suitable nonce is found.
Once a suitable nonce is found, anyone can verify that the nonce/hash pair is valid by hashing the block with that nonce and seeing that the hash matches. This check can be done very quickly, and serves to prove that whoever found that nonce did the work.
The nonce is a 32-bit integer (source), which means that there are 4,294,967,295 (just under 4.3 billion) possible nonces. Compare that to the Powerball lottery, in which a single ticket has about a 1-in-300,000,000 chance of winning the jackpot, and it becomes clear how unlikely a randomly-chosen nonce is to be valid; even if there were thousands of nonces that could produce a SHA256 hash with enough leading zeroes, picking nonces at random would still be staggeringly unlikely.
Then, the time can take any value in a roughly 3-hour window and has second-resolution, so there are ~10,800 values it can take. The version has some limits, but it appears to be another 4-bit integer like the nonce; for rough calculations' sake, let's say it can take half of the possible values that the nonce can. That means that there are around 9e+22 (a 9 followed by 22 zeroes) possible combinations. There are about 200 billion stars in the milky way (source); that is, 200,000,000,000 or 2e+11. Finding a correct header randomly had odds in the realm of two people randomly choosing the same grain of sand from the whole of the galaxy.

119103: <p>How does a blockchain verify that the hash provided (the one with the leading zeros that is supposed to be unique, computed using lots of processing power) is indeed unique and that it wasn't just a random number some one came up with and then just added the expected leading zeros to it?</p>
 113254: <p>The hash of a block is not simply a unique string; rather, it is a unique string generated using a hashing function.</p>
<p>A hashing function is a one-way algorithm that cannot be reversed. Due to this, in order to generate a desired output, you have no choice but to modify your desired input over and over until you find one that works.</p>
<p>This is the process of mining, where computers (1) take transaction data, (2) modify a small part of it and (3) generate billions of hashes per second in an attempt to find a given small modification that, taken in conjunction with the rest of the transaction data, will generate a hash with X amount of zeros.</p>
<p>Now that the hash has been generated, the full transaction data along with the nonce can be submitted to the BTC network. Although it took an unfathomable number of tries to find the correct nonce - to &quot;reverse&quot; the one-way hashing function, it is trivial to verify it by simply passing it and the transaction data through the hashing function.</p>
 5406: <p>A block is valid when:</p>
<ul>
<li>its hash is lower than the difficulty</li>
<li>it only includes valid transactions</li>
</ul>
<p>The hash is produced from the 80-byte blockheader. The resulting hash is then interpreted as a number to compare it to the difficulty target.</p>
<p>It is difficult to find a block whose header meets the difficulty: the Bitcoin network currently is currently about 163 EH/s, i.e. globally there are 163 quintillion attempts per second to find a valid every ten minutes in average.</p>
<p>On the other hand, it is trivial to recognize a made-up solution. The successful miner must provide the complete blockheader in their announcement. Its peers simply repeat the hash calculation from the blockheader to verify that the block meets the difficulty. Only then do peers check that the remaining content of the block is valid as well. If the block is valid, they relay the block to their peers in turn. Otherwise, they discard it (and in some cases drop the peer that provided the invalid data).</p>
 109555: <p>@Sprout Coder The winning miner does not supply the hash to the network to be verified. He supplies the block. The first 80 bytes of a Bitcoin block are the block header. The block is not valid if the hash of the header is greater than the target hash. The miners hash the 80-byte header repeatedly, making a small change each time. When a miner finds a header which has a hash which is small enough, he sends the entire block to one or more Bitcoin nodes. If the block is not valid, the nodes drop it, and do not propagate it to their neighbours</p>
 112077: <blockquote>
<p>How does a blockchain verify</p>
</blockquote>
<p>Blockchains do not verify anything; the network does. But blockchains can be <em>used</em> to verify things (in fact, that is the whole point of them).</p>
<blockquote>
<p>that the hash provided (the one with the leading zeros that is supposed to be unique …) is indeed unique</p>
</blockquote>
<p>Hashes <em>are</em> unique, by definition, in the sense that each block header has exactly one hash.</p>
<p>If by “unique”, you mean “different to every other block”, then:</p>
<ol>
<li>This is not explicitly part of Bitcoin’s rules.</li>
<li>Even if it were, it would be trivial to verify, at least compared to all the other calculations required to verify the blockchain.</li>
<li>This is virtually guaranteed to be the case anyway, because a good hash function like the one used by Bitcoin (SHA256) makes it virtually impossible to find two values with the same hash.</li>
</ol>
<p>“Unique” is probably not the right word for this question.</p>
<blockquote>
<p>that the hash provided (the one … computed using lots of processing power)</p>
</blockquote>
<p>The hashes used by Bitcoin are easy to compute (and therefore easy to verify). The difficulty comes in finding a block header whose hash is less than the target value.</p>
<blockquote>
<p>and that it wasn't just a random number some one came up with and then just added the expected leading zeros to it?</p>
</blockquote>
<p>No one can verify where the provided hash came from, and it does not matter. All that matters is that:</p>
<ol>
<li>It is in fact the hash of the provided header.</li>
<li>It is less than the target value.</li>
</ol>
 13866: <p>Because</p>
<ol>
<li><p>Everyone can quickly use the transaction data to re-calculate the hash and check that it matches and is less than the target value.</p>
</li>
<li><p>Computing the hash is not what takes time, it is altering the transactions details (e.g. the &quot;nonce&quot; value) until you find an arrangement that hashes to a value less than the target. On average this takes an enormous number of attempts, altering the transaction data a little between each attempt. It therefore takes an enormous number of calculations of the hash. But only the last calculation needs to be verified, not the vast amount of failed attempts.</p>
</li>
</ol>
 119121: <p>A <a href="https://en.wikipedia.org/wiki/Hash_function" rel="nofollow noreferrer">Hash Function</a> maps &quot;data of arbitrary size to fixed-size values&quot;. As an incredibly simple hash, consider a function only works on numbers and simply returns the last 3 (decimal) digits (ie., the 1s, 10s, and 100s places).</p>
<p>Using this simple hash, <code>5</code> would hash to <code>005</code>, and <code>123,456</code> would hash to <code>456</code>.</p>
<p>A Bitcoin block contains a handful of fields (<a href="https://medium.com/hackergirl/how-to-calculate-the-hash-of-a-block-in-bitcoin-8f6aebb0dc6d" rel="nofollow noreferrer">source</a>):</p>
<ul>
<li>Version</li>
<li>Previous block hash</li>
<li>Merkle root</li>
<li>Time stamp</li>
<li>Difficulty bits</li>
<li>Nonce</li>
</ul>
<p>All of those can be represented by numbers (the time stamp is <a href="https://en.wikipedia.org/wiki/Unix_time" rel="nofollow noreferrer">Unix time</a> (<a href="https://en.bitcoin.it/wiki/Block_timestamp" rel="nofollow noreferrer">source</a>), which means it's basically the number of seconds since 00:00:00 UTC on 1 January 1970).</p>
<p>Of those values, only the nonce can be freely changed without invalidating the block. The timestamp can take a range of values (roughly &quot;1 hour ago&quot; to &quot;2 hours from now&quot; (<a href="https://bitcoin.stackexchange.com/a/90396/119121">source</a>)), and the version number has a great deal of flexibility (<a href="https://bitcoin.stackexchange.com/a/90396/119121">ibid</a>). I'll focus on the nonce since that's the easiest for me to talk about.</p>
<p>Proof of work, in this simplified scenario, is accomplished by adding all of those numbers together and finding a nonce that results in the hash being <code>000</code>. In this simplified scenario, that's trivial to do: you can just add the other numbers together, hash that partial sum, then set the nonce to 1,000 - that partial hash. So, it's not a very good hashing algorithm for this purpose.</p>
<p>Instead, Bitcoin uses <a href="https://en.wikipedia.org/wiki/SHA-2" rel="nofollow noreferrer">SHA256</a>. SHA256 has a couple of advantages which stem from its being a <a href="https://en.wikipedia.org/wiki/Cryptographic_hash_function" rel="nofollow noreferrer">cryptographic hash function</a>; the big three are that calculating the SHA256 hash of a given value is &quot;cheap&quot; but generating a value that will produce a given SHA256 hash is <em>hard</em>, and that tiny changes in the input will produce large changes in the output (<a href="https://en.wikipedia.org/wiki/Avalanche_effect" rel="nofollow noreferrer">the avalanche effect</a>).</p>
<p>In fact, to the best of our collective knowledge, the only way to generate an input that produces a given SHA256 hash is to keep trying inputs until you find one that works.</p>
<p>So: unlike the simple hash at the beginning, we can't figure out what the nonce should be just by looking at the rest of the data. And, we can't just tweak the nonce to get the hash we want: the avalanche effect means that every small change to the input will have large changes to the output. Therefore, the only way to find a nonce that produces a valid SHA256 hash is to start at 0 and work up 'til a suitable nonce is found.</p>
<p>Once a suitable nonce is found, anyone can verify that the nonce/hash pair is valid by hashing the block with that nonce and seeing that the hash matches. This check can be done very quickly, and serves to prove that whoever found that nonce did the work.</p>
<p>The nonce is a 32-bit integer (<a href="https://en.bitcoin.it/wiki/Nonce" rel="nofollow noreferrer">source</a>), which means that there are 4,294,967,295 (just under 4.3 billion) possible nonces. Compare that to the <a href="https://en.wikipedia.org/wiki/Powerball" rel="nofollow noreferrer">Powerball</a> lottery, in which a single ticket has about a 1-in-300,000,000 chance of winning the jackpot, and it becomes clear how unlikely a randomly-chosen nonce is to be valid; even if there were thousands of nonces that could produce a SHA256 hash with enough leading zeroes, picking nonces at random would still be staggeringly unlikely.</p>
<p>Then, the time can take any value in a roughly 3-hour window and has second-resolution, so there are ~10,800 values it can take. The version has some limits, but it appears to be another 4-bit integer like the nonce; for rough calculations' sake, let's say it can take half of the possible values that the nonce can. That means that there are around 9e+22 (a 9 followed by 22 zeroes) possible combinations. There are about 200 billion stars in the milky way (<a href="https://en.wikipedia.org/wiki/Milky_Way" rel="nofollow noreferrer">source</a>); that is, 200,000,000,000 or 2e+11. Finding a correct header randomly had odds in the realm of two people randomly choosing the same grain of sand from the whole of the galaxy.</p>
