Bitcoin Whitepaper but easier
Tags: blockchain, bitcoinwhitepaper, bitcoin, satoshinakamoto
Published: 2024-04-27 17:48:39


While the entire world was busy being amused by the infamous Balloon Boy incident, the tech world was also amused by the invention of Bitcoin or to say more precisely, the creation of Web3 i.e **Blockchain Technology** by **Satoshi Nakamoto**, who might be a person or several people or maybe even aliens because the identity of this thing has not been recognised yet. SN (short for Satoshi Nakamoto and also my initials hehe) introduced the technology by releasing a Bitcoin Whitepaper which, in my opinion, is hella confusing, so I am here to simplify it for you(I hope I don't confuse you even more :p)

**What's the basic concept behind Bitcoin?**

When the internet was introduced, everyone expected that it would help to get rid of the 2 most important flaws of day-to-day lives, first being the presence of a middleman in anything and EVERYTHING and the second being the lack of trust. I mean, will you ever trust random news on the internet OR are the middlemen that are interfering in our personal lives in the pretext of navigation, reliable? Thus, to solve these problems and to be honest many others, blockchain technology was introduced.

Blockchain technology is what forms the backbone of Bitcoins (yes, blockchain and bitcoin are 2 different things, we will get to that later). BT (not the Bad Trip one dumbo) works on the solid idea of peer to peer version of a system where a transaction happens between only two parties, yeshhhh no interference by any GIANTS aka middleMAN. Every transaction is added to a chain of blocks (imagine a train’s design for better visualization) that has been validated by numerous nodes, if these large numbers of nodes are not trying to attack the network, they will create the longest possible chain and will win against the attackers hehe. These long chains are not only proof of the sequence of events, but also proof that it has been generated by a pool of majority CPUs. The nodes participating can leave the system anytime they want and when they want to rejoin they can just refer to the longest chain to understand what happened while they were gone

**The role of financial institutions in transactions**

Every time you make a transaction, say for example you bought some anime merch via an online website, the process of transaction is navigated by a financial institution. This system works well for a small-scale transaction, but we can't forget the trust issues that are prevailing. Also, every time there’s a dispute in the transaction, say the other party did not receive the money, this third party (mostly a bank) has to interfere to fix the problem, which increases the cost of the transaction. Meanwhile, if reversibility of the transaction is possible, the trust within the system increases. The presence of middlemen increases the need for users to give away their personal information, sometimes that information is asked that isn’t even required.

**How to kick these financial institutions out (such parasites eww)**

See the solution is simple, introducing a system with no central authority, or to be more precise we need a decentralised payment system. And how is this possible? Well, what if two parties directly communicate with each other and the trust of the transaction relies on cryptographic proof? This system will protect the seller and the buyers as well using different mechanisms which we will discuss later on. This system will be secure until it is in the power of the majority of CPUs that are legit and not the attacker nodes. 

**How do Transactions Shake, Rattle, and Roll in BT**

In BT, when a transaction has to be made, an **electronic coin** is assigned as a chain of digital signatures. Now how can a user (sender) send this coin to another user (receiver), two components are required to do so, the first being **signing a hash** of the previous transaction and the other being the **public key** of the next owner. 

Alright lemme explain to you what hashing and public key are before going further

Hashing happens when a transaction is broadcasted to the network, the data is converted into a fixed-length string called hash. Now this hash function uses the transaction data as the input and provides an output which severe as a digital footprint of the transaction.

The public key belongs to both the sender and receiver. Everyone in the BT network has their own **public key** and **private key**. Let's assume that the public key is a lockbox which is shared within the network but the key (private key) isn't. Now the users can send messages or money using this public key as a reference and the receiver uses their private key for their account.

Once the transaction is made, it has to be logged into the end of the coin. The receiver can check the previous ownership by using the signatures.

However, one of the issues with this process is that the payee (receiver) cannot check if the sender has double-spend or not. Oh wow, now what is double-spend? Ok so for example You have 5 bitcoins, and you want to send 2 bitcoins to Teddy and Bear each and alsooo you don't wanna spend 4 bitcoins. So you use your clever mind and send 2 bitcoins to Teddy and before the transaction is logged into the network you send 2 bitcoins to Bear ehehehe, which means you just tricked the system and used the same 2 bitcoins twice and your balance now is 3 bitcoins instead of 1. 

To solve the issue, a central authority which will check every transaction, which defies the main logic of BT. (We BT people HATE banks). Now to make sure that **double spend** does not occur is to be aware of all the transactions, one way to do so is to make every transaction public in the network. Also, the payee needs to approve that at the time of each transaction, the majority of nodes should agree it was the first received.

![[hi]](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g5xs0f1r4yctl5ntclu7.png)

**Timestamp Server:- The Killer of Double-Spend**

Now BT has a very amazing solution for double-spending. Now, this timestamp works by using the hash of the block of items that has to be timestamped and then publishing this hash over newspaper or **Usenet**(It is a worldwide-distributed discussion system available on computers). Whenever someone tries to double spend the system can detect it via the hash, coz if the transaction has entered the hash then it must have happened before, right? Now these timestamps also include the previous hash, forming a chain which has the information about the previous transactions.


![hi](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/njxnbugbppd8qu90d7c8.png)

**Mining Mastery: Understanding Proof of Work**

We just discussed the timestamp server, right? Now to implement this we need a system known as **Proof-of-Work**, which is similar to **Adam Back's Hashcash**. Proof-of-Work involves scanning of values using a hash function, a hash function is a mathematical function that takes an input and gives a fixed-size string of bytes. 

Now, how does a miner use these hash functions? Well, they continuously try different **nonce**(not used values) which when hashed with the data of the block returns some hash value which starts with some number of zero bits, this number of zeros influence the amount of time required to get the exact nonce, meaning that as the number of zeros increases, the amount of time required to find the valid nonce also increases.

To implement the Timestamp Server into the network, we increase the value of nonce by some values until a value is found that gives the block’s hash the required zero bits. Once the miner finds the nonce that satisfies the proof-of-work requirements and creates a valid block, changing the data in the blockchain will require the miner to redo all the work. When more blocks are added to the network, the work to change any aspect of the block will require the effort to redo all the blocks after it. 

Another major problem that Proof-of-Work solves is the determining representation in decision-making. If the concept of **one-IP-address-one-vote** is applied, then it can be misused by anyone who can allocate many IPs. Blockchain uses the concept of **one-CPU-one-vote**. If the majority of CPUs are controlled by honest nodes, then they can grow faster and outpace any competing chains. For an attacker to attack a block, they will need to redo all the work for every block and surpass all the kinda impossible work of honest nods.  

As technology improves, computers get faster, allowing people to mine **cryptocurrency** more quickly. Also, the number of people interested in participating in the network can change over. To keep things fair and stable, the difficulty of mining new blocks is adjusted regularly. This adjustment is based on how quickly blocks are being produced compared to a target rate, which is usually an average number of blocks per hour. If blocks are being produced too quickly, it means that miners are working too efficiently, so the difficulty of mining is increased. This makes it harder to mine new blocks and helps maintain a steady rate of block creation.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qmlugp7ljtmb5vchxofx.png)

