Subscribe Now
Trending News

Blog Post

Featured

Yes, Okay, But What Is the Blockchain Exactly? 

This technical series aims to demystify Bitcoin’s core concepts and empower enthusiasts worldwide. In this episode, we dive into the essence of Bitcoin as an accounting book, unraveling its mechanics through an engaging analogy of play money among friends.

With a focus on Bitcoin’s economic policies and its revolutionary impact on financial freedom, we guide you through each step towards a deeper understanding of this transformative technology.

Join us on this enlightening expedition through the Bitcoin universe as we pave the way for your journey into running your own node.

Watch the episode:

Welcome to the Heartbit podcast, where we delve into the heart of Bitcoin and uncover the sweet spot for enthusiasts worldwide.

I’m Dani, your fellow explorer in the Bitcoin universe.

This is our technical series where every episode is about what is bitcoin. Bitcoin is…{noise effect discussed}… an accounting book and now we’re going to share with you how… SILENCE!!!

Thank you. Yes, there is a lot of noise and confusion about what bitcoin is. This show is here to silence the noise and bring you the signal. This show is for the average person who wants to understand how things work and why. This episode is dedicated to my aunt and my cousins and my friends who are lost. Because I want you all to come on the boat, to be freed from the shackles of fiat money, and join the insurrection.

As I was saying, Bitcoin is an accounting book. Here we’re going to break things down to its core concepts and at its core Bitcoin is an accounting book now we’re going to share with you how that enables sound money.

As I was saying, Bitcoin is an accounting book. We use the book to keep track of how much money each person has. Bear with me as we walk through an example that has been used extensively in the Bitcoin education books, but we’re going to take it one step further and actually show you the accounting book directly from the node. In this episode I’m going to show you bitcoin, so you can see it for what it is and dissolve the mystery. In the next episode I will show you how to run a node so you can keep a copy of the accounting book yourself and hold the power that comes with it. 

Imagine your group of friends is hosting a game and you need some play money. You solve it by having Alice keep a table on the computer with the names of the people and the money that corresponds to each. 

{show table names and money}

Check #recipientvalue
1Alice$100
2Ben$100

Instead of thinking of these as transactions, think of them as checks. Each of those lines represents a check that person received for that amount of money. In this example, Alice is just going to give each player a check for $100 when the game starts. The bitcoin economic policy is more complex than this and we will discuss it later but for now, let’s just assume the table starts with each person already having $100.

It’s simple enough at the beginning when Alice just assigns $100 to each player. But what happens when each person starts giving others a little bit here and a little bit there? It becomes really hard to track who gave what to whom and how much they have left.

Check #recipientvalue
1Alice$100
2Ben$100
3Carol$100
4Ben$20
5Alice$300

In addition to thinking of each line as a check, we need to think of them as potential inputs. If Alice or Ben want to spend money, they must use their existing checks to pay. At the same time, for the person receiving the payment, the check is a potential input for their own transactions. This is known as a circular economy.

Bitcoin handles this by keeping track of the checks that have not been spent. The actual table will contain every check, but here, we’re only going to show which checks have not been spent.

Every check:

Check #recipientvaluespentspent_to
1Alice$100no
2Ben$100yesCarol
3Carol$100no
4Dave$100no
5Edgar$100yesDave
6Flit$100no
7Carol$100no
8Dave$100no

Unspent checks:

Check #recipientvaluespentspent_to
1Alice$100no
3Carol$100no
4Dave$100no
6Flit$100no
7Carol$100no
8Dave$100no

So let’s see what it looks like when we start moving money one check at a time. 

Edgar went all in on a bet and had to pay Ben $100. That’s quite simple. We mark Edgar’s check as spent and add a check for Ben for $100.

Check #recipientvaluespentspent_to
1Alice$100no
2Ben$100no
3Carol$100no
4Dave$100no
5Edgar$100yesBen
6Flit$100no
7Ben$100no

