Contents

• Introduction
• Running a Monetary Database
  • Brandolini's Law
  • The Fundamental Problem: Disagreement
  • Tempting but Unrealistic: All Transactions, Every Round
  • The Real Solution: Cryptographic Hashing
  • Cryptographic Hashing in Action
  • Filtering Forgeries: Proof-of-Work
  • Proof-of-Work in Action
• Summary
• Where the Example Ends and the Real Blockchain Begins

What we are going to do

This chapter explains the basic idea behind the blockchain through a simplified, hypothetical example that strongly resembles Bitcoin.

We removed the bulk of the technical complexity so that the core concepts (what a blockchain does and why it works) become easy to understand.

Starting from Bitcoin's real technical specification is overwhelming for anyone without significant time and expertise. Beginning with a simplified model is effective: once the core ideas make sense, the real system becomes much easier to explore.

At the end, we highlight the parts where our example diverges from Bitcoin's actual design.

Our goal is simple, show the two essential properties a blockchain provides:

1. Ensuring monetary records are managed so disputes over balances can be resolved quickly and easily.
2. Designing the system so fraud is simply not worth the cost.

With these ideas in mind, let's begin.

Brandolini's Law

We begin with an idea that applies to many areas of life, but which becomes the central problem when trying to run a database that records monetary transactions.

Brandolini's Law goes like this:
"The amount of energy needed to disprove nonsense is much greater than the amount of energy needed to produce it."

Most people have experienced this in arguments. One person confidently throws out a series of claims that sound plausible, while the other struggles to respond in real time. The difficulty lies in the fact that properly refuting a claim requires detailed knowledge, examples, and careful reasoning. If you cannot immediately produce those, the confident speaker may appear to be "winning", even if they are wrong.

For example, consider climate change, and how a climate change denier might argue:
"The climate's always changed, ice ages happened before humans, CO₂ is good for plants, the sun causes warming, and anyway, scientists used to warn about global cooling!"

Or how an evolution denier might:
"Evolution can't be real. there are no transitional fossils, DNA is too complex to form by chance, scientists keep changing their minds, the second law of thermodynamics forbids it, no one's ever seen a new species evolve, and anyway, carbon dating doesn't even work."

We can see in both of these examples how one could loudly produce these claims, and seen as "the winner" if you can't immediately point to material that a climate or evolution expert would be familiar with.

In both cases, it is easy to produce many claims quickly, but hard to refute them on the spot. This imbalance becomes a serious obstacle when the subject is money.

The Fundamental Problem: Disagreement

Imagine ten friends who decide to maintain a shared database of monetary transactions. They will act as validators. The database is shared over the internet, everyone begins with an initial balance that all agree on, and only transactions that the group votes to be valid are added to the record.

After each transaction, everyone recalculates balances locally so that future transactions can be checked for validity.

This is how the initial balances would look:

1. Mary: 30 money
2. Nadia: 20 money
3. Mark 25 money

Then, the first transaction comes in:
- Nadia sends Mark 5 money.

Each friend (validator) checks that Nadia has at least 5 money (yes) and proposes the following to be added to the database as a valid transaction:

{Nadia 5 money -> Mark}

After Each of them update the balances they hold, the 2nd transaction would come in:

{Mark 7 money -> Mary}

Mark has sufficient balance, the transaction gets added.

Then, the 3rd transaction comes in:
- Mary sends Nadia 300 money.

The proposed transaction:

{Mary 300 money -> Nadia}

This is invalid and won't get voted into the database. So far so good.

This process continues. More transactions appear, new wallets are created by money being sent to them, and the list of valid transactions grows longer and longer.

Then, much later, a problem arises. Around the 1,833rd transaction, someone named Adam wants to send 3,000 units of money. Most validators don't believe he has the funds, but three of them think he does. Adam claims he received a bonus transaction as part of a marketing campaign, and that some validators failed to update their records due to internet outages at the time.

Some validators find this plausible, as there were indeed reports of connectivity issues. Others are unconvinced. Adam offers several different explanations for why his bonus transaction might be missing from some records.

Who is right?