**The networking in the blockchain world** 

what do the nodes do when any transaction is made?

1. A new transaction is broadcast throughout the network.
2. These nodes add the data of the transaction to a block.
3. The nodes try to find the best proof-of-work for the block. 
4. When a node finds the required proof-of-work, it broadcasts it to all the nodes.
5. The other nodes accept the block only when the transactions are valid and not already spent.
6. After accepting the new block, the nodes work on adding new blocks using the hash of the previous hash.

Now, what if two nodes broadcast two different versions of the next block? Well, the system accepts one block by default and works on it and keeps the other one IF its chain gets longer (because the nodes consider the longest chains). If by chance the node they didn’t choose becomes longer, then they switch to the longer one. 

Now it is not certain that all the transactions reach every node, sometimes the block gets added so fast that all the nodes don't even receive the transaction data. Now when the next block has to be added, the nodes who didn’t receive the data will realise that they have missed one.

**Crypto Rewards: Fueling the Blockchain Boom**

The **first transaction** in a block is always special because it starts a new coin owned by the creator of the block. Now to support the system some **incentive**(reward) is given to the nodes. Unlike traditional systems of transaction networks, there is no middleman or central authority which can control it, instead, cryptocurrencies are usually mined. Whenever a miner successfully adds a new block, they are given a “block reward” in the form of newly created coins. In the case of cryptocurrency mining the resources expended are CPU time and electricity, i.e. the computational power time required to solve the cryptographic puzzles and the electrical energy required while mining. 

The other ways of incentives include **Transaction Fees**. To understand this let's take an example

Let Ponyo(Japan) want to send 20 cryptos to Howl (America), when these cryptos reach Howl, the 20 cryptos can be reduced to let's say 18 cryptos, and the 2 cryptos are the transaction fee that acts as the reward for the miners. Once the predefined number of coins is introduced no new coins can then be included, now this reward can completely transform into the transaction fee which is completely inflation-free.

Now, what if an attacker thinks of assembling more CPU power than all the honest nodes? Well, then they will have to make a tough choice between stealing money back from people or using it to generate new coins. 

Before we go onto the next topic, I would like to say, GOOD JOB MATE (read this with an Australian accent). You have completed half of this hell. So far it has been very confusing yet interesting. Let's see what the other half is about.