Since Edgar spent their check we remove it from the list.

Check #recipientvaluespentspent_to
1Alice$100no
2Ben$100no
3Carol$100no
4Dave$100no
6Flit$100no
7Ben$100no

Ben has to add up every time his name appears on the list to get the total amount of money available to him. 

Let’s try another, more complicated transaction. Dave has a check for $100 and needs to pay Carol $20. He can’t cut the check in half and give it to Carol. So how can Dave pay Carol?

For now, we’re going to have Alice break the check for Dave, but in reality, this process is more complex, since in Bitcoin, there is no centralized entity such as Alice to manage the table. So Dave goes to Alice and asks her to please break the check into two checks, so Alice gives Carol a check for $20 and gives Dave a check for $80

Check #recipientvaluespentspent_to
1Alice$100no
2Ben$100no
3Carol$100no
4Dave$100yesmultiple 
6Flit$100no
7Ben$100no
8Dave$80no
9Carol$20no

This is when things get interesting. We need to separate the notion of transaction from the notion of check. One transaction may involve more than one check. For example here we took one check as input and created two checks as output. But that created a problem. In the spent to category we couldn’t write one name because it went to multiple people. 

Our table can reflect that strategy by just adding a couple of columns. For clarity, I will include all the checks, including the ones that have been spent.

txidCheck #recipientvaluespentspent_tospent_txid
11Alice$100no
22Ben$100no
33Carol$100no
44Dave$100yesMultiple8
55Edgar$100yesBen7
66Flit$100no
77Ben$100no
88Dave$80no
89Carol$20no

So, if we read this table, we would say that Dave’s Check #4 was spent in transaction 8, and if we look in the list what checks are part of transaction 8, then we can see that checks 8 and 9 are the output of Dave’s payment.

Now we can remove the spent checks leaving us with:

txidCheck #recipientvaluespentspent_tospent_txid
11Alice$100no
22Ben$100no
33Carol$100no
66Flit$100no
77Ben$100no
88Dave$80no
89Carol$20no

Ben can pay Carol $200 if he wants, but he would need to use two checks to add up enough money to pay her. That would be a transaction that takes two checks as inputs and produces one check as output.

txidCheck #recipientvaluespentspent_tospent_txid
11Alice$100no
22Ben$100yesCarol9
33Carol$100no
66Flit$100no
77Ben$100yesCarol9
88Dave$80no
89Carol$20no
910Carol$200no

Giving us:

txidCheck #recipientvaluespentspent_tospent_txid
11Alice$100no
33Carol$100no
66Flit$100no
88Dave$80no
89Carol$20no
910Carol$200no

Everything seems to be going great, but since Alice is also participating in the game, some friends expressed discomfort with the fact that only she has access to the list, so she decides to make it public. However, other players voiced concerns about their names being visible to everyone, so Alice decides to replace them with pseudonyms.

txidCheck #recipientvaluespentspent_tospent_txid
11{Alice}$100no
33{Carol}$100no
66{Flit}$100no
88{Dave}$80no
89{Carol}$20no
910{Carol}$200no

It all seems resolved, except that not everyone trusts Alice, and she could unilaterally make changes to the list. Instead of having one copy that everyone can see, they opt to distribute the list so that everyone has a copy. 

{show multiple copies of the table}

If you’ve followed me so far then you should be happy to know that this is basically it, at its core. The Bitcoin accounting book is that simple, but the measures that need to be taken so the book isn’t tampered with are deeply complex. The list itself is not terribly complex, but the methods to secure it are… 

OK, so now everyone has a copy, but how do we know whose is correct? We need a strategy to update the table; otherwise, we will have many different versions. We need a strategy to determine the correct and the most up-to-date table. Also, when everyone has their own copy of the table, what stops them from creating money from thin air or spending one check multiple times?

