Understanding the nonce in blockchain validation

With a reasonable amount of research, the concept of a blockchain is accessible to most technically minded people. Simply put:

A blockchain is a public ledger. Participants compete to add blocks of transactions to the ledger, in return for a reward. This competition is based on problem solving. The participant who solves the problem gets to add the new block, and the transaction that creates their reward is included in that block. The block also contains the solution to the problem, so that other participants can verify that the participant solved the problem.

The detail is a little bit trickier, particularly when it comes to the problem solving step.

In the Bitcoin blockchain, problem solving means creating a hash of all of the contents of the candidate block and converting it into a binary string (e.g. 0000011001110010). The problem is solved when the participant (a miner in the case of Bitcoin) can produce a string with a minimum number of leading zeros. The number of leading zeros required can be obtained from the previous block in the chain, which is determined by how long it took the miner who created that block to solve the problem for that block. Bitcoin self-regulates the rate at which new blocks are created by adjusting this “difficultly” level up and down.

But here’s the thing:

If a miner knows that it must calculate a binary string with x leading zeros, why doesn’t it just create such a string with a line of code (a fake or forged string, if you will), add that to the block, submit the block for validation by other miners and wait for its reward?

Bitcoin (and other blockchains) obviously deal with this, but how they do so may not be immediately apparent.

When a miner attempts to solve the puzzle, it bundles all the data in the block into a string, hashes it and the converts it to binary format. However, for it to produce a different string each time, in order to find one that meets the requirements of the puzzle, it needs to slightly alter the input to the hash, as otherwise it would just produce the same string each time.

This altered input is the nonce. A basic nonce is just a number incremented by one. For example, in the first iteration, the miner would include a nonce of “1″, in the second “2″, in the third “3″ etc etc.

If the minder finds a string that solves the puzzle, they include both that string *and* the nonce in the block.

Now when another miner goes to validate that block, they include the same nonce as the miner that originated the block in hashing function, and derive the same binary string as is required by the puzzle.

If the originating miner had simply faked/forged the binary string, they would not know the nonce required to generate it, and no other miner would be able to validate it. The block would therefore be rejected.

Simple, but effective!