**Trimming the Fat: Reclaim Desk Space**

**Reclaiming Desk Space** is one of the ways to save memory, once the latest transaction block is buried under enough blocks, the spent transactions can be discarded to save the disc space. Now to do this **Merkel's tree** concept is used, in this the transactions are hashed which further facilitates saving memory space without breaking the block’s hash. The branches of old Merkel’s trees with data can be stubbed or removed as they are not needed any longer time. 

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mvbi8c4g11s7zt5q6nab.png)

In the above picture, we can analyse Merkel’s tree, which is used to store data about a transaction.  Merkel tree is like an inverted family tree. The main node has a **Block Header** which has the **Block Hash**, data about the previous hash, **Nonce**(Number used Once) which is a random or semi-random number that is used only once in a cryptographic communication, and lastly the data about the root hash. This main node is then connected to multiple other nodes which also have some data about hash functions.

Now one may think that saving all this memory of block hash, block header, prev hash etc etc can take up a lot of memory, but it is not the case because let's say blocks are made every 10 minutes and each block header without transaction would be about 80 bytes. The yearly storage required for this block would be about 4.2 MG, considering the computers, back in 2008, nowadays, have storage of 2GB and according to Moore's law this value increases by 1.2GB every year. Thus storing block headers in memory shouldn't be an issue, even as blockchain networks grow.

**Easy-Peasy Blockchain Payment Checks**

**Payment verifications** can be easier in blockchain. In order to understand this let's take an example of you attending a birthday party and you want some information without asking directly. Just like how you didn't need to talk to everyone in the party to know about something specific, you can just talk to some key people, these key people in the Blockchain network are **network nodes**. You can ask these network nodes about the block headers of the longest chain of transactions, we can assume these block headers as the main summary of all the transactions. 

Now let's say you wanna confirm who brought the best birthday cake at the party, and in order to verify that you don't need to ask everyone present at the party, instead you just need to know where all the info about the cake is stored. Just like this, a user can check the transaction or verify the transactions in the blockchain network. 

Even though the user is not checking or verifying the transactions by themselves, they can trust the result by linking the transaction to the main summary of all the transactions. And further, if the chain gets more updates, it's like getting more confirmation that the transaction is legit.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ta208ml0dvkt8bco9n5g.png)

So far everything is fine, the user are not verifying every transaction but trusting other honest nodes but what iffffff, what if there is an attacker node huh? The network nodes can easily verify the transactions without any problem but what if an attacker node fabricates the information and overpowers the network. The solution to this problem is very easy, the nodes can keep an eye on **security alerts** that can detect an invalid block and alert transactions to confirm the inconsistency. 

Businesses that get frequent transactions can form their independent security and run their nods thus ensuring safety and consistency in the system. 

**Coin Fusion: Mixing and Matching in the Crypto World**

While doing transactions, multiple inputs and outputs can be combined in a single transaction, this way the transactions can be done easily and efficiently for everyday use.

Now to understand this let's take an example:

Let's say Jay wants to buy a new mouse and it costs around 1000 rupees, Jay does not have a single 1000 rupee bill but he has multiple bills and coins adding up to 1200 rupees. Now transactions using multiple bills and coins will be a very tiring job and it will also take lots of time. One way to fix this issue is by making one single transaction instead of making multiple, in this way, Jay is using 1200 rupees worth of bills and coins as the input. Now we can have 2 outputs, one for the mouse ie 1000 rupees and one for giving back the change, which in this case is 200 rupees. In this way,  blockchain combines and splits value for a smoother and easier user experience.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k1lug7dagvls2xzi9e7x.png)

**Fan-out** is a transaction which relies on other transactions and those transactions, in turn, rely on many other transactions. In the traditional system of fan-out, it is very difficult to practice because one need to have the info of all the other transactions which makes it very **resource-intensive**. But in blockchain fan-out is not difficult because here, the user does not need to have the information about all other transactions. When a transaction occurs, nodes only need to verify the validity of the transaction. They don't need to retrieve and store the entire history of each transaction involved in the fan-out scenario. 

**Hush Hush: Privacy in Blockchain**

**Privacy** can be a major concern in blockchain networks, as we know that each transaction in the network is publically announced, but how can this be secure or how can the privacy of the sender and receiver be maintained? 

Let's take a scenario where there is a thrift marketplace where multiple stalls are put up, in a traditional transaction process, when a buyer makes a purchase, only the buyer, the sender and maybe a third party(bank) get information making sure that the transaction process is private. 

But what if, after every transaction is YELLED OUT? This will eliminate the privacy aspects because now everyone in the market knows who is buying what from whom. But this can be done in a better way, instead of announcing all the information like “Hiya bought 1 dress from Sara” we can say “x bought a dress from y”, in this way the market will know about every transaction, while the privacy of the buyer and seller is maintained. 

