How does a blockchain relying on PoW verify that a hash is computed using an algorithm and not made up by a human?

Question

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?

Answer 1

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:

1. This is not explicitly part of Bitcoin’s rules.
2. Even if it were, it would be trivial to verify, at least compared to all the other calculations required to verify the blockchain.
3. 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:

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

Answer 2

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.

Answer 3

Because

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

2. 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.

Answer 4

@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

Answer 5

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).

Answer 6

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.

Answer 7

It doesn't matter who/what made the hash up, as long as it works correctly for the given hashing function.

Let's say you manually packed a block together in notepad, randomly thought of a number in your head and tagged the block with the hash you just dreamed up, and let's just say you're the luckiest person in the universe and you just so happen to have packed a block in that way so that it does indeed hash to the exact number you dreamed up in your head (the odds of this are incredibly, incredibly, incredibly unlikely but not absolutely impossible) - congrats, you won this round of the competition; someone else on the network will take the block you assembled, hash it according to the network-wide accepted algorithm, get the exact same number you dreamt up, and bingo - it's proven. Your solution works! You get the block reward and your block becomes incorporated into the blockchain

The kicker is, the "incredibly, incredibly, incredibly unlikely" part that you'll get the maths so exactly bang on that when you exclaim to the world "I have this block like ABCDEF, and I hashed it to 00123 which is valid and works and less than the difficulty so give me the reward". The rest of the network will go "er, no, actually block ABCDEF hashes to 00255 which isn't right" - the chance that this will happen (that your made-up hash is wrong) is billions and billions of times more likely

You have to appreciate that a mining machine will have a bunch of transactions and other fluff that it can pack together in a block, and it can hash it - gets the result 200 (imagine it is looking for less than 100), which is higher than the difficulty, so it makes some tweaks, hash again, gets 250, tweak, hash get 199, tweak/hash/tweak/hash.. it does this literally billions of times a second and eventually, maybe it will get a result that it less than 100 - it can now announce the block and others will verify it

If it(or you) just made up the hash and announced it as the winner, it's so incredibly unlikely to be right that it probably isn't a win and won't be accepted by the network. It'd like you buying a lottery ticket with losing numbers, then running round shouting "I won the lottery! I picked 1,2,3,4,5,6 and the numbers last night were 1,2,3,4,5,6, give me the millions!" and everyone goes "no, last night's numbers were 1,4,7,22,38,49.. go away"

Answer 8

Calculating the hash given known values is trivially easy. How mining works is that you have to take transaction details and come up with a value (nonce) that will make the hash fit into a predefined range. Currently with bitcoin you need to have some value and compute a hash with 18 leading 0s to 'mine' a coin.

To compute the hash you take transaction details and add in some special sauce and compute a hash. If the hash has 18 leading zeros, you are on your way to mining a bitcoin. You give your special value and your hash to the network and if enough other miners agree, it becomes part of the blockchain. Other miners accept your hash and start computing new hashes with new transactions and their own nonces to get the next hash.

If you make up your own hash with 18 leading 0s and some other numbers for the other 46 hex digits, the first thing to happen will be that other miners will take your nonce tand the transaction details and compute the hash themselves. This is a simple and fast operation, one that is done with a random nonce to try and come up with a new valid hash.

The thing is that with 18 leading 0s, you need to to try a LOT of nonces to find a hash with 18 leading zeroes. You need to try about 1,000,000,000,000,000,000,000 nonces to find one that will give you a hash with 18 leading zeroes. That means that CHECKING that hash takes 1/1,000,000,000,000,000,000,000th as much computing power. When you submit your hash to the network , the first thing other nodes to is verify your hash. If you try to 'make up' a hash and it can't be verified, the rest of the network will ignore you, and stop even trying to verify future hashes you create.

Answer 9

The hash produced by a miner is not a random unique number per se. Generally, in the mining process, a miner will take transactions and construct a block, then using the block's header (which contains information as described by @minnmass), it will produce a SHA256 hash. This hash is then compared with the target set by the network and if not less, the miner will adjust the variable number until it gets a hash which is less than the target.

so, If a miner could theoretically just plug in a random number with required leading zeros and considering the variable nature of a block's composition, the chance that this number/hash would match the hash produced from the block header is practically impossible.