This is when things get a little complicated because the solution involves a series of sophisticated steps but bare with me and I will do my best to explain them in plain English. 

Before I explain the exact steps, I need to explain what hashing means. Hashing is a mathematical process that can take any number as input and produce a unique output of a predetermined size. In Bitcoin, the hashing functions used are SHA-256 and RIPEMD-160. These functions take in data of any size and produce as output a number that is 256 and 160 bits long, respectively. Bits just means 1s and 0s. So, sha256 will take any size data and produce a unique sequence of 256 1s and 0s. 

The number of possible ways to combine 256 1s and 0s is 2^256, larger than the number of atoms in the visible universe. That means it’s practically impossible to produce the same hash with two different inputs. This is referred to as being collision-proof. Another important quality of hashing is that it is a one-way function, meaning that you can produce a hash from the data, but you cannot figure out what the original data was from the hash. Ok, so empowered with this knowledge, let’s proceed.

The first step is for the group to broadcast their transactions to everyone. But what stops Dave from pretending to be Ben and creating a transaction with Ben’s money? This is when asymmetric public key cryptography comes in. Instead of using random pseudonyms, we use a public-private key pairs. Th next technical episode will explain what a key is in more detail, but for now, know this: It is possible to have one number that is secret, from which we derive a second number that is public. In Bitcoin, we go further and create an address by hashing the public number. Because it’s a one-way function, people cannot derive your private number or key from the address. 

The address is the pseudonym your funds are associated with, and the private key is used to prove that the pseudonym is yours. But since the private number cannot be revealed, you prove it by performing a mathematical equation that only the owner of the private number associated with the related address could perform. This ensures that when you publish a transaction, you can prove that the checks that you are using to pay actually belong to you.

———————————

Bitcoin is pseudo-anonymous, meaning that if it is used correctly, the pseudonym can be so private that it is impossible to determine who is behind the monikr, and therefore anonymous. 

—————————

The second step is known as consensus and is achieved through a distributed timestamp server that uses proof of work. Yes, that was a lot of jargon, and I will explain it to you now. A timestamp server is a tool to prove that a piece of data existed at a given time. This is achieved by hashing the data and publishing the hash. Why is this proof? Since only that exact piece of data could produce the given hash, if the hash exists, then the data exists. 

At this point, we need to return to our table and see it not as a table with infinite rows but rather as a book with pages of limited size. In Bitcoin, we call the pages blocks, but they are no different from the pages in an accounting book. 

Instead of checking and revalidating the entire book after every transaction, we create a hash at the end of each page. If even a single bit in that set of transactions is changed then it would produce an entirely different hash. That way we only need to be on the same page, all pun intended, regarding the most recent page in the book rather than the entire history.

Lets say that people have transacted enough to fill an entire page, at that moment we generate a hash. But how do you stop someone from changing an entire page? well you include the hash of that page at the top of the next page and so changing one page would require changing all subsequent pages. This is why it is known as a Blockchain. Because every page is linked to the next through the hash that connect the previous page to the next.

Previous page hash
txidCheck #recipientvaluespentspent_tospent_txid
11{Alice}$100no
33{Carol}$100no
66{Flit}$100no
88{Dave}$80no
89{Carol}$20no
910{Carol}$200no

We use the timestamp server to agree on the order of transactions, so if someone tries to reuse a check we will know because the timestamp server will tell us that a transaction that spends that check has already been included in an earlier page.

Ok, but who produces the hash? Where is it published? Well anyone can produce the hash and it is stored in every computer along with the list of checks. The person who gets to produce the hash is the one who wins, what I like to call the nonsense competition, which is no nonsense at all. It’s what in Bitcoin is known as Proof of Work. This is why the timestamp server is distributed, because any miner can produce the hash. 

In order to ensure that pages are turned at a consistent rate, Bitcoin adjusts the difficulty depending on the amount of computing power competing in the nonsense competition. The way it achieves this is by demanding that the hash of the page is preceded by a certain number of zeros, the more zeros the harder to produce the hash. A set of data will always produce the exact same hash so in order for the hash to change the input data has to change. 

