In this section, we shall try to break down the mathematical problem, *number X*, the reference number, the rule, and how they work together to allow recording transactions in a consensual and secured manner.

Let's summarize what we have so far:

- The page is what we call a
**Block**.
- Date time provided on screen B is what we call the
**timestamp** of the block.
*Number X* is known as a **nonce**. It is the number that the nodes of the blockchain network (in our example, the villagers) try to find to reach the output number that respects the rule given by the wall.
- The process of finding
*number X* is called **mining**.
- The rule given by the wall is called a
**hash function**.
- We will see what the reference number is, in later sections.

Before moving on with the mathematical problem, let's first focus on the rule given by the wall, the so-called hash function.

A hash function is a mathematical function that transforms any chain of characters or numbers into a fixed-length chain of characters. It turns data **into a digital fingerprint called a hash**. For example, if I enter `euclide` (7 characters) into the hash function called SHA-256, it will return the 64 characters hash: `E0F4C627CD4D365EE9760BAA6A1CD35CA26CF7252F6EB25C0DC7B4C3E2718A20`.

**SHA** stands for **Secure Hash Algorithm** and is a set of cryptographic hash functions designed by the US National Security Agency. SHA-256 means that it is a hash function producing a 256-bit-long output.

Now, if I input into the same SHA-256 hash function the entire Wikipedia's Bitcoin page description, it will return: `D5752C643EC97DC0FF32AE74FF2F2079043A8AB0191C51AEFDE09EDE0C757EE6`.

It returns 64 characters—all of the time—whatever the length of the input is.

**The hash function is deterministic**: **it is always the same output for the same input**.

The following diagram depicts the process explained in this section:

The principle behind a hash function is, when you know the output, it is very hard to find the input because the reverse action is not possible. That is, knowing the digital fingerprint of data does not reveal that specific data. You cannot guess that I entered `euclide` if I tell you that the output is `E0F4C627CD4D365EE9760BAA6A1CD35CA26CF7252F6EB25C0DC7B4C3E2718A20`. However, when knowing the input, it is very easy to find the correct output. Indeed, you can easily verify that `euclide` returns the hash `E0F4C627CD4D365EE9760BAA6A1CD35CA26CF7252F6EB25C0DC7B4C3E2718A20`, just by entering it into the SHA-256 hash function.

You can try this yourself on your device. Try typing `euclide` on the following website: https://passwordsgenerator.net/sha256-hash-generator. You should find the same chain of characters as mine.

If we return to Village Beta, you might have understood where this is going:

- The reference number, 0
- + the timestamp of the page, 2018/06/25, 03:25 PM
- + the transactions (the data written in one page of the book)
- + the nonce (number X)
- = return the hash of page #1 (an output number following the rule: a number starting with two leading zeros)

The preceding equation can be pictured like this:

Consequently, to find the output number (a number starting with two leading zeros, or the hash of the page), every villager will have to try several inputs for *number X* for the equation to return a number respecting the rule.

It is as if I asked you: using the SHA-256 hash function, can you find an output number starting with two leading zeros? How many inputs will you try before finding a correct output?

You can also try this exercise on your device, using this website: https://passwordsgenerator.net/sha256-hash-generator.

Eventually, one villager, named Dan, finds an appropriate *number X*. He tells everybody else that the number **12345**, combined with the timestamp, the reference number, and the transactions return the output number, **0031993**. As regards the rule, this number is a valid output because it starts with two leading zeros.

Because it is very easy to find the output when you know the input, every other villager can verify that n*umber X*, 12345, is a correct data that return a valid hash, that is, for the mathematical problem to be solved.

The output **0031993** is what we call the **hash value of a block**. It is the seal needed for the page and its transactions to remain valid.

Once everyone has verified that 12345 is the correct *number X* (the nonce) that returns the output number 0031993 (the hash value) that respects the rule, Dan is allowed to display his first page on the wall, hence becoming the reference page:

Now, why should every villager try to find *number X* since somebody is going to find it anyway and tell everyone else? Why should a villager spend time and effort to have his/her page validated and displayed on the wall?

We introduce here the incentive mechanism, an economic payoff for the community to play fair. Because the pages should keep being sealed to keep the transactions accurate, the community should continuously work on solving the mathematical problem. In this manner, a reward is given to the villager who finds *number X*, that is, the first villager to find the correct hash of the page. In our example, Dan is rewarded with, say, 5 Villagecoin.

This incentive mechanism ensures that everyone keeps interested in working for the common good*. *More on that in Chapter 2, *A Technical Dive into Blockchain*.

Now that page #1 is displayed on the wall and secured, transactions continue to take place: *Chuck sends 5 Villagecoin to Alice, Dan sends 2 Villagecoin to Bob, *and so on.

When page #2 is completed with 10 transactions, the villagers repeat the entire process all over again.

So, what is the *reference number*? Remember that, on page #1, the reference number was 0?

For page #2, it will be 0031993. Exactly! The reference number of page #2 is the output number found for the previous page. In technical terms, we call it the **previous hash** or **the hash value of the previous block**. This allows the pages to be linked with one another, or to be chained to one another.

So, when page #2 is filled, the process repeats: every villager gathers at the wall, which displays new information on screens A and B:

- Screen A's reference number (hash of the previous page, page #1): 0031993
- Screen B's date and time (timestamp): 2018/07/03, 10:08 AM

The following diagram displays the new information on the wall:

Then, the villagers input the transactions of page #2 in Screen C. Finally, everyone tries to find the correct *number X* (the nonce) on Screen D, which will return an output number starting with two leading zeros.

When an output number following the rule is found, *number X* is announced to everyone else who checks that *number X*, combined with 0031993, the timestamp, and the transactions, returns a number that starts with two leading zeros. If everyone agrees, we put the page on the wall and reward the villager who found the correct input with 5 Villagecoin.

And then the process repeats with page #3, page #4, and so on:

Let's evaluate how secured this system is. Let's assume that Chuck wants to modify a transaction on page #2. He wants to erase the 5 Villagecoin he sent to Alice during the completion of page #2, and change it to 1 Villagecoin.

*What will happen?*

He will have to solve again the mathematical problem for page #2 because he modified the transaction of page #2 (hence, the data of Screen C). Because of this slight change, the wall returns an entirely different output number, say 37882, which does not respect the rule anymore. Therefore, Chuck has to calculate the new *number X* on Screen D that would return a number starting with two leading zeros for page #2.

*How is that a complication for Chuck? *

Imagine that Chuck actually finds a new correct *number X *that returns an output number that starts with two leading zeros. Because hash functions are change-sensitive (a slight modification in the input returns a totally different output), even if Chuck finds a new correct input, the output will totally be different from the original. Say the new output number for page #2 is 00829 instead of the initial 0088. What will happen on page #3? The reference number (previous hash) will be different and so will be the output number of page #3. Furthermore, it is very likely that the new reference number of page #3 (00829 instead of 0088) combined with the rest of the data on the other screens will return a number that does not start with two leading zeros, hence making the page (and the transactions with it) invalid. In this fashion, Chuck will also have to compute again *number X* of page #3, then of page #4 and #5 and every page validated afterward.

*This is how security is achieved in a blockchain, by sealing and chaining the blocks containing the transactions. *

The more pages (blocks) are put on the wall (validated), the more secure and unalterable are the transactions. Because it would take a tremendous amount of time and computing power to re-calculate every *number X* (nonce) of every page (blocks) in order to find the correct output numbers that start with two leading zeros (hashes), the wall (the blockchain) is the best technology for storing and securing the transactions of the villagers (nodes and users).