This is the same concept that is used while trading, where the **time and size** of the individual trade is made public but without telling who were the parties.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cz586qaow8ksxl7d9dur.png)

An additional privacy system can be the inclusion of a **public key** (like a lock)and a **private key**(like a key to the lock),  to access and send funds.

Let's say you want to buy some paintings, you use a **unique key pair** to make the transactions. The public key associated with this transaction is like the **address** of the seller's digital wallet, while the private key is your **secret key**. Now let's say you want to buy some music, instead of using the same key pair as before, you generate a new one for this transaction. This way, the public key associated with this transaction is different from the one used for the book purchase.

Now what if you are making multiple transactions, like for eg you are collecting funds from different funds to make a single payment? Even though you will be using different key pairs for making each transaction, as all the inputs contribute to the same transaction may reveal the fact that they belong to the same owner.  
The risk in this is that, if someone gets hold of one of your key pairs, they can find the owner and thus it becomes harmful. The solution to this problem will be to generate a **new key pair** for every transaction, making it more difficult to link transactions to a common owner.

Wohooo only one more topic and you are all done!! I am so proud of you for reaching here!! You're hardworking and passionate. :)

**Calculations**

Let's consider a scenario where an attacker is trying to create a different chain faster than the honest one. Even if this attempt is successful, it does not expose the system to any random alterations, such as generating an unpredictable value or taking money that never belonged to the attacker. The nodes are never going to accept a transaction with invalid credentials and the honest nodes are never going to accept a block consisting of them. The only way an attacker can fool the system is by taking the money back that he recently spent in a transaction. 

To understand the rat race between the honest nodes and the attacker node while a transaction is made, we need to characterize each of them based on **Binomial Random Walk.**

The gap between the number of chains of the honest nodes and the attacker node can be considered by understanding the success and failure events in the honest nodes and the attacker node respectively. The gap gets extended by one block in the honest nodes chain whenever there's a success event, meanwhile, the chain of the attacker chain extends by 1 when there’s a failure event. 

To understand this let's discuss the **Gamblers Ruin problem**. 

Imagine you are playing a game where you start with a certain amount of money, but you owe some money initially. You keep playing the money, and with every round, you either win or lose some money. Now your motive is to reach a point where you have enough money to pay back the initial deficit and break even. 

Now, let's relate this to the situation of an attacker trying to catch up with the honest chain in a blockchain system.

1. The player with the **initial deficit** represents the attacker who is behind the honest nodes. 
2. Each round of the game represents the attempt of an attacker to generate a new block faster than the honest chain. 
3. Winning money represents the successful creation of a new block and reaching the same level as the honest nodes or surpassing them
4. Losing money represents failing to create a new block or falling behind the honest nodes. 

We can calculate the probability of the attacker ever reaching the breakeven,or the attacker ever catching up with the honest chains by using the formulas given below.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bup9rq2nuexse9ifs0lo.png)

If we assume that **p>q**, the probability of the attacker catching up with the honest nodes gets extremely low. If the attacker doesn’t make a lucky step forward in the beginning, it becomes nearly impossible to succeed. 

Now it might be possible that the sender in a transaction might be the attacker, who sends money to the receiver, the attacker wants to make the receiver believe that the money has been sent for a while, and then switch back to pay back the amount after some time has passed. Whenever this happens, the receiver gets an alert about the same and the attacker hopes that it will be too late. 

Whenever a transaction has to happen, the receiver creates a new key pair and then gives the public key shortly before the transaction happens. This prevents the sender from creating a chain of blocks before the transaction happens and then works continuously until the attacker gets far ahead, and the executing the transaction. One the transaction the attacker works secretly parallel on a chain containing an alternate version of the transaction. 

The receiver waits until the transaction has been added to a block and the number of blocks has been linked after it(let's say z number of blocks). The receiver usually has no idea about the progress the attacker has made, but the receiver assumes the average time taken by the honest nodes per block, the attacker's potential progress will follow a Poisson distribution with a mean of…

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vlkhg97qk3adflpq06or.png)

What if the attacker still catches up now? In this case, to find the probability, we calculate the **poison density** for each potential amount of progress the attacker could have made and then multiply it by the probability that they could catch up from that particular point.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e8vrbcvcdn0gabsdd5pa.png)

On rearranging this formula we get

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3x5f4493sf4fqniiti0v.png)
Sorryy if you didn't get the Calculation part, coz I found it a little difficult :(

I hope I was able to explain you the Bitcoin Whitepaper in a better and easy way. Lemme know if I missed out on something or if you have any suggestions. All the images have been taken from the original whitepaper(https://bitcoin.org/bitcoin.pdf) which you can refer to understand the topics in depth.