For this we need to create an additional field in our table called the nonce. Think of it as nonsense. It is a field that the miners can change arbitrarily in order to change the resulting hash until they produce one that contains the desired number of zeros. It’s a game of chance, where the person who makes the largest number of guesses has the highest chance to win. I call it the nonsense competition because the person who gets to hash the page is the person who can come up with the correct nonce that will produce the desired number of preceding zeros. 

Previous page hashnonce
txidCheck #recipientvaluespentspent_tospent_txid
11{Alice}$100no
33{Carol}$100no
66{Flit}$100no
88{Dave}$80no
89{Carol}$20no
910{Carol}$200no

Ok, but if there are discrepancies in the list, how do you resolve who has the most up to date copy?

Using POWER!!! Ok I’m joking but i’m not joking. In our example it is equivalent to who has the most amount of pages. Like if you’re on page 8 and im on page 11 then my version is the final version.

I’d like to go back and emphasize on something that I executed trivially in the example. At the beginning of the story Alice “simply” assigned $100 to each person. In the Bitcoin Accounting Book, the origin of money works a little differently and relates to important Economic policies. 

In Bitcoin there is a limited supply but not all of it was put into circulation at the same time. The money is put into circulation by awarding it to the winner of the nonsense competition. So basically we are rewarding the users for competing in the nonsense competition and creating timestamps of the pages. 

The amount of Bitcoin that will ever be is almost 21 million. Approximately in the year 2140 all Bitcoin will be in circulation and the winner of the nonsense competition will only be rewarded by the fees rather than the increasing the supply. This is important because by having a fixed monetary supply it makes the currency dedflationary rather than inflationary. 

Ok so to recap

  • We kicked things off with Alice introducing her trusty table to keep track of play money among friends.
  • Then, we saw how each entry represented a check, each detailing a transfer of funds between players.
  • As our play money economy grew, we realized the importance of tracking unspent checks to maintain transparency.
  • Next, we delved into the world of public-private key pairs, ensuring pseudonymous transactions while maintaining security.
  • We then explored the role of hashing, ensuring the integrity and immutability of our transaction data.
  • With the need for a decentralized timestamp server, we introduced the concept of Proof of Work consensus, where miners compete to add transactions to the ledger.
  • As our individual tables evolved, we transitioned to a distributed ledger, the blockchain, ensuring consensus among all participants.
  • Miners entered the scene, engaging in the “nonsense competition” to validate transactions and secure the network.
  • Through consensus mechanisms like the longest chain principle, we resolved discrepancies and ensured the integrity of the ledger.
  • Along the way, we discussed Bitcoin’s economic policy, emphasizing its limited supply and deflationary nature.
  • And finally, after all these steps, we arrived at the robust and decentralized network we know as Bitcoin.

So lets take a look at what this actually looks like on the computer.

The actual node data is not this easily accessible because it’s stored in files to optimize for efficiency. 

I wrote a program that interprets those files and stores the information neatly into a table so we can read it easily.

We’ve taken a deep dive into the heart of Bitcoin, breaking down its complexities into digestible pieces. From the simple analogy of an accounting book to the intricate workings of hashing and consensus mechanisms, we’ve explored how Bitcoin ensures security and transparency in transactions. Remember, Bitcoin isn’t just digital currency; it’s a revolution in financial freedom. So, join us next time as we continue unraveling the mysteries of Bitcoin and guide you through running your own node. Stay tuned, and let’s navigate this Bitcoin universe together!

Support by Donating: ⚡zapheartbit@getalby.com https://geyser.fund/project/heartbit

Looking for bitcoin wallets, gadgets and merch? Find them all on our coupons page https://loveisbitcoin.com/coupons

Related posts

Leave a Reply