By Brandolini's Law, making these claims is easy. Disproving them is hard. Validators would need to investigate logs, timelines, network issues, and competing pieces of evidence. The effort quickly becomes enormous.

Then others follow. Amy claims she received a bonus in a different month. Karl insists he is 2,000 units richer because Bob paid him, and one validator even seems to have that transaction recorded. Joyce claims the initial balances were wrong and that she should have started with more money.

Do the validators now conduct detective work every time someone disputes a balance? What if there is disagreement about the evidence itself? Do they vote on how to resolve disputes?

This approach is clearly not sustainable. When consensus only exists on new transactions, disputes about the past will inevitably pile up. Fraudulent claims and honest mistakes alike will bog the system down. Running a monetary database this way simply does not work.

Tempting but Unrealistic: All Transactions, Every Round

The friends consider a solution. To quickly resolve disputes, they decide that every validation step will include a complete copy of all past transactions. Whenever someone makes a claim, they can simply check the latest record and see whether the transaction appears.

So the records to add would look like this:

On 1st transaction:

{Nadia 5 money -> Mark}

On 2nd transaction:

{Nadia 5 money -> Mark; Mark 7 money -> Mary}

On 3rd transaction:

{Nadia 5 money -> Mark; Mark 7 money -> Mary; Mary 3 money -> Nadia}

This would indeed make disputes easy to resolve, but it introduces a new problem. The amount of data that must be agreed upon grows endlessly. Every new step requires copying and validating the entire transaction history. Over time, this becomes impractical. Once again, the system is not sustainable.

The Real Solution: Enter Cryptographic Hashing

Fortunately, the friends are familiar with cryptography.

Instead of repeatedly quoting the entire transaction history, they take the complete set of information they want to agree on (all transaction history up to a certain point), convert it into binary form (string of 1s and 0s, so that computers can work with it) and run it through a cryptographic hashing algorithm called SHA‑256. This algorithm takes any digital input and produces a fixed-length output of 64 characters, known as a hash.

Two aspects of this algorithm are crucial.

1. The first aspect: The output (the hash) is always the same size. Whether we hash the digital representation of a short text like "Hello" (40 pieces of 1s and 0s) or the digital representation of entire Hungarian Anthem (around 15 thousand pieces of 1s and 0s), the result is always 64 characters.
2. The second aspect: The hash is unique to its contents. If even a single character of the input changes, the hash changes completely and the process cannot be reversed.

It is like crumpling a newspaper into a tiny ball where 1) the ball will be the same size, no matter how many pages the newspaper has and 2) you can't uncrumple this ball to get back the original newspaper, but the headline is still visible so you can still tell exactly which newspaper the tiny ball formed from.

We understand that this is unintuitive and encourage readers to look up "SHA‑256" to see how this is possible, but for conciseness now, just accept that (1) and (2) above are true.

Because of these properties, a single 64‑character hash can represent an entire transaction history. Agreeing on the hash is equivalent to agreeing on all transactions that produced it.

Here is how this will work in practice:

1. They take the set of initial balances, hash that.
2. Then, they take the first verified transaction, hash that, but then, they would also concatenate this "hash of the 1st transaction" with the hash of the initial balances from (1) and hash that as well (don't worry, example coming in a bit). They shall call this the "hash of the 1st step", 64 characters, unique to the precise initial balance amounts and the first transaction.
3. Then, they verify the 2nd transaction, hash that as well.
4. Then (focus!), they would concatenate these two hashes together from (2) and (3) and hash that as well. Because hashing is unique to its input, the resulting 64-character string will depend on everything that came before, or in other words, if anything changes in the initial balances, in the 1st or in the 2nd transaction, this hash in (4) would change as well, making tampering obvious. They shall call this the "hash of the 2nd step".
5. When the 3rd transaction comes in, they'd verify it, hash it, and then they would hash it together with the hash of the 2nd step from (4). We will call this the "hash of the 3rd step".

Therefore, the list of transactions would now be "chained" together, by having been individually hashed, and then hashed together with a hash that represents everything that happened before (the "hash of the previous step").

Cryptographic Hashing in Action

Time to see this in our specific example.

As per (1) above, lets apply the SHA‑256 hashing algorithm to the initial balances, so this:

{Mary: 30 money; Nadia: 20 money; Mark 25 money}

becomes this:

b1fb6d071a9964bc09574644d265636ce7cf5972d0faf6d2cd23cfa047a3dbd4

Upon receiving and validating the first transaction, the "hash of the 1st step" is established as:

1. Hash of first transaction {Nadia 5 money -> Mark}:
   3d2efb0717b25ca6de2cba24f66c490f43d08bf82ae5c8babed3af26cb034d28
2. Hash of 1st step: b1fb6d071a9964bc09574644d265636ce7cf5972d0faf6d2cd23cfa047a3dbd4
   3d2efb0717b25ca6de2cba24f66c490f43d08bf82ae5c8babed3af26cb034d28
   -> f5a5b36a41480f567663a9a8916414d1e3781e6893d0b75ac7d53314a8ec8a13

Great. They'd get and validate the second transaction, establishing the "hash of the 2nd step":

1. Hash of second transaction {Mark 7 money -> Mary}:
   d750476372215b2b6aa679abb7088fbd443582baf92c6d51815adfb142661a0b
2. Hash of 2nd step: f5a5b36a41480f567663a9a8916414d1e3781e6893d0b75ac7d53314a8ec8a13
   d750476372215b2b6aa679abb7088fbd443582baf92c6d51815adfb142661a0b
   -> fe5c831994fb85efbd93c64a7809cc49fc74a5bb2f22f9b10930c7c543db4423

Finally, after validating the 3rd transaction, the hash of the 3rd step:

1. Hash of third transaction {Mary 3 money -> Nadia}:
   fd2b918db2ab68dd4a9383b61fd2b2d10b7ece2d9505e4b20279f5dd42a0e5e4
2. Hash of 3rd step: fe5c831994fb85efbd93c64a7809cc49fc74a5bb2f22f9b10930c7c543db4423
   fd2b918db2ab68dd4a9383b61fd2b2d10b7ece2d9505e4b20279f5dd42a0e5e4
   -> cd5f30326c28c50231d3d17cceecf7ec0855070428515e69cfde00d9b530c81b

So this hash (the one starting with "cd...") is dependant on the initial balances, the 1st and the 2nd transaction. Its essentially a "receipt" of all money movements up to a certain point. We can use this receipt to resolve disputes in a matter of seconds, not in a matter of days and days of detective work on various claims.

This hash is the key to taking on Brandolini's Law that prevented us from running a monetary database, because the time it takes to disprove nonsense went from who-knows-how-long to mere seconds, because we retain all the transactions that lead up to a certain hash, i.e. our receipt of what has been considered in building the most recent money balances. Imagine how the life of Adam's claim would now shape up:

1. He claims to have received some bonus transaction as part of some campaign.
2. We say "okay, we check all of the transactions that lead to the latest hash we have (as that is unique to all of the transaction history) and get back to you on whether we've found it". If we don't find it, that means that it was never validated and we move on, sorry. The transaction is not part of the chain that leads to the latest hash.

There might be legitimate reasons why Adam's transaction didn't go through, but those form separate discussions. The main point is that we have an easily replicable rule to assess which transactions were included.

Hashing is extremely fast. What once required lengthy investigation now takes seconds. The system can move on instead of being trapped in endless arguments.

This ability to cheaply and quickly resolve disputes about monetary transactions is the central innovation of blockchain technology.

Filtering Forgeries: Enter Proof-of-Work

Now imagine a new validator who wants to join the 10 friends, someone who calls himself Wolf, ok. He has a problem, because there are now many different groups who have chains they claim are honest. There would be one where some guy sent some lady 10,000 money, another where some lady apparently sent some other guy 7,000 money, etc.

Even though with hashing we can easily prove consistency, we cannot prove truth. Anyone can fabricate a set of fake transactions, hash them, and produce a flawless, self-consistent chain of hashes in milliseconds.

So in order to deal with this, our simplified system needs a way to make forging an entire history so costly that no one would even consider doing it.

We must design the system in a way that validating a transaction carries with it something that cannot be faked: cost through real work. Each time a new transaction is added, someone must perform a simple but repetitive computational task. You cannot skip it, you cannot pretend you did it, and you cannot reverse it.

To achieve this, we need two things:

1. A real monetary cost associated with adding transactions to the database.
2. A real monetary reward for verifying transactions, one that grows with the amount of honest activity.

The idea is this: People don't want to use a database filled with fraudulent transactions. Because of this, running a fraudulent monetary database would bring no users and therefore no transaction verification rewards, however cheap it would be. It simply wouldn't be worth paying the costs to maintain it.

In contrast, running an honest monetary database is valuable to many people. That value translates into transaction submission volume, which generates verification fees. Those fees would more than offset the cost imposed on validators, creating a profit incentive. So there would always be participants willing to pay the cost of validation for an honest chain because it would be popular enough to generate enough transaction verification rewards to make it a good business.

Not in the case of a fraudulent chain however, because that one would not attract enough users to generate enough verification rewards.

Let's see how this idea manifests.

Proof-Of-Work in Action

Let's go back to the point where we got the hash of the 3rd step by hashing the hash of the 2nd step and the hash of the 3rd transaction. This one: cd5f30326c28c50231d3d17cceecf7ec0855070428515e69cfde00d9b530c81b

We'll modify this step in general, such that the thing to hash is actually not two but three things:

1. The hash of the previous step
2. The hash of the current transaction
And now we also add a third thing:
3. Also, a random number like 12, 3, 623, or 32 etc., such that (here comes clever) the hashing of these three things together would result in a hash that happens to start with "00...". There is no trick for finding such a "random number". You cannot predict it. You must guess repeatedly until luck happens.

Remember the second aspect of the SHA256 algorithm, that you can't "uncrumple" the tiny ball you crumpled from the newspaper? Here is where that becomes relevant.

You can't "uncrumple" or reverse-engineer that random number in (3). If you take a random hash that begins with "00...", you cannot work backwards to say "I have the hash of the 3rd transaction and the hash of the 2nd step, what number would I need so that the hashing of these three things would result in that hash?" The best you can do is keep trying, because the algorithm is such that modern computers cannot reverse-engineer its inputs, however unbelievable that sounds.

This is how the verification process now looks: They combine the hash of a transaction, the hash of the step preceding that transaction and a random number, like the number 12, and hash. If the output does not begin with "00...", they try a different number. They may try 23, then 131, then 43, then 812, and so on.

All the 10 friends do this in parallel, each guessing different numbers. When someone finally finds a number that produces the required pattern, for example 46322, that person sends the transaction / random number combination to all 9 friends with the message "got one".

The others check all that is claimed: the hash of the transaction, the hash of the preceding step, as well as the final hash of the current step with this number that is proposed to have been found to satisfy the "starts-with-00" condition.

If everything is correct, they accept the transaction, add it to the database, confirm the transaction reward for the friend who successfully found it and move on to the next submitted transaction.

This creates a cost because the friends must spend money on electricity for guessing numbers. You cannot cheat your way around it and that is the point. If someone wanted to create a fake history where Mary secretly sent Johnny 10,000 money in one of the transactions, they would face a huge barrier. Changing even one transaction changes its hash, which breaks the "starts-with-00" rule above.

To fix it, they would need to redo the Proof-of-Work for that step and for the step afterwards, and for every step after, because new validators do check upon joining that the entire chain has hashes adhering to the rules, including the "starts-with-00" rule above. New validators wouldn't just trust anyone; they'd verify that they will indeed be dealing with an honest chain.

Back to Wolf. So how can he in practice decide which chain to join? He simply chooses the chain that contains the most accumulated work, i.e. the most amount of guessing that has taken place, the most amount of electricity that has been spent on producing the chain. Only the honest chain would be so useful to so many people so as to attract enough validators to support the ongoing cost of guessing the number. Other chains will be short or cheaply made.

As hinted above, once Wolf chooses the honest chain, he verifies every transaction from the beginning. He checks every hash and that every rule was followed when producing it. He trusts nobody. Every new validator does the same.

This is the principle that Bitcoin follows. Every new validator independently verifies the entire chain, before commencing the validation based on the calculated balances. No one relies on outside authority. As Bitcoin's ethos goes: "do not trust, verify".

Proof-Of-Work makes it such that creating such receipts in general is so costly that only the operation of making honest receipts would generate so much volume from people to be worth the maintenance.

Fraudulent receipts would never attract enough users to make them worth the cost of creation.

Our simplified blockchain works by combining two ideas: hashing of transactions and Proof-of-Work done on transactions. Both of these concepts are delivered by the "hashing algorithm" which, in the case of a lot of blockchains, is called SHA256.

The operation of our pet blockchain relies on two aspects of the SHA256 cryptographic algorithm:

1. Hashing allows a vast amount of transaction data to be represented by a single 64-character string. Even a tiny change in an early transaction alters the hash of every later step.
2. This output cannot be reversed. The only way to produce a certain hash that meets some required rule is to keep guessing. This is what gives Proof of Work its cost, and the valid chain is the one with the most accumulated work. Only that would be worth the cost.

It is in the interest of millions (or billions) of people to record digital money movements that are honest and fraud-free. And only the honest chain would be so useful for so many people and produce so many transactions that it would result in revenue from transaction fees high enough to offset the cost and more.

Bitcoin is the first process designed in such a way that honest participants are rewarded for performing work that makes the above happen, while dishonest participants would need to spend a prohibitive amount of energy to fake history. They would never find enough people to agree with them, because they are dishonest. But if you don't have enough people agree with you, you don't generate enough revenue to cover the cost of transaction validation.

That is the core idea behind our pet blockchain and behind Bitcoin. Bitcoin's innovation is not money, speed, or decentralisation, but a mechanism that makes honesty cheaper than deception at global scale.

So, one last time, the innovation of the blockchain is two fold:

1. Attaching compact "receipts" to all transactions, past and present, so their inclusion can be verified quickly and easily.
2. Constructing this process such that only receipts about honest transactions are worth doing.

As noted in the introduction, our model simplifies many details. The real Bitcoin system works differently in several important ways.

First, Bitcoin does not validate transactions one by one, it groups them into "blocks". A block is a bundle of transactions, with a header that includes the previous block's hash, the random number (referred to as the "nonce") and other info. The hash of the block is computed from this header, which is why the structure is called a "blockchain".

Bitcoin also does not store balances directly. Instead, it maintains a separate table of unspent coins, called the "UTXO set". This design ensures that no coin can be spent twice and is recalculated by everyone when they join validation, independently, based on the already verified blocks of transactions.

Second, the roles are divided differently. In Bitcoin, validators are called "nodes". They enforce the rules and verify every block. The entities that perform Proof-of-Work and propose the transactions for inclusion are called "miners". Miners search for the nonce that makes the block's hash valid.

When a miner finds such a nonce and proposes a block, nodes verify it. If it is valid, it becomes part of the chain and miners are rewarded with newly created Bitcoin upon successful block proposals, known as the "block reward". Because only the first miner to find a valid nonce receives the reward, mining is competitive.

This is why companies invest in large amounts of specialised hardware and operate in places with cheaper electricity. They can test far more nonces per second than a single computer. A person with one laptop can mine, but the chance of finding a valid block is extremely small.

Lastly, in our example we described the goal as "finding a hash that begins with zeroes". In Bitcoin, the rule is more precise. The system defines a target value, and a valid block hash must be numerically "less than" this target. The lower the target, the harder it becomes to find a valid nonce. This is how Bitcoin adjusts mining difficulty over time, as more entities join the mining process.

Blockchains come in many forms, each offering different capabilities, such as issuing fungible tokens, minting NFTs, supporting smart contracts, and more. Bitcoin delivers the core idea of a blockchain extremely well, but its feature set is intentionally limited.

A newer network, the XRP Ledger (XRPL), builds on those fundamentals with a much broader set of built-in features and very fast performance. For a clear overview of how XRPL differs from Bitcoin, we recommend reading The Upgrade.