v01

Hash

Hashing is a process that can be likened to generating a unique fingerprint for data. Just as our fingerprints act as unique identifiers, a hash function produces a fixed-size output for any given input, making it a one-of-a-kind representation for that data. Hashing is widely used in computer security, especially in securing logins and passwords, as it prevents plain-text passwords from being exposed during transmission over the internet.

Let's explore the key features of hashing through various analogies to help better understand this crucial concept in computer science and for Bitcoin!

There are several hash algorithms, but we will use SHA256 as a reference, as it is widely used on the Bitcoin network.

SHA-256, which stands for Secure Hash Algorithm 256-bit. It was developed by the United States National Security Agency (NSA) and published in 2001 by the National Institute of Standards and Technology (NIST) as a U.S. Federal Information Processing Standard.

SHA-256 generates a unique 256-bit (32-byte) signature for text strings or data files.

In essence, SHA-256 takes any input and transforms it into a set of numbers (bits) with a specific size. It then thoroughly shuffles these numbers in a highly systematic and secure way to produce a seemingly random and unique output.

One-way Functionality

An essential feature of hash functions is their one-way nature. This means that it is easy to create a hash from input data but extremely difficult, if not impossible, to reverse-engineer the input from the hash. As an analogy, you can think of a fingerprint. A fingerprint can be derived from a person's finger, but you cannot recreate the person from their fingerprint.

Deterministic Output

Hash functions are deterministic, meaning that given the same input, they will always produce the same output, regardless of the computer or system used. This feature can be compared to a recipe. When following the same recipe with identical ingredients, you will always end up with the same dish.

Sensitive to Input Changes

Hash functions, particularly the SHA256 Hash function used in Bitcoin, are highly sensitive to even the smallest changes in input. This sensitivity results in a drastically different output for even minor variations in the input.

An example using SHA256 Hash function:

If the input is: Hello, I'm Matheus

The output will be: D7A7DD7CA99320BB0C2FBBA48FD53D24D3D4F65317B950197EDC790198BCEAE4

And if we just remove the comma from the input: Hello I'm Matheus

The output will be:

B929280E3136AEFFCBADFAE60F02276270A3E3F19F171F06F1670D705F68D5E2

Totally different. This shows how it is not possible to discover the input from the output.

You can make some tests here: https://emn178.github.io/online-tools/sha256.html

Quantum Collision Resistance

The number of possible hash outputs is so vast that the chances of generating the same hash for two different inputs (collision) are astronomically low. To put this into perspective, the number of possible hash outputs is 10^77 and can be compared to the estimated number of atoms in the universe (10^80). This immense variety helps ensure the uniqueness of each hash output.

Easy Verification

Checking if a hash is the correct representation of a given input is a simple process. This can be compared to a password lock. Once you know the correct password, it is easy to verify if it opens the lock. In the same way, hashing allows for easy verification of data integrity without needing to store or transmit the original data.

By serving as a digital fingerprint for data, hash functions provide a secure way to verify the integrity of information without exposing sensitive details, making them an indispensable tool in modern technology.

Now that we've covered hash functions and seen how they work their magic in the realm of cryptography, it's important to keep this knowledge in your back pocket as we venture further into Bitcoin's territory. These hash functions aren't just technical jargon; they're crucial players in the Bitcoin network. As we unfold the layers of Bitcoin in the upcoming chapters, you'll notice hash functions in action in many key areas, from securing your digital transactions to the heart of Bitcoin mining. So, keep these hashing insights in mind – they're going to be our trusty guides in navigating the intricate world of Bitcoin.

Private and Public Keys / Digital Signatures

In the traditional banking world, when you want to open a bank account, you walk into a branch or visit a website, provide your personal details, and the bank creates an account for you. It's the bank that gives you an account number and helps you set a password. They hold the power and control over account creation, and they ensure that only you, with your unique password, can access your funds. If you forget your password or if someone tries to fraudulently access your account, it's the bank's responsibility to verify your identity and safeguard your money. The bank acts as the central authority, the gatekeeper, and the verifier.

Now, in a decentralized system like Bitcoin. If there's no central entity like a bank, then who creates your account? Who ensures that only you can access your bitcoins?

The brilliance of Bitcoin's decentralized system is that it doesn't rely on a central authority to issue accounts or validate transactions. Instead, it leverages the power of cryptography. In the Bitcoin world, you create your own "account" by generating a pair of cryptographic keys: a public key, which is like your account number, and a private key, which is like your password (we will learn more about them throughout this chapter).

But unlike a bank password that can be reset, your private key is unique and non-recoverable. Lose it, and you lose access to your funds. Share it, and others gain access. It's a system built on trust in mathematics and code, rather than trust in a central institution.

This decentralized approach offers freedom, control, and responsibility. It's a revolutionary shift from the centralized systems we've always known, placing the power of account creation and access squarely in the hands of the individual.

Excellent. But once I have my account and password, who will validate that I authorized a transaction?

Who verifies that a transaction was actually authorized by the issuer and not tampered with?

The answer is digital signature: They bridge this trust gap, offering a decentralized way to verify that a transaction truly originates from its claimed source and guarantees that it has not been tampered with.

Digital signatures is a more secure subset of electronic signatures. So, let’s understand the differences, real-world applications, especially in a decentralized context and for Bitcoin.

Let's start with a broader category: Electronic Signatures:

Think of the electronic signature as the digital equivalent of your handwritten signature on a paper document. It's any electronic data (like a typed name, an uploaded image of a handwritten signature, or a click on an "I agree" button) which is logically associated with other electronic data and is used by the signatory to sign. It's akin to a physical signature but in electronic form.

Most of us engage with electronic signatures, often without realizing it. Here are some commonplace examples:

• Agreeing to the terms and conditions of a software or online service by clicking "I Accept."

• Signing on digital pads after credit card transactions at retail outlets.

• Using signing platforms, where one can draw or upload an image of your signature to digitally sign a document.

Your electronic signature is your signature and doesn’t change based on the item being signed: when you sign a letter, or a document, the whole point is that your signature looks the same. This is easy for other people to copy! This is really terrible security!

The problem with electronic signatures is that they rely on a trusted third party to validate the authenticity of the signatory and the integrity of the signed data. For instance, when using e-signature platforms, the platform itself acts as the third party, ensuring that the signatory is who they claim to be and that the document hasn't been tampered with after signing.

In contrast, a digital signature is only valid for that exact piece of data, and so it cannot be copied and pasted underneath another piece of data, nor can someone else re-use it for their own purposes. Any tampering with the message will result in the signature being invalidated. The digital signature is a one-time proof that the person with a private key really did approve that exact message. No one else in the world can create that digital signature except you, unless they have your private key.

So given that we learned that Bitcoin does not have a trusted third party, this is where digital signatures come in to "sign" valid transactions confirming the sending of coins from one account to someone else’s.

Delving deeper, the digital signature is a specific type of electronic signature. Rooted in cryptography, it involves creating a unique digital code (“signature”) using a private cryptographic key. When others receive the digitally signed document, they can use the signatory's public cryptographic key to verify the document's authenticity and ensure it remains unaltered since being signed.

Imagine I've organized an exclusive party, and I want to send out special invitations to a select group of friends. Given the event's exclusivity, it's vital that the recipients know that the invitation genuinely came from me and hasn't been replicated or forged.

To ensure this, I seal each invitation envelope with my unique wax stamp. This stamp, known only to belong to me, adds a touch of authenticity to each invitation. Once pressed into the wax, the seal's intricate design hardens, making it evident if someone were to tamper with the envelope.

While my wax stamp is unique, the method to verify it isn't hidden. Over the years, friends and acquaintances have come to recognize the design of my stamp. Moreover, I've often shared a magnifying glass at gatherings, which displays the finer details of my stamp's design for anyone curious.

Once they receive the invitation, anyone can analyze the wax seal and validate its authenticity.

This verification assures that the invitation is genuine and indeed from me.

In this scenario:

• My unique wax stamp represents the private key. It's used to assert authenticity by "signing" the invitation.

• The magnifying glass, shared among friends and acquaintances, represents the public key. It allows anyone familiar with my stamp to verify the authenticity of the seal, ensuring the invitation truly comes from me.

A digital signature is created by taking the message you want to sign and applying a mathematical formula with your private key. Anyone who knows your public key can mathematically verify that this signature was indeed created by the holder of the associated private key (but without knowing the private key itself).

Knowing that those who will solve the problem of issuing the account and password are the public key and the private key, and that those who will solve the problem of verifying the authenticity of transactions are digital signatures, then how are they created? How do they work?

To do this we will have to quickly understand a little cryptography. Although this is the most important and complicated topic, we will only touch the surface.

Cryptography is used to provide:

• Encryption: When only the intended recipient can interpret the message (Confidentiality);

• Signatures: When you want to ensure that the message was written by the sender (authentication) and was not tampered with in transit (integrity);

There are two ways to do encryption. Those two ways are symmetric encryption and asymmetric encryption.

The main difference between these two is that symmetric encryption is going to encrypt and decrypt content using the same keys, and asymmetric encryption is going to encrypt and decrypt using different keys.

So let's talk about what that means.

To show you how this is going to work, we're going to use the alphabet. Now for these examples, we're going to assume that there's only uppercase A through Z, there's no lowercase characters, there's no numbers, there's no symbols. We're going to keep it simple for the explanation.

So the symmetric encryption uses the same key for encryption and decryption. So let's say we start with the word HELLO. We are going to use a symmetric encryption algorithm in combination with a secret key. Now the algorithm we are going to use for this example is simply moving the letters forward, and we are going to move it that amount of times In this case: three. Well if we start at the H and I move forward three times, we'll end up at K. If we did the same for the rest of the letters in the word, we'd end up with K H O O R.

To decrypt this, we would simply take the cipher text and do the inverse of the algorithm. So if our algorithm was to move forward, our decryption algorithm is going to be to move backwards and we’re going to use the same key. So if we move forward three times to encrypt, we’re going to move backwards three times to decrypt. If we start at the K and we move backwards three times, we'll end up back at the H. And again we could do this for the rest of the letters to decrypt the whole word.

So that's a simple example of symmetric encryption. In this case, the same key was used for both encryption and decryption.

Now let's talk about asymmetric encryption and we are going to see it's a little different. With asymmetric encryption, we’re still going to use an encryption algorithm, but the keys we use for encryption and decryption are going to be different.

Here we are going to use the encryption key of five. Again, we are going to start with H and we are going to move forward five times to get to M. We could do it with the rest of the letters in this word to get to MJQQT. Now it might seem like we can just go backwards to get back to H. But  asymmetric encryption algorithms are usually a one-way function,- remember the hash algorithms we learned previously? We can't do them backwards!

So in the case of asymmetric encryption, we can't actually go backwards. Instead we have to go forward a different amount. To decrypt this, We are going to have to take my cipher text and use a different key going forward again. So starting with the M, if we go forward 21 positions, we'll end up back at the H. And we could do it again for the rest of the letters to decrypt the rest of the word. But note that unlike symmetric encryption, we move forward to encrypt and forward again to decrypt. With symmetric encryption, we were able to use the same key to encrypt the decrypt. Whereas with asymmetric encryption,weI had to use different keys to encrypt and decrypt.

Now let's talk about those keys a little bit more.

Those two keys we used in this case, 5 and 21 are mathematically related. Whatever we encrypted with 5 could only be decrypted with 21. There are other combinations of keys that you could use in our little example using just the alphabet. Actually anything that adds up to 26 would work. So we could have also used an encryption key of 6, and a decryption key of 20.

Well, what if we used them in the reverse order? What if we encrypted a 21? Could we not then decrypt with 5?

Well, let's give it a shot. Again, we’re going to start at the H and we’re going to see if we can move forward 21 times. That will bring us back to the C and we could also do the same for the rest of the letters. And then to decrypt this, we would again take our cipher text and then move forward another 5 times. That would bring our C back to an H successfully decrypting the first letter of our plain text. We could again use the same decryption key to decrypt the rest of the letters. The main thing we’re pointing out here is this property of asymmetric encryption is that what we can encrypt with one key can only be decrypted by the other key. But it works in either direction. We can encrypt with 21 and decrypt with 5, or as we showed earlier, we can encrypt with 5 and decrypt with 21.

These two asymmetric keys are mathematically related.

Now, what the industry does with this is they take one key and they label it as the public key and they make it available to anybody that asks for it. And then they take the other key and they call it the private key and they keep it to themselves.

Given that cryptography allows encryption and signatures, but for Bitcoin purposes, we will only focus on the Signature feature.

So, if you have the private key you can sign a message.

And if you have the public key, you can prove the signature was made by the owner of the private key;

When someone wants to send bitcoins to another person, they create a transaction message specifying the amount and the recipient. However, instead of signing the entire transaction message, which can be of variable length and relatively large, Bitcoin employs a more efficient approach: What is signed is the hash of the transaction.

This way, we can ensure:

Uniformity: Regardless of the length or content of the original message (transaction), its hash will always be of a fixed length (256 bits in the case of Bitcoin's SHA-256 hashing algorithm). This uniformity is convenient for processing and verification purposes.

Efficiency: Signing a hash, which is a fixed and relatively small size, is computationally more efficient than signing a potentially large and variable-length message.

Security: The cryptographic hash functions used in Bitcoin (like SHA-256) have the property that even a tiny change in the input will produce a vastly different output. This means that if even one character in the original transaction changes, the hash will change entirely. Thus, by signing the hash, the integrity of the entire transaction is ensured.

So, this is how public and private keys are used to sign a transaction in Bitcoin:

I am going to generate a transaction of 1 bitcoin for my grandma. I'm then going to run that transaction through a hashing algorithm. That's going to result in a particular output. For our example, the hashing algorithm produces the output "HELLO" from the input "transaction of 1 bitcoin".

That output "HELLO" is then going to be encrypted with my private key. Given that my private key is 5 (letters ahead in the alphabet), this means signing the hash "HELLO" results in "MJQQT". The result of that, which is the encrypted output "MJQQT", is the signature. That is actually the signature of that transaction of 1 bitcoin. That gets appended to the transaction, and then both the transaction and the signature get sent across the wire.

Now, that signature was created with my private key, which means on the other side, my grandma is going to use my public key to verify the signature. Given that my public key is 21 (letters ahead in the alphabet), my grandma will use it to verify if the signature was made by the private key that is a pair of my public key.

What she's going to do is take the signature "MJQQT" and decrypt it using my public key. That's going to result in the output of the hash of the transaction: "HELLO" .

Then my grandma is going to independently calculate a hash of that transaction. If the output "HELLO" that my grandma got in her calculation matches the output "HELLO" that I had sent, this proves two things.

First, it proves that the transaction has not changed since I signed it. Remember, this output was created by taking a hash of this transaction. So if anything changed in this transaction, my grandma would have gotten a different output. This gives us the property of integrity.

The other thing that signatures prove is that only I could have created the signatures. This signature was created as a result of taking my private key and encrypting the digest "HELLO". Well, if my grandma was able to decrypt something with my public key, this proves it was definitely my private key that signed it. And the only person in the world that has my private key is me. This gives us authentication.

Transactions:

Now that we already have an account and password generated by cryptography and can sign them without the need for a trusted third party to confirm the sending of a message, we can think that in Bitcoin, this message is actually a transaction.

That's right: Transaction is a message to the Bitcoin network indicating that the owner of a certain amount of bitcoin authorizes the transfer of that amount to another person. Each transaction contains information about input, which are the credits from which the values will be sent, and outputs, which are the destinations of the credits.

It is as if in a transaction, the owner is indicating which piggy bank he wants to send the values from (input), and then indicating which new piggy bank the values should go to (output).

In the real world, we may come across the situation where we want to send a smaller amount of values than what initially exists in the piggy bank. Then we would have to break the piggy bank, send part of the resources to the recipient's piggy bank and the remaining coins we would have to deposit again in a new sender's piggy bank as if it were a change.

In this case, we have an input, which is the original piggy bank that contains all the coins. And we have two outputs: the recipient's piggy bank and the amount we want to send to him; and we also have to send what's left (change) back to a new piggy bank (since we broke the original) from the sender.

In Bitcoin, the concept of inputs and outputs works in the same way, where we have to indicate the address where the bitcoins that will be sent are, and then indicate the address to which the amounts will be sent and possibly another change address if the amount to be sent is greater than that to be received.

The opposite can also occur: The total amount to be sent is greater than that existing individually in each piggy bank. In this case, it will be necessary to indicate two or more piggy banks from which the total to be sent will be debited, and then indicate the destination piggy bank, and possibly another piggy bank (of the sender) if there is any change.

There is one more important point: The values of the outputs will always be equal to or greater than those of the inputs. This difference refers to the transaction fee that is paid to the miners who will add the transaction to the block (we will soon understand the concept of mining and blocks).

So, a transaction doesn't just say "A sends 5 bitcoins to B." Instead, it references previous transactions that A has received and uses them as inputs to send BTC to B. These inputs are essentially references to the bitcoins that A has received in the past but hasn't spent yet.

And here we come to yet another problem: If we don't have a trusted third party, who will add up all the credits and debits to calculate the current balance?

The concept of UTXOs emerged: UTXO stands for "Unspent Transaction Output." In simple terms, it's the amount of Bitcoin left over after a transaction has been executed, which can be used in future transactions.

So, rather than having an account-based solution like banks where there are debits and credits and you have a running balance at statement time every single month or on another cadence, in a UTXO model like Bitcoin, for example, your total wealth or your total balance is a sum of all of the unspent transaction outputs that you have in your wallet. Let’s think of this as giving change in the cryptocurrency world. There are some similarities and some differences, but let's take an example for that.

So let's just say you have $35 USD. To have $35 USD in your wallet right now, you would have to have a combination of different bills in your wallet because there is no $35 bill. Now, that being said, you can think of each of those individual bills, those individual denominations as Unspent Transaction Outputs (UTXO). Each of those bills is a value that you have received in the past from other transactions that add up to your total balance of $35.

So let's take this example a step further. Let’s suppose that each dollar bill is an Unspent Transaction Output (UTXO). Say you want to go buy a $28 lunch. If you want to spend that $28, you're going to have to give the person taking the cash one or more of those bills to cover that transaction. So let's just say to make up that $35, you have one $20 bill, one $10 bill, and one $5 bill. So all in all, you have three Unspent Transaction outputs (UTXO). So to cover that $28 lunch, you'd have to take two of those bills (UTXO). Let's say the $20 bill and the $10 bill. Give that to the cashier and they would give you back $2. When they give you that change, the change that you receive back as a dollar bill is, you guessed it, an Unspent Transaction Output (UTXO). And that $2 dollar bill goes back into your wallet to form your total leftover balance of your unspent outputs.

When we deal with traditional currency, like the US dollar, we're accustomed to dividing it into smaller units called cents. Every dollar has 100 cents. In the world of Bitcoin, the smallest unit is called a "Satoshi," named after its mysterious creator, Satoshi Nakamoto. But unlike the cent-dollar relationship, where 1 dollar is divisible into 100 cents, 1 Bitcoin is divisible into 100,000,000 Satoshis.

So, if you think of Bitcoin as the 'dollar' of the cryptocurrency realm, Satoshis are its 'cents'. Only, remember, instead of splitting your dollar into 100 pieces, you're dividing your Bitcoin into 100 million pieces!

Now, this is where the analogy breaks down a little bit because when the Unspent Transaction Outputs (UTXO) come back in the form of change for US dollars, the cashier is limited to the denominations of bills that there are in US dollars, whether that be change or dollar bills. Whereas in Bitcoin, there aren't any bill denominations or any other way that money is split up or value is split up so that does not really apply.

This is an important characteristic of outputs that needs to be emphasized: outputs are discrete and indivisible units of value, denominated in integer satoshis. An Unspent Transaction Output (UTXO) can only be consumed in its entirety by a transaction.

Unless it is possible to construct a transaction whose sum of inputs is exactly equal to the amount you wish to send (output) plus transaction fees, then change will be generated.

So let's take a Bitcoin related example. So if I wanted to send you 1 bitcoin and I had one Unspent Transaction Output (UTXO) in my wallet of 5 bitcoins, I would have to create a transaction that must consume the entire 5 bitcoin UTXO and produce two outputs: one paying 1 bitcoin to you and another paying 4 bitcoins in change back to my wallet. As a result of the indivisible nature of transaction outputs, most bitcoin transactions will have to generate change.

Remember that an important characteristic of transactions is that the total input must be equal or greater than the total output?

For example, if my input to a transaction would be 3 bitcoins, then, the outputs have to equal 3 bitcoins either, whether that goes to all to you or whether that goes part to me and part to you. And what happens is that's one of the preliminary checks for whether or not a transaction is valid. If there is a transaction with an input that is lower than the total output, that would mean that bitcoins were created out of thin air, so the transaction is considered invalid.

So, before a Bitcoin node forwards any received transaction to its neighboring nodes, it first conducts a thorough verification of the transaction. This critical step ensures that only legitimate transactions are circulated across the network.

During this verification process, a node checks various aspects of the transaction. It examines whether the digital signatures are valid, confirming that the transaction has indeed been authorized by the rightful owner of the bitcoins. Additionally, the node verifies that the sender has enough bitcoins to complete the transaction and that these bitcoins have not been previously spent.

There is a checklist to ensure that a transaction is valid, but we will not go into the details as it ends up being too technical for the purposes of this book.

Once a transaction passes these rigorous checks and is deemed valid, the node then broadcasts it to its neighboring nodes. This mechanism acts as a powerful filter, preventing the spread of invalid or fraudulent transactions, such as those attempting to spend the same bitcoins twice (double-spending).

As each node independently verifies each transaction it receives, it gradually builds up a collection of verified but yet-to-be-confirmed transactions. This collection is known as the transaction pool, often referred to as the memory pool or mempool. The mempool is a dynamic space in each node where valid transactions wait until they are picked up by miners to be included in the next block of the blockchain.

If an UTXO is larger than the desired value of a transaction, it must still be consumed in its entirety and change must be generated in the transaction. In other words, if I have an UTXO worth 20 bitcoins and want to pay only 1 bitcoin, my transaction must consume the entire 20 bitcoin UTXO and produce two outputs: one paying 1 bitcoin to my desired recipient and another paying 19 bitcoin in change back to my wallet. As a result of the indivisible nature of transaction outputs, most bitcoin transactions will have to generate change.

And so if you think about that also in relation to your total balance or the amount of coins that you have in your wallet at any given time, you can see how computationally simple it is to figure that out. All it is is the sum of your total Unspent Transaction Outputs (UTXO).

So, now you know that when we say that a user’s wallet has "received" bitcoin, what we mean is that the wallet has detected on the blockchain an UTXO that can be spent with one of the keys controlled by that wallet.

The exception to the output and input chain is a special type of transaction called the coinbase transaction, which is the first transaction in each block. This transaction is placed there by the "winning" miner and creates brand-new bitcoin payable to that miner as a reward for mining. This special coinbase transaction does not consume UTXO; instead, it has a special type of input called the "coinbase." This is how bitcoin’s money supply is created during the mining process, as we will see in mining.

In short, transactions are messages indicating to the Bitcoin network which inputs will be used to generate outputs. The transaction input is a reference to one or more outputs from previous transactions, indicating where the value comes from. The transaction output indicates the quantity to be sent and to which address, and may include an amount to be sent back to a sender's address as change.

The majority of transactions come with fees, which reward Bitcoin miners for their role in safeguarding the network. These fees also act as a protective measure, deterring potential attackers from overwhelming the network with lots of transactions. We will dive deeper into mining, as well as the fees and rewards that miners receive, in the mining chapter.

A financial institution acts as a single, central point of control and is responsible for deciding whether transactions are valid and accounting for balances.

Now that we know what a transaction is and how it works, one more question arises: Who will check whether the transactions are valid and account for post balances?

The solution to not depend on a trusted third party was to replicate the database (ledger).

In this case, anyone anywhere in the world can have and maintain the ledger without having to ask anyone for permission. Those who have and maintain a copy of the ledger are called network nodes. There is also no hierarchy between nodes, to the point that if a single one decides to censor a transaction or manipulate balances, his action will be immediately identified by all other nodes in the network.

The greater the number of nodes that exist and keep records updated, the greater the system's resilience. If one of us stops working, the others will continue.

So, the network is resilient to anyone joining or leaving at any time.

Remember the physical encyclopedias we used to rely on when researching? The companies behind them employed editors who were responsible for this content, and we can imagine the power they had in deciding what was worth mentioning, condemning, tolerating or ignoring.

Today, information is much more decentralized thanks to the efforts of more than 120,000 active editors who update the records of the famous Wikipedia. If any of these become corrupted, the risk of being able to edit a biased record and not be noticed is very low, since every edit is public and can be checked by anyone.

A real world example on how decentralization reduces the risk of corruption, manipulation or fraud.

Ok, then a constellation of nodes are responsible for validating transactions and keeping balances updated. But how do they all manage to keep all the ledgers in sync?

Imagine that two people are a node on the network, one of which is in Brazil and the other in the USA. The one in Brazil receives transaction A first and the other receives transaction B first.

Given that there are several transactions being made at all times, it takes time for all these transactions to propagate across the network (distance, connectivity, connection speed, servers, bandwidth), some nodes may receive transactions in a different order than other nodes . Therefore, there would be conflicting versions of the ledger.

Given that it is impossible to control how many transactions will be generated every second and that their propagation throughout the network of nodes will not be done instantly for each node, the solution was to aggregate the transactions within a block.

Imagine a bustling store with several vendors, each receiving and independently recording buying orders throughout the day. Like nodes in the Bitcoin network, these vendors might register transactions in a different order due to variations in processing times and customer interactions. However, at the close of business, a harmonization process begins.

Each vendor has their own ledger, a personal page of sorts, where they’ve noted down sales and transactions as they occurred. At the end of the day, all vendors come together to compare their ledgers. Through a consensus process, they agree upon a single ledger that accurately reflects all the transactions of the day, irrespective of the order in which they were initially recorded by individual vendors.

This agreed-upon ledger then becomes the official record, ensuring that every vendor has an identical and accurate account of the day’s transactions. This process mirrors the way transactions are aggregated into blocks in the Bitcoin network, with the entire network ultimately reaching consensus on the state of the blockchain, ensuring uniformity and trust across all participants.

Blocks are generated every 10 minutes, that is, much less frequently than transactions. This way it is easier for a block containing all transactions executed within those 10 minutes to reach all nodes before a new block is created.

So the network nodes now have two functions:

• Validate and propagate transactions;

• Validate, store and propagate blocks;

Since the process of recording node inputs has been shortened, nodes around the world now have more time to agree on the order (of blocks and not transactions). And consequently, there will be less conflict regarding the correct order of the blocks, than there would be if the system had to agree on the order of transactions.

But even if much less frequent, there is still the possibility of conflict regarding the order of the blocks. But we will explore this further in the Fork part. Once a transaction is inserted together with others within a block, then it is said to be confirmed with one confirmation. When the next block is added, right after the previous block where the transaction was, then it has two confirmations, and so on.

There is a balance here: If blocks were created once a day instead of every 10 minutes, it would be much easier for all nodes to agree on the block order, but it would make users have to wait 24 hours so that your transactions have the first confirmation.

Blocks

To understand how blocks work, we need to remember that a transaction is a message to the network saying from which addresses the funds will be used to be transferred to which address, and the value of that transaction. Also remember that if the sum of the values of the input addresses is greater than the quantity you wish to send, you will need to indicate the sender's own address so that the change can be sent.

What aggregates all this information and submits it to the network is an application we call a wallet. We will soon understand how they work. But for now, it's enough to know that the user just needs to choose the amount they want to transfer, the recipient's address and under the hood, the wallet takes care of the rest.

When you submit a transaction from a wallet, the wallet is connected to a network node, which in turn is connected to other network nodes. The Bitcoin network was designed so that transactions and blocks are broadcast throughout the network so that everyone agrees on the new balance status.

Any Bitcoin node that encounters a valid and previously unseen transaction will promptly relay it to all connected nodes, employing a propagation strategy referred to as flooding. As a result, the transaction spreads throughout the peer-to-peer network, ensuring that it reaches a substantial number of nodes in just a few seconds.

Once a transaction is created and sent to the Bitcoin network, it does not become part of the blockchain until it is verified and included in a block by a process called mining, which we will understand later.

Transactions that become part of a block and added to the blockchain are considered "confirmed," which allows the new owners of bitcoin to spend the bitcoin they received in those transactions.

Blockchain is a structure of chained blocks that contain transactions. Just like a bakery ledger whose structure is made up of sequential numbered pages that contain the sales made on each page.

Blocks are interconnected in reverse, with each one pointing back to its immediate predecessor in the chain. Frequently, people picture the blockchain as a vertical pile, where blocks are placed one atop another, and the first block (Genesis Block) forms the base of this pile. This stacked arrangement leads to the adoption of terminology such as "height" to denote the number of blocks separating a particular block from the initial one, and "top" or "tip" to identify the block that has been most recently added.

In the bakery’s ledger, the pages are sequential, so it's easy to figure out which page is linked to the previous one. In the case of Bitcoin blocks, it is a little more complicated. Each block has its own ID. This ID is a hash generated using the SHA 256 cryptographic model (we already understand what a hash function is and how it works).

And each block ID has a reference to the hash of the previous block in its header. So each block is linked to its predecessor going backwards in the blockchain to the first block (genesis block). So that if the hash of the previous block (parent block) changes, the hash of the current block will change too!

The hash of block 5, for example, is composed of the hash of block 4 and another random number. Therefore, if the content (transactions) of block 4 is changed, the hash of block 4 will change, which will consequently require the "hash of the previous block" component of block 5 to also change, and which will consequently change its hash. And therefore, the "hash of the previous block" component of block 6 to also change, changing its hash, and so on. This long chain of blocks is what guarantees the immutability of Bitcoin's transaction history.

But why doesn't a bad actor simply change the transaction history of a block for his own benefit? Remember that the hash (ID) of each block has a random number? To calculate it, a large computational effort is required (we will understand this better when we talk about mining), which makes it unfeasible both in terms of time and resources used.

But before we understand mining, let's understand the block better.

The block consists of a header and a list of transactions.

The header is made up of three components:

• Previous Block Hash: A reference to the hash of the previous (parent) block in the chain;

• Merkle Root: A hash of the root of the merkle tree of this block’s transactions;

• Nonce: A counter used for the Proof-of-Work algorithm;

Merkle Root? Nounce? Calm! We will soon understand them.

In fact, the header is made up of more components (version, date/time, difficulty). But just the previous ones are enough to understand the dynamics.

The combination of the previous block hash, the Merkle root and the nounce ensures that each block is unique and securely linked to the previous block in the blockchain.

Here's a simplified example to visualize the dynamics:

Previous Block Hash: ABC123 Merkle Root: XYZ789 Nonce: 42 Concatenating these values gives us the block header: ABC123XYZ78942.

The miners would then hash this block header (in reality, the process is more complex and involves double SHA-256 hashing) and try to find a hash value that is less than the target. If the hash is not less than the target, they will increase the nonce and try again. This process repeats until a valid block header hash is found (we will understand better in the mining chapter).

It's important to note that this is a simplified example and the actual process involves binary data and SHA-256 hashing, but I hope it helps you understand the basic dynamics of how a Bitcoin block header is constructed and how it plays a role in the Proof-of-Work mining process.

Merkle Root

To understand Merkle Root, we will need to understand Merkle Trees.

Each block within the Bitcoin blockchain contains a summary of all its transactions through a Merkle tree.

A Merkle tree, often referred to as a binary hash tree, serves as a data structure for the efficient summarization and verification of the integrity of extensive data sets. These binary trees are composed of cryptographic hashes. In computer science, the concept of a "tree" denotes a branching data structure, but these trees are typically represented inversely, with the "root" situated at the top and the "leaves" at the bottom in diagrams, as we will demonstrate in subsequent examples.

Merkle trees are used in Bitcoin to summarize all the transactions in a block, producing an overall digital fingerprint of the entire set of transactions, providing a very efficient process to verify whether a transaction is included in a block.

Construction: Hash Individual Transactions: Each transaction in a block is hashed using a cryptographic hash function like SHA-256. These hashes form the leaves of the tree.

Pair and Hash Again: The hashes of the transactions are then paired and hashed together. If there's an odd number of transaction hashes, the last hash is duplicated and hashed with itself to ensure that all nodes have a pair.

Repeat Until One Hash is Left: This process of pairing and hashing continues upwards in the tree until there is only one hash left. This top hash is called the "Merkle Root."

Example: Imagine a block with four transactions, Tx1, Tx2, Tx3, and Tx4.

Hash Transactions: First, hash each transaction: H(Tx1), H(Tx2), H(Tx3), H(Tx4).

Create Second Layer: Pair and hash the transaction hashes: H(H(Tx1)+H(Tx2)), H(H(Tx3)+H(Tx4)).

Merkle Root: Finally, hash the results of the second layer together to get the Merkle Root: H(H(H(Tx1)+H(Tx2)) + H(H(Tx3)+H(Tx4))).

And the hash of all those concatenated results is the Merkle Root, and is stored in the block header.

So, the Merkle Tree is utilized to efficiently and securely summarize all the transactions within a block. Irrespective of the number of transactions a block contains, be it a handful or thousands, the final Merkle Root derived from this tree will always be of a fixed size, specifically 32 bytes.

This consistency in size is achieved through the process of cryptographic hashing.

Each transaction is initially hashed, producing a fixed-size output, and these hashes are then paired, concatenated, and hashed again in successive layers of the tree. This process is repeated until a single hash remains, the Merkle Root. The nature of the cryptographic hash function ensures that the output is always of the same length, thus maintaining a uniform 32-byte size for the Merkle Root regardless of the quantity or size of the transactions in the block.

This fixed-size Merkle Root is a critical feature, as it simplifies the block header's structure and ensures the scalability and efficiency of the blockchain, making it easier to verify transaction inclusion without requiring the entire transaction list. But, how a node can verify that a specific transaction is included in a block, especially when it only downloads the block headers and retrieves a small Merkle path from a full node?

Light nodes don’t have all transactions because they don't download full blocks, just block headers.

In order to verify that a transaction is included in a block, without having to download all the transactions in the block, they use an authentication path, or merkle path.

And when I am going to make a transaction and don't run a full node, how can the light node in my wallet know that a transaction was made in the past and that it resulted in a balance for me and that I therefore have a balance to be sent to someone else?

When a light node wants to verify if a specific transaction is included in a block, it requests the Merkle path for that transaction from a full node. The Merkle path consists of the minimum number of hashes needed to link the transaction to the Merkle Root in the block header.

The full node provides the light node with the hash of the transaction in question, along with the hashes of other transactions that are paired with it at each layer of the Merkle Tree. The light node then recreates the path of hashes, starting from the specific transaction hash up to the Merkle Root.

The light node compares the recreated Merkle Root with the Merkle Root in the block header. If they match, it proves that the transaction is indeed included in that block, without the need for downloading all transaction data.

In the same example above, the light node can prove transaction D (Tx D) is included in the block with a path provided by a full node. The full node will provide the block header (Habcd), and the path: Hc and Hab.

The light node hash the transaction D (Tx d) with the hash pair provided Hc + Hd. It now has a new hash of this pair of transactions, which is Hcd. It can now pair this hash with the next one provided, which is Hab (Hab + Hcd). The result is Habcd. And it is easy to compare the final hash with the block header hash. If those match, it means transaction D is part of that block, and therefore a valid transaction in blockchain.

Imagine a classroom where two students are attending a lecture. One student, representing a light node, only writes down the table of contents of the lecture, which lists the main topics (akin to the block headers and Merkle Roots in Bitcoin). This student prefers a concise summary rather than detailed notes, saving time and effort.

The other student, representing a full node, diligently writes down every detail of the lecture, including all examples and discussions (comparable to recording all transactions in a Bitcoin block). This student's notes are comprehensive and contain everything covered in the lecture.

Now, when the student with just the table of contents needs to verify whether a specific topic (a transaction) was covered in the lecture, she needs to ask the student with the full notes.

The full-note student then provides a brief path (the Merkle path) from the specific topic back to the table of contents, showing where and how that topic fits into the lecture's overall structure. By following this path, the first student can confidently confirm the inclusion of the topic without having to go through the entire set of detailed notes.

This analogy represents how light nodes rely on full nodes in the Bitcoin network. Light nodes, with their limited record of block headers, can verify the existence of a specific transaction in a block by obtaining and verifying a small part of the information (the Merkle path) from the full nodes, which maintain a complete record of all transactions.

Using Merkle trees, a node can efficiently download only the block headers, and still ascertain whether a transaction is included in a block. This is achieved by obtaining a concise Merkle path from a full node. This method allows the light node to bypass the need to store or transmit the whole blockchain data, which can amount to several gigabytes. Light nodes, leverage these Merkle paths to authenticate transactions while avoiding the download of full blocks.

Nodes

The Bitcoin was created as a permissionless system that cannot be censored, and does not rely on any trusted third party like a financial institution.

So, since there are no trusted third parties to manage the creation and maintenance of blocks, how does it work in Bitcoin?

The solution is called Nodes.

Essentially, anyone, anywhere in the world, can become a node operator simply by downloading and running the Bitcoin software on their computer. This process requires no permission from any central authority.

A key characteristic of the Bitcoin network is that every node is equal; there is no hierarchy or special status among them. Each node independently verifies and processes transactions, contributing to the collective maintenance and security of the network.

By participating as a node, individuals contribute to the system, ensuring that the transactions and blocks remain accurate and up-to-date. This open and inclusive approach allows the Bitcoin network to be robust and resilient, as it is powered by a diverse and widespread community rather than a single centralized entity.

As long as all nodes keep an identical record of the blocks, we have a more resilient system. And if any node is forced to stop working, the others will continue.

After joining the Bitcoin network as a node, this new node begins to connect with others through a mechanism known as a "gossip network." This term describes the way information, specifically about new transactions and blocks, is disseminated across the network. In a gossip network, nodes communicate with each other in a manner akin to how people share information in a community: by passing it from one to another.

When a node receives new transaction data or a new block, it doesn't keep this information to itself. Instead, it immediately starts sharing this data with a few other nodes it is connected to. These nodes, in turn, relay the information to the nodes they are connected with, and so on. This chain reaction ensures rapid and widespread dissemination of the information across the entire network.

Each node acts autonomously, choosing which other nodes to connect with and share data. This decentralized approach not only makes the network more resilient to failures and censorship but also ensures that all nodes, regardless of their location or the time they joined the network, have an up-to-date and synchronized view of the blockchain.

Through this gossip network, nodes collectively maintain the integrity and continuity of the Bitcoin ledger. As each node receives and verifies the information, they update their own copy of the blockchain, thus keeping the record of all transactions up-to-date and consistent across the global network.

Although nodes in the Bitcoin network are hierarchically equal, they may take on different roles depending on the functionality they are supporting. There are some different types of nodes, but we will focus on two: The full node and the simplified payment verification (SPV) or light node.

Full nodes are nodes that maintain a full blockchain with all transactions. They uphold the integrity of the Bitcoin network by maintaining a complete and current copy of the Bitcoin blockchain, encompassing every transaction. These nodes independently build and validate this record, starting from the genesis block, the very first block, and extending to the most recent block known in the network.

A full blockchain node possesses the capability to independently and definitively verify any transaction, without needing to depend on or refer to any external node or source. To stay updated, a full blockchain node depends on the network to receive notifications about newly added blocks of transactions. Upon receiving these updates, the node verifies and integrates them into its own version of the blockchain.

Running a full blockchain node allow independent verification of all transactions without the need to rely on, or trust, any other systems.

If you wanna run one, it will require more than one hundred gigabytes of persistent storage (disk space) to store the full blockchain. And it will also take around three days to sync to the network.

When a new full node joins the Bitcoin network, its primary task is to construct a complete blockchain. Initially, it only knows the genesis block (block #0), which is preloaded in its software. To synchronize with the network, the node must download hundreds of thousands of blocks. This syncing process begins with the node comparing its blockchain height (number of blocks) with its peers using version messages.

The node identifies the missing blocks through a series of messages exchanged with its peers. First, it sends a getblocks message containing the hash of its top block. Peers with longer blockchains recognize this hash as belonging to an older block, indicating that the new node needs to catch up. They then send an inv (inventory) message to the new node, listing the hashes of the first 500 blocks it lacks.

The new node requests these blocks using getdata messages, specifying the required blocks using the hashes received. It manages the download process to avoid overwhelming any single peer and the network. As it receives each block, it adds it to its blockchain. This process of requesting and receiving blocks continues until the node has fully synchronized with the network, regardless of how many blocks it initially lacks. The same process is followed whenever a node goes offline and needs to catch up upon returning online.

Imagine a new student, Alice, joining a class midway through the school year. She's eager to catch up with her classmates, especially with an older student, Bob, who's known for diligently taking comprehensive notes since day one. Alice only has the first lesson in her notebook (akin to the genesis block in a node's blockchain).

To catch up, Alice starts by asking Bob about the latest lesson he's noted down. This is similar to a new node using version messages to understand the current length of its peers' blockchains. Bob, realizing Alice is behind, decides to help her by listing the titles of all the lessons she missed, much like the inv (inventory) message in the Bitcoin network.

Alice then requests the details of each missed lesson, starting with the earliest ones she lacks. Bob obliges, sharing his notes in manageable chunks, ensuring Alice isn't overwhelmed. This mirrors the new node fetching blocks using getdata messages based on the hashes received from its peers.

As Alice receives notes on each lesson, she diligently adds them to her notebook, gradually filling in the gaps. She continues this process, requesting more notes as she assimilates the previous ones, until her notebook is as complete as Bob's. In the Bitcoin network, this represents a node progressively downloading blocks until its blockchain is fully synchronized with the network.

Just like Alice, if a node ever falls behind (say, due to being offline), it repeats this process of requesting and receiving data to update its blockchain and stay in sync with the network.

Not everyone has the ability to store the full blockchain, or doesn't want to dedicate as much memory as is necessary. Many Bitcoin nodes are designed to run on space and/or power-constrained devices, such as smartphones.

For this kind of device, a simplified payment verification (SPV) method is used to allow them to operate without storing the full blockchain. It is also known as lightweight nodes.

Simplified Payment Verification (SPV) nodes operate differently from full nodes in that they only download the headers of blocks, bypassing the transactions contained within each block.

This approach significantly reduces the data size, with the blockchain headers being about 1,000 times smaller than the complete blockchain. Consequently, SPV nodes lack the capability to form a comprehensive view of all Unspent Transaction Outputs (UTXOs) in the network, as they are not aware of every transaction.

To verify transactions, SPV nodes employ an alternative method. Instead of independently verifying every transaction, they rely on other peers in the network to supply them with targeted segments of the blockchain. This method allows them to confirm transactions by obtaining only the necessary parts of the blockchain, relevant to their transactions, upon request.

Imagine a full node as a diligent student preparing for a comprehensive exam. This student has meticulously gathered and studied all the textbooks and lecture notes covering the entire syllabus. In contrast, an SPV node is like a student who, instead of studying all the materials, relies on summaries and key points provided by classmates. This student has a general understanding of the main topics but lacks the detailed knowledge of the entire curriculum.

Both students are capable of answering questions about the subject matter. However, the student with complete knowledge (the full node) can independently verify any fact or detail from the textbooks and notes. On the other hand, the student relying on summaries (the SPV node) can only verify information based on what they've been told or provided, without the ability to independently confirm every detail.

For instance, if asked about a specific historical event, the first student can reference the exact page in a textbook, while the second student might need to ask classmates for their notes or recall a summary they've read. This analogy illustrates how full nodes, with their comprehensive knowledge of the blockchain, can independently verify any transaction, whereas SPV nodes depend on others for partial information to validate transactions.

The security and privacy offered by full nodes and SPV nodes in the Bitcoin network significantly differ due to their operational methodologies. Full nodes provide a higher level of security and privacy. They achieve this by downloading and verifying every transaction on the blockchain, which inherently conceals which transactions or addresses they are specifically interested in or are using in their wallets. This comprehensive approach ensures that full nodes do not reveal any specific information about their transactions or holdings, maintaining robust privacy.

On the other hand, SPV nodes, while offering the advantage of requiring less storage and computational resources, compromise on privacy. SPV nodes download only block headers and a filtered list of transactions that are relevant to the addresses in their wallets. This selective process of receiving transactions inherently indicates to the network which addresses the SPV node is interested in. Consequently, SPV nodes inadvertently expose some information about the transactions or addresses they are monitoring, leading to reduced privacy.

This difference in privacy and security levels is a fundamental trade-off in the design of Bitcoin's network architecture. While full nodes provide a more secure and private way to interact with the Bitcoin network, they require more resources. In contrast, SPV nodes offer a more resource-efficient way to participate in the network at the cost of reduced privacy and reliance on full nodes for transaction verification. Therefore, users must weigh their needs for privacy, security, and resource efficiency when choosing between running a full node and an SPV node.

Mining / PoW

The Bitcoin system operates on a foundation of transactions, which are compiled into blocks. Approximately every 10 minutes, a new block is formed, encapsulating the latest transactions submitted to the network. This timing creates a balancing act between achieving consensus on the network's transactions and the speed at which these transactions are confirmed when included in a block.

Consider if blocks were generated only once every 24 hours. It would significantly simplify the process for all nodes in the network to reach an agreement on the sequence of these blocks. However, this would also mean that users would have to endure a lengthy wait to receive confirmation that their transactions have been validated and are secure.

Now, who takes on the task of creating these blocks? If a particular node were designated for this role, it could choose which pending transactions to include in the block before broadcasting it to the rest of the network. However, this approach reintroduces the issue of centralization, creating a single point of vulnerability susceptible to failure, coercion, and corruption.

The ingenious solution lies in decentralization: allowing any node on the network the opportunity to create blocks and disseminate them across the network. But this raises another crucial question: If every node has the capacity to create blocks, how do we ensure that only one block is produced every 10 minutes?

One could imagine a system where a random node is selected to create the next block. Yet, this leads to further queries: Who administers this selection process? How can we ensure that this selection is genuinely random and fair?

Satoshi Nakamoto, introduced an elegant solution to this conundrum. Since any node can create a block, to qualify for creating the next block, nodes engage in a form of competition. This contest is structured so that each participant has an equal chance of success, with the winning node able to provide verifiable proof of their victory. This proof enables other nodes in the network to validate and reach a consensus without the need for a central authority.

The reward for the node that triumphs in this competition? The privilege of creating the next block on the network!

This competition is known as "proof of work," and it's a cornerstone of how the Bitcoin network achieves a decentralized, global consensus. Through this process, Bitcoin maintains its integrity and trustworthiness, ensuring that no single entity can control or manipulate the transaction ledger.

So let's understand how a node can participate in this competition and create the next block.

Remember that in the Bitcoin network, after validating transactions, nodes will add them to the memory pool, also known as the transaction pool. This is where transactions wait until they can be included in a new block.A miner node operates like any other node in terms of collecting, validating, and relaying transactions. However, it also plays a unique role in forming these transactions into a candidate block.

To illustrate this, let's consider a miner node's activity during a typical transaction process, such as a retail purchase. The transaction from this purchase is included in a newly mined block. For our example, we'll assume that the miner node is responsible for mining this particular block.

The miner node maintains a local copy of the blockchain and constantly updates it with new blocks mined by other nodes. While it is mining the actual block, it also listens for transactions to include in the next block. Simultaneously, it listens for new blocks discovered by other nodes. When the miner node receives the latest block, it signifies the end of the competition for the last block and the start of the new competition for the actual block.

During the time it took to mine the last block, the miner node was collecting transactions in preparation for the next block. These transactions accumulate in the memory pool. After validating the latest received block, the miner node compares it against all transactions in the memory pool. Any transaction already included in the last block is removed from the pool. The remaining transactions in the memory pool are unconfirmed, awaiting inclusion in a new block.

The miner node immediately starts constructing a new, empty candidate block for the next block number. This block is termed a 'candidate' because it is not yet a valid block—it lacks a valid Proof-of-Work. It only becomes a valid block if the miner node successfully finds a solution to the Proof-of-Work algorithm (we will see soon how this is done).

As the miner node incorporates transactions from the memory pool into the new candidate block, the block begins to take shape with various transactions and their associated transaction fees.

The process of selecting transactions for the next block by a mining node is a strategic one, primarily driven by transaction size and fees. Each transaction within the network has two key attributes: its size, measured in bytes, and the transaction fee, which is the amount the sender is willing to pay to have the transaction included in a block (as we saw in the transaction chapter).

When a mining node prepares to create a new block, it faces the challenge of maximizing its potential reward while adhering to the block size limit set by the Bitcoin protocol. The block size limit is a cap on the amount of data each block can contain, ensuring that blocks are not too large to be quickly propagated through the network.

Given these constraints, the mining node adopts a strategy of selecting transactions that strike a balance between the fees they offer and the space they occupy in the block. Typically, transactions with higher fees are more attractive to miners because they represent a greater reward for the work done to mine the block. Therefore, a miner will often prioritize transactions with higher fees per byte.

The node assesses the available transactions in the memory pool, comparing their sizes and fees. The goal is to include as many high-fee transactions as possible, optimizing the use of the block's capacity to maximize the total fees collected. This is akin to a puzzle where the miner must fit various-sized pieces (transactions) into a set space (the block) in a way that maximizes the value (fees).

However, this doesn't mean that only high-fee transactions are selected. Depending on the transaction landscape at the time, a miner might also include smaller or lower-fee transactions to fully utilize the block's capacity, especially if there are not enough high-fee transactions to fill the block.

This selection process is crucial as it affects not only the miner's rewards but also the speed at which transactions are confirmed on the network. Transactions with higher fees tend to be confirmed more quickly, as they are more likely to be picked up by miners, while those with lower fees may have to wait longer.

In summary, a mining node selects transactions for the next block based on a careful consideration of transaction size and fees, aiming to maximize the fees collected within the constraints of the block size limit. This method ensures an efficient and rewarding mining process while maintaining the smooth operation of the Bitcoin network.

Given the effort, energy, and resources required to operate as a mining node in the Bitcoin network, you might wonder what incentivizes nodes to undertake this role.

The answer lies in the rewards that mining nodes receive for their critical contribution to the network's functioning.

In addition to the transaction fees collected from users for including their transactions in a block, mining nodes are also rewarded with a special type of transaction known as a "coinbase transaction".

This coinbase transaction is unique and serves as the primary incentive for nodes to participate in the mining process.

When a mining node successfully creates a new block, it includes the coinbase transaction at the beginning of this block. This transaction is unique in that it creates new bitcoins, which are awarded to the miner. The amount of bitcoins awarded in the coinbase transaction is predetermined by the Bitcoin protocol and is adjusted over time through an event known as "halving" (we will understand better later). This reward serves as compensation for the miner's expenditure of computational power and energy in solving the problem required to find a valid Proof-of-Work for the new block.

The combination of transaction fees and the coinbase reward constitutes the total reward for a miner. This dual-reward system compensates miners for the resources expended in maintaining and securing the network.

The coinbase transaction differs fundamentally from regular transactions. Unlike standard transactions, which consume Unspent Transaction Outputs (UTXOs) as inputs, the coinbase transaction has only one input, known as the "coinbase." This unique input effectively creates bitcoin out of nothing. Additionally, the coinbase transaction typically has one output, which is the payment to the miner's own Bitcoin address.

Now that the mining node has carefully selected which transactions will be included in the next block and indicated its reward through the coinbase transaction, the next crucial step is to construct the block header.

It serves as a sort of digital fingerprint for the block, encapsulating key information in a compact and secure format. The header includes several vital pieces of data:

Version Number: Indicates the version of the Bitcoin protocol being used.

Previous Block Hash: A reference to the hash of the immediately preceding block in the blockchain, linking the new block to the existing chain in a chronological and immutable sequence.

Merkle Root: A unique identifier derived from the hashes of all transactions included in the block, including the coinbase transaction. This ensures the integrity and immutability of the transactions within the block

.

Timestamp: Records the time when the block was created.

Difficulty Target: A representation of the current difficulty level for mining new blocks, which adjusts over time to maintain the average time between blocks.

Nonce: A variable number that miners change during the mining process to try and achieve a hash below the difficulty target.

To facilitate understanding, in the following example, we will only use the fields: Previous Block Hash, Merkle Root, and Nonce.

Merkle Root:

As we have already seen, this process involves summarizing all the transactions in the block using a structure known as a Merkle tree. This is done to incorporate the Merkle root into the block header, which serves as a comprehensive yet efficient summary of all the transactions in the block.

The Merkle tree starts with the coinbase transaction, which is always the first transaction in the block. Following this, all other transactions that the miner has selected for inclusion in the block are added. To construct a Merkle tree, there must be an even number of leaf nodes. If the number of transactions is odd, the last transaction is duplicated to create an even number of leaf nodes.

Each leaf node in the Merkle tree is a hash of a single transaction. These transaction hashes are then paired and hashed together, which forms the next level of the tree. This process of pairing and hashing continues upwards through the tree, with each level being a hash of its predecessor, until only one hash remains. This final hash is the Merkle root, a single, compact 32-byte value that uniquely represents all the transactions in the block.

The Merkle root is then added to the block header. It acts as an efficient and secure way to verify the presence and integrity of any transaction within the block. By using a Merkle tree, it is possible to check whether a specific transaction is included in a block without needing to hold the entire list of transactions.

Nonce:

In the Hash Chapter, we talked about an important concept: the 'nonce.' A nonce is essentially a random number that serves as a variable input in the hash function used in block creation. The unique property of a nonce is that even a minor change in its value can result in a drastically different output from the hash function. This characteristic is fundamental to the mining process.

For each block header, the mining node selects a nonce and inputs it into the hash function along with the other components of the header. The output of this function, or the hash, is then evaluated against the network's current Difficulty Target.

The primary objective in mining is to find a nonce that, when used in the hash function, produces an output (block hash) that meets the Difficulty Target. This target defines the required conditions for a valid block hash, usually a hash that starts with a certain number of zeros. Since the output of the hash function is unpredictable, the only way to achieve this is through trial and error, by trying a vast number of different nonce values. This process is known as 'proof of work' and it requires substantial computational effort.

When a miner finally discovers a nonce that produces a hash meeting the Difficulty Target, it means they have successfully mined a block. This nonce is then included in the block header, and the new block is broadcast to the rest of the network for verification and addition to the blockchain. The discovery of the correct nonce, thus, is the pivotal moment in the mining process, enabling the creation of a new block and the reward that comes with it.

Let's simulate an example with these variables to illustrate how a mining node operates during the mining process:

Previous Block Hash: Suppose the hash of the previous block in the blockchain is '12345'. This value is a part of the block header for the next block being mined.

Merkle Root Calculation:

Transactions in the block: TX A, TX B, TX C, TX D.

Hashing these transactions in pairs:

TX A and TX B together form HASH X.

TX C and TX D together form HASH Y.

Combining HASH X and HASH Y to form the Merkle Root: HASH Z.

Mining Process with Nonce:

The mining node starts with nonce = 0.

The block header constructed is: '12345HASHZ0'.

Hash (SHA-256) of this header: '0e1bef837d8fda573b44be80971339a4df60888f70425b0af23028a686824556'.

This hash does not meet the Difficulty Target (which, for our example, is a hash starting with '00').

The node then increments the nonce to 1.

New block header: '12345HASHZ1'.

New hash: '1881668681ea58bdc05993655d9714252389e93fb0dec44d5f7987e5169cde57'.

Again, this hash does not meet the Difficulty Target.

The node continues this process, incrementing the nonce each time and recalculating the hash, until it finds a nonce that, when combined with the other parts of the header, produces a hash that meets the Difficulty Target.

To get to nounce, I had to create a program to simulate this mechanism. The goal was to iterate through nonce values until the SHA-256 hash of the block header met the specified difficulty target. In this case, the target was a hash that begins with '00'.

To my fascination, the program had to test 369 (0 is one attempt) different nonce values before it successfully found one that met the criteria. The winning combination turned out to be '12345HASHZ368'. This instance clearly demonstrates the trial-and-error nature of the mining process and the computational work involved in finding the correct nonce.

Verifying the correct nonce is made simple thanks to the SHA256 hashing algorithm. Once a miner finds a nonce that they believe is correct, like '368' in our example, any node in the system can easily check its validity. They just append this nonce to the block data, like "12345HASHZ368", and run it through the SHA256 function. If the output hash meets the difficulty target (starts with 00), then the nonce is verified as correct.

But what if the difficulty target were more stringent? For instance, suppose the requirement was a hash starting with '000'. In this scenario, my program would have to iterate through many more nonce values to find a match. To illustrate, the program would need to test nonce values up to '8976' before finding a hash that meets this more challenging target. Specifically, the input '12345HASHZ8976' would yield the hash '000be772f6de64a461425df53c701935c6a0a6ee0fcf60de6b510446e12546fc', which satisfies the '000' starting condition.

This example underscores how increasing the difficulty target exponentially increases the computational effort required in mining.

In conclusion, the extensive and meticulous process a mining node undergoes to find the correct nonce, as demonstrated in our example, epitomizes what is commonly referred to as 'mining' in the Bitcoin system. This mining is not a physical act, but rather a computational one, where nodes in the network engage in a rigorous and competitive process of trial and error to solve a cryptographic puzzle.

The essence of this puzzle is to discover a nonce value that, when combined with other components of a block header and processed through a hash function (like SHA-256), produces a hash output that meets the network's difficulty target. This target is a critical part of the network's design, ensuring that blocks are generated at a consistent rate, regardless of the overall computational power of the network (we will detail this process shortly).

Mining is thus a cornerstone of the Bitcoin ecosystem. It serves multiple purposes: it secures the network by making it computationally challenging to alter any aspect of the blockchain, it introduces new bitcoins into the system in a controlled and predictable manner, and it incentivizes participants to contribute their computational resources to maintain and operate the network.

The effort expended by nodes in finding the correct nonce is a testament to the decentralized and competitive nature of the Bitcoin network. It underscores the ingenuity of the proof-of-work mechanism, where the combined efforts of numerous miners ensure the integrity, security, and continuity of this groundbreaking digital currency system.

Do you still believe that mining blocks on the Bitcoin network is solving an extremely complex mathematical problem?

We hear this explanation almost every day, but the ASICs (Application-specific integrated circuit) that are hardware used for mining are optimized to perform a specific task.

And what specific task is that?

Trial and error!

A good analogy is those padlocks with sequences of numbers. There is no mathematical formula that, if solved, will open the lock. The only way to open it is to discover the sequence of numbers, and for that the only possibility is to try and try (0000, 0001, 0002, and so on).

Once discovered, it is easily verified by others, as well as the Bitcoin network.

What the Bitcoin network algorithm does is indicate an output and miners need to test several inputs until they reach that output (marked by the number of zeros at the beginning of the string).

In other words: trial and error!

The more miners on the network, the more attempts are made, the faster the input is discovered, and consequently the faster the block is mined. In order for the mining time of each block to remain close to 10 min, every two weeks the algorithm adjusts the difficulty (as if it were adding another number to the lock sequence).

And now maybe a question is hanging over your head: In Bitcoin's decentralized system, any node can contribute computing power to mine blocks, earning block rewards and transaction fees. But what happens if many nodes decide to mine simultaneously? Wouldn't this collective effort lead to finding the correct nonce more quickly and thus creating new blocks in less time than the standard 10 minutes?

This is a pertinent question and touches on a crucial aspect of Bitcoin's design — the difficulty adjustment mechanism. Bitcoin is ingeniously programmed to maintain a consistent pace of block creation, approximately one block every 10 minutes, regardless of the total computational power on the network.

Here's how it works: Bitcoin's protocol includes a mechanism to adjust the mining difficulty. This adjustment occurs every 2,016 blocks. The system evaluates the average time it took to mine the previous 2,016 blocks. If the average mining time was less than 10 minutes per block, the protocol increases the difficulty of mining. Conversely, if the average time was more than 10 minutes, the difficulty is decreased.

The adjustment in difficulty is primarily achieved by changing the number of leading zeros required in the hash output of the block's header. The more zeros required, the more challenging it is to find a valid hash, and thus, the higher the difficulty. This mechanism ensures that as more computing power joins the network, the difficulty of mining increases, keeping the block creation rate steady.

This difficulty adjustment is a cornerstone of Bitcoin's functionality, allowing it to remain secure and stable in the face of fluctuating mining power. It's a self-balancing system that adapts to the total mining power.

Imagine the Bitcoin network is like a treasure chest locked with a numerical padlock. Each gear on the padlock has numbers ranging from 0 to 9, and the correct combination of these numbers is required to open the lock. In this analogy, the padlock represents the cryptographic challenge of finding the right hash, and the numbers on the gears represent the nonce that miners are trying to guess.

When only a few people (miners) are trying to open the padlock, it takes a considerable amount of time to try every possible combination on a 3-gear padlock (akin to a hash with fewer leading zeros). However, as more people join in the effort, the collective ability to try different combinations increases significantly. Soon, they find that they can open a 3-gear padlock (solve the hash puzzle) in less than 10 minutes.

To maintain the challenge and ensure that the treasure chest (Bitcoin block) doesn't get opened too quickly, the padlock is replaced with one that has an additional gear, making it a 4-gear padlock (equivalent to increasing the number of leading zeros in the hash target). Now, with this more complex lock, even with more people trying, it takes approximately the same amount of time to find the right combination as it did initially with fewer people and a simpler lock.

This ongoing adjustment of the padlock's complexity mirrors Bitcoin's difficulty adjustment mechanism. As more miners join the network and contribute greater hashing power, making it easier to find the correct hash, Bitcoin automatically adjusts the difficulty by essentially adding more 'gears' to the cryptographic 'padlock'. This ensures that the rate of unlocking new blocks (or opening the treasure chest) remains consistent, roughly every 10 minutes, regardless of the number of participants or their combined computational power.

While discussing the difficulty adjustment mechanism in Bitcoin's mining process, it's worth noting a curious aspect rooted in the early code of the Bitcoin Core client. The target recalibration for mining difficulty, intended to occur every 2016 blocks, actually has a slight quirk due to an off-by-one error in the original programming.

Instead of basing the adjustment on the total time it took to mine the intended 2016 blocks, the algorithm mistakenly calculates this adjustment using the time taken for only 2015 blocks. This slight deviation, while seemingly minor, results in a consistent bias in the recalibration process. The outcome is a subtle but persistent tilt towards increasing the mining difficulty by approximately 0.05%.

The difficulty adjustment mechanism is not influenced by the price of Bitcoin, the number of transactions processed, or the value of these transactions. Instead, it's directly proportional to the collective effort exerted by the mining nodes – essentially, the amount of computational power and, by extension, the electric energy consumed in the mining process.

This means that the amount of hashing power, and consequently the electricity used to secure the Bitcoin network, is entirely independent of transactional activity. Bitcoin's capacity to scale, gain wider adoption, and maintain its security does not inherently require an increase in hashing power from its current levels. The ongoing increase in hashing power primarily reflects market dynamics, with new miners entering the market to compete for mining rewards.

The security of the Bitcoin network hinges on having sufficient hashing power, predominantly under the control of miners motivated by rewards and operating honestly. This adequate level of hashing power is vital for preventing potential takeover attacks and ensuring the network's overall security.

Furthermore, the difficulty of mining in the Bitcoin ecosystem is closely tied to the cost of electricity and the exchange rate of Bitcoin against the currency used to pay for this electricity. High-performance mining systems, operating at the peak of current technological capabilities, convert electricity into hashing computations as efficiently as possible. Therefore, the mining market is significantly influenced by the price of one kilowatt-hour of electricity in terms of Bitcoin. This price determines the profitability of mining operations, thereby influencing the incentives for miners to either enter or exit the mining market.

Once a mining node discovers a nonce that satisfies the Bitcoin network's difficulty target, what happens next?

The node first propagates the new block, along with the winning nonce, across the network. This allows other nodes to quickly and easily verify that the nonce meets the target requirements.

Upon receiving the new block, other nodes in the network perform their validation checks. Each node independently verifies the block against a set of predefined criteria to ensure its validity. As the block passes through the network, it is added to each node's copy of the blockchain, effectively extending the blockchain to a new height.

When mining nodes validate the new block, they stop their efforts to mine a block at the same height and immediately begin working on the next block in the chain. They use the newly discovered block as the "parent" for this next block. This act of building upon the newly discovered block is akin to casting a vote with their mining power, endorsing the new block and the chain it extends (this will be important later when we discuss situations where two blocks are created at the same time).

The next step in Bitcoin's consensus mechanism involves each node on the network independently validating each new block. As the solved block propagates through the network, each node conducts a series of tests to validate it before passing it on. This process ensures that only valid blocks are circulated within the network. It also means that miners who adhere to the network's rules and act honestly have their blocks added to the blockchain, earning them the corresponding rewards. Conversely, miners who attempt to act dishonestly have their blocks rejected, forfeiting the reward and wasting the effort and electricity used to find a Proof-of-Work solution.

Among the criteria used by nodes to validate a new block are several key parameters. These include ensuring that the first transaction in the block is a coinbase transaction (preventing miners can’t write themselves a transaction for a thousand bitcoin instead of the correct reward), verifying that the block's size is within acceptable limits (preventing a mining node from including an excessive number of transactions to garner more fees), and confirming that the block header's hash is equal to or less than the current target. These and other criteria form a comprehensive checklist that each block must pass to be accepted into the blockchain, maintaining the network's integrity and trustworthiness.

Once a node in the Bitcoin network validates a new block, its next step is to integrate this block into the existing blockchain. This involves assembling a chain by connecting the newly validated block to the previously established blocks.

The concept of the "main chain" is central to understanding how the Bitcoin network operates. At any given moment, the main chain is defined as the valid chain of blocks with the most cumulative Proof-of-Work associated with it. Under normal conditions, this is also the chain with the greatest number of blocks. However, in cases where two chains are of equal length, the one with more Proof-of-Work takes precedence. Alongside the main chain, there are often branches with blocks that are siblings to those on the main chain. These sibling blocks are valid but are not part of the main chain. They are retained for future reference, in case one of these branches gets extended and surpasses the main chain in terms of cumulative work (we will see more when talking about forks).

When a node receives a new block, it endeavors to place this block within the existing blockchain structure. Each block contains a "previous block hash" field, which acts as a reference to its parent block. The node's task is to locate this parent block within the blockchain. In most cases, the parent is found at the "tip" of the main chain, meaning the new block effectively extends the main chain.

As an analogy, let’s imagine the Bitcoin blockchain as a growing train made up of a series of connected cars, each representing a block. The train is constantly moving forward, with new cars (blocks) being added to the end of the line.

Each time a new car (block) arrives, the station master (node) checks to ensure it's meant to connect to the very last car of the train (the most recent block in the blockchain). This check is done by examining a unique identifier or code on the new car, which should match the code of the last car in the train. This identifier is akin to the "previous block hash" in a Bitcoin block, linking each new block to its predecessor.

If the codes match and everything checks out, the station master attaches the new car to the end of the train, extending the length of the train (the blockchain). This process is methodical and ensures that each new addition is correctly placed, maintaining the train's (blockchain's) integrity.

Occasionally, there might be situations where two cars arrive almost simultaneously or where a car is meant to attach to an earlier part of the train. These are like the branching scenarios in the blockchain. The station master keeps these cars on a separate track (branch of the blockchain), just in case the main train line needs to be reconfigured or extended differently in the future.

Forks

But what happens if two mining nodes simultaneously find a nonce that meets the output target and each propagates its own block to its neighbors?

This is indeed a possible and natural occurrence in the decentralized structure of the Bitcoin blockchain. Due to the distributed nature of the network, copies of the blockchain across different nodes aren't always perfectly synchronized. Transmission delays and the sheer size of the global network can lead to blocks arriving at different nodes at different times. This can result in nodes having different perspectives of the blockchain's current state.

In such scenarios, where there's a split in the blockchain due to different nodes receiving different blocks at the same time, the phenomenon is known as a "fork." This term aptly describes the situation where the blockchain diverges into two potential paths, much like the prongs of a fork.

Forks in the blockchain occur naturally and are often accidental, stemming from the aforementioned transmission delays. Before a fork, all nodes share the same perspective of the blockchain. A fork happens when there are two valid blocks at the same height, both competing to be added to the blockchain. This typically occurs when two miners solve the Proof-of-Work algorithm almost simultaneously.

Each miner broadcasts their own 'winning' block to their neighbors, starting the propagation across the network. Nodes that receive a valid block add it to their blockchain, extending it by one block. If a node then receives another valid block that extends the same parent block (at the same height), it adds this block to a secondary chain, creating a fork in its version of the blockchain.

Consequently, different nodes might initially 'see' and add different blocks first, leading to two competing versions of the blockchain temporarily existing.

And how are these forks resolved?

When two valid blocks compete at the same height, creating a fork, the network follows a simple but effective rule to achieve consensus and maintain the blockchain's integrity.

This rule is centered around the concept of the "longest chain," which is often synonymous with the chain that has the most cumulative Proof-of-Work.

The logic here is straightforward: nodes in the network will always consider the longest chain as the valid one. This means that when nodes encounter a fork, they temporarily follow the first block they receive. However, as soon as a longer chain (one with more cumulative work) becomes apparent — typically when a new block is added to one of the forks — the nodes switch to this longer chain.

In practice, this means that when one of the competing forks at the same height grows longer than the other (by having an additional block added to it), the network collectively adopts this chain. The blocks in the shorter fork become 'orphaned' and are discarded in terms of transaction confirmations and rewards. However, the transactions in these orphaned blocks are not lost; they return to the pool of unconfirmed transactions and are eligible for inclusion in future blocks.

The key to resolving forks is the continuous, competitive process of block creation. Miners are constantly working on finding new blocks, and as soon as one fork outpaces the other, the network achieves consensus on the longer, more work-intensive chain. This process ensures that even if forks occur, the Bitcoin blockchain quickly reconverges to a single, consistent state.

Imagine two mining nodes, Node A and Node B, both diligently working to solve the Proof-of-Work algorithm for the next block in the Bitcoin blockchain. Almost simultaneously, each node finds a solution, but for different blocks. Node A propagates a block (let's call it Block Ba) to its neighbors, while Node B propagates another block (Block Bb) to its neighbors. Since both blocks are derived from the same parent block, they are both valid but competing extensions of the blockchain.

In the network, different nodes receive these blocks at different times due to the nature of distributed networks. Some nodes receive Block Ba first and add it to their version of the blockchain. When Block Bb arrives at these nodes, they recognize it as a valid block extending the same parent and attach it as a fork. The same happens in reverse for nodes that received Block Bb first.

Now, the network temporarily has two competing versions of the blockchain: one extended by Block Ba and the other by Block Bb. Miners in the network continue their work, now focusing on creating a new block that will use either Block Ba or Block Bb as its parent, depending on which block they received first.

As mining continues, let's say the miners building on top of Block Ba find a new block, which we'll call Block Baa. This block extends the chain that started with Block Ba. They quickly propagate Block Baa throughout the network. Upon receiving this new block, the entire network recognizes it as a valid extension of the Ba chain, making the Ba-Baa chain longer than the chain ending with Block Bb.

At this point, the network collectively abandons Block Bb in favor of the longer Ba-Baa chain. The transactions that were in Block Bb, but not in Block Ba or Block Baa, are returned to the mempool, awaiting inclusion in future blocks.

The network now reconverges on a single version of the blockchain, with Block Baa as the latest block. All miners across the network update their efforts, beginning to work on new candidate blocks that reference Block Baa as their parent.

Monetary Policy

If miners receive rewards in bitcoins for creating blocks, and any node is free to mine, what stops the network from continuously mining and creating an excessive number of bitcoins? How does the Bitcoin system control the issuance of bitcoins?

The concept of 'mining' in the Bitcoin ecosystem is aptly named, as it draws a parallel with the extraction of precious metals like gold. This analogy extends to the reward structure designed by Bitcoin's creator, Satoshi Nakamoto, which is characterized by diminishing returns over time.

Initially, to incentivize participation and bootstrap the network, the rewards for mining a block were set high. In 2009, when Bitcoin was first launched, the reward for mining a single block was 50 bitcoins. This substantial reward was aimed at attracting early adopters, encouraging them to contribute their computing power to maintain and secure the network.

However, Nakamoto envisioned a system where this reward wouldn't remain constant. The protocol includes a mechanism known as 'halving', which is fundamental to Bitcoin's monetary policy. Approximately every four years, or after every 210,000 blocks mined, the reward for mining a new block is halved. As a result, the issuance of new bitcoins gradually slows down over time. This halving process has already occurred several times since Bitcoin's inception, with the block reward decreasing from 50 bitcoins to 25, then to 12.5, then to 6.25 and most recently to 3.125 bitcoins per block.

The reason for this diminishing reward structure is twofold:

Controlled Supply: It ensures a controlled and limited supply of bitcoins. By design, there will only ever be 21 million bitcoins in existence. This finite supply mimics the scarcity of precious metals and contrasts with fiat currencies, which can be printed in unlimited quantities by central banks.

Network Maturity: As the Bitcoin network matures and becomes more robust, the need for large block rewards diminishes. The expectation is that as Bitcoin becomes more widely adopted, transaction volumes will increase, and the transaction fees alone will be sufficient to incentivize miners to continue validating and securing the network.

Through this innovative approach, Bitcoin introduces a deflationary model where the issuance of new coins slows down over time, adding a layer of predictability and stability to its monetary policy.

Like many others, you might be curious about why the Bitcoin system is designed to have a maximum of 21 million bitcoins. Why precisely 21 million? Why not 20 million, or 22 million? Satoshi Nakamoto, the creator of Bitcoin, didn't explicitly state the reasoning behind this specific figure in any of his writings or communications, leaving room for speculation and analysis.

To understand the logic that leads to the 21 million cap, we need to look at the key parameters Satoshi set for Bitcoin:

Block Creation Interval: Satoshi designed the system such that new blocks are created approximately every 10 minutes.

Initial Block Reward: The initial reward for mining a new block was set at 50 bitcoins.

Halving Interval: Satoshi implemented a halving event every 210,000 blocks, roughly every four years, during which the block reward is halved.

When we crunch the numbers based on these parameters, an interesting picture emerges. Starting with a 50 bitcoin reward, which halves every 210,000 blocks, the total number of bitcoins that will ever be created closely approaches 21 million.

Here's a simplified breakdown:

The first 210,000 blocks yield 50 bitcoins per block, totaling 10.5 million bitcoins.

The next 210,000 blocks yield 25 bitcoins per block (after the first halving), totaling 5.25 million bitcoins, and so on.

The sum of this series is a finite number due to the halving process, which is a geometric series. As the reward halves with each successive set of 210,000 blocks, the total number of bitcoins approaches 21 million but never quite reaches it. The system is designed to reach this limit around the year 2140.

Thus, the 21 million cap appears to be a consequence of the initial parameters set by Satoshi. It's a deliberate design choice that introduces scarcity to the digital realm, much like precious metals in the physical world. This scarcity is a fundamental aspect of Bitcoin's value proposition, distinguishing it from fiat currencies that can be printed without limit. It's this feature that has led many to view Bitcoin as 'digital gold', a store of value in the digital age.

Soft Forks and Hard Forks

Just like any other technology, changes and improvements are essential to adapt to new requirements, introduce enhancements, or rectify bugs. In the context of Bitcoin, these changes often pertain to the 'rules of consensus.' These rules are fundamental to the Bitcoin protocol, determining the validity of transactions and blocks. They form the backbone of collaboration between Bitcoin nodes, ensuring that all local perspectives converge into a single, consistent blockchain across the entire network.

However, updating the rules in a consensus-based system like Bitcoin is inherently more complex than typical software updates. It demands a high level of coordination among all network participants. Unlike traditional software that can be updated with a new version download, changes in Bitcoin’s consensus rules require agreement and simultaneous adoption by the entire network of nodes. This is because each node independently validates transactions and blocks; any divergence in rules could lead to inconsistencies in the blockchain.

The process of agreeing on changes to Bitcoin's consensus rules depends on the nodes updating their software. Each node in the network runs a version of the Bitcoin software that enforces specific rules for validating transactions and blocks. When a proposed change to these rules emerges, it's typically introduced through a new version of the Bitcoin software.

The way nodes validate and agree upon a change in consensus is by individually choosing to update their software to the version that incorporates the new rules. This updated software version is programmed with the proposed changes to the consensus rules. By downloading and running this new version, a node signals its agreement to adopt and enforce the updated rules.

However, this decision is left to the discretion of each node operator. They must assess the proposed changes and decide whether to accept them by updating their software or to continue running the existing version. This distributed decision-making process is a key aspect of Bitcoin's decentralized nature.

The updated software, once running, processes transactions and blocks according to the new set of consensus rules. If a significant portion of the network's nodes adopts the update, the new rules become the de facto consensus rules of the network.

But what happens if only part of the network wants to upgrade to new consensus rules while the rest do not?

This situation can lead to a phenomenon known as a 'fork' in the Bitcoin network. A fork, in this context, represents a divergence in the blockchain due to differences in consensus rules adopted by different groups within the network.

There are two main types of forks that can occur in this scenario: hard forks and soft forks. Both types of forks represent changes to the blockchain's protocol, but they differ in compatibility and impact on the network.

Hard Forks

A hard fork represents a significant change to the Bitcoin network's protocol, one that fundamentally alters the rules by which blocks and transactions are deemed valid or invalid. Unlike other updates, a hard fork necessitates that every node in the network upgrades to the new protocol to continue participating effectively. This is because the changes introduced are not backward compatible; they create conditions where blocks or transactions previously considered invalid may now be valid, or vice versa.

When a hard fork occurs, if only a subset of the network adopts the new rules while others do not, the result is a permanent divergence into two separate blockchains. Each of these blockchains operates under its distinct set of consensus rules, and over time, they evolve independently of each other. This separation is why a hard fork is described as a definitive split — the network does not reconverge onto a single chain after the fork.

Hard forks can happen for various reasons, including fixing a critical bug or implementing a deliberate change in how the consensus rules are applied. However, coordinating a hard fork is a complex process that requires all network participants to agree on and adopt the new rules. Nodes that do not upgrade to the new set of consensus rules post-fork find themselves on a different blockchain. In essence, changes brought about by a hard fork lack forward compatibility, meaning systems that don't upgrade can't recognize or validate transactions and blocks created under the new rules once the fork occurs.

Let’s imagine a scenario where the Bitcoin software is updated with a change in the consensus rules. Starting from block height 5, miners using this new implementation will start producing blocks with a size limit of 2 MB, an increase from the standard 1 MB limit.

When a miner running the updated software mines block 5b, it potentially includes more transactions than could fit in the standard 1 MB block. This new block, adhering to the 2 MB limit, marks the beginning of a divergence in the blockchain.

Nodes and miners that haven't updated their software to accommodate the 2 MB block size see block 5b as invalid. It violates their rule of a 1 MB block size limit. Consequently, these nodes reject block 5b and its transactions, choosing not to propagate it. Meanwhile, they continue mining on top of block 4, aiming to produce a block 5a that conforms to the 1 MB size limit.

This leads to a split in the blockchain: the "b" chain, where blocks follow the new 2 MB size rule, and the "a" chain, which sticks to the original 1 MB limit. Miners on the "b" chain accept and mine larger blocks, while those on the "a" chain continue to reject them. The two chains evolve independently, each adhering to its version of the block size rule.

Once the fork occurs due to the change in consensus rules – in this case, the increase in block size limit – the network's response intensifies the split. Nodes adhering to the original consensus rules (the 1 MB block size limit) not only reject transactions and blocks created under the new 2 MB rule but also take measures against nodes transmitting this information. These original nodes will temporarily ban and disconnect from any nodes that send them transactions or blocks that don't comply with their version of the rules. This reaction effectively partitions the network.

As a result of this partitioning, two distinct networks emerge: one comprised of nodes operating under the old rules and the other consisting of nodes following the new rules. A single block or transaction adhering to the new rules becomes a catalyst for this division, as it ripples through the network and leads to a clear split. Nodes on each side of the fork will only communicate and connect with other nodes that share their consensus rules.

In parallel with the network partition, a division also occurs in the mining power and the blockchain itself. Miners who have upgraded to the new rules begin mining on top of blocks that follow these rules, such as the 2 MB blocks in our example. Conversely, miners who continue operating under the old rules mine a separate chain that maintains the original 1 MB limit. Due to the network's division, these groups of miners are unlikely to receive each other's blocks, as they are now part of two separate and distinct networks.

Each network continues to grow its own version of the blockchain, following its specific set of consensus rules. This results in two parallel chains, each validated and extended by a segment of the original network that shares the same understanding of valid transactions and blocks. This scenario illustrates how a change in consensus rules can lead to a hard fork, resulting in a permanent split in both the network and the blockchain.

In the event of a hard fork, as miners diverge to work on two different chains, the total hashing power of the network is split between these chains. The distribution of mining power can vary significantly, with some chains being favored more than others by miners.

For our example, let's consider a 90%–10% split in mining power following the fork, where 90% of miners adopt the new consensus rules and 10% continue with the original rules. We'll also assume this fork happens right after a difficulty retargeting.

Both chains inherit the same difficulty level that was set during the last retargeting. However, the impact of the split in mining power becomes immediately apparent:

Chain with New Rules (90% of Hashing Power): This chain retains the majority of the mining power. However, it still experiences a 10% drop in mining capacity. With this reduced power, the average time to mine a block increases from the standard 10 minutes to about 11.1 minutes. This slower block production will persist until the next 2016 blocks are mined, which will take around 22,377 minutes, or approximately 15.5 days. After this period, the difficulty will adjust downward to bring the block time back to the average 10-minute target, accounting for the 10% reduction in mining power.

Chain with Original Rules (10% of Hashing Power): The minority chain, now operating with just 10% of the original network's hashing power, faces a far more significant challenge. Block times on this chain will increase dramatically, averaging around 100 minutes per block. It will take much longer for this chain to reach the 2016-block threshold for a difficulty retargeting – approximately 201,600 minutes, or around 14 weeks. During this period, the transaction capacity of this chain will also decrease significantly due to fewer blocks being mined.

The immediate aftermath of a hard fork, characterized by a split in mining power, leads to imbalanced block production times on the diverging chains. The chain with more mining power adjusts more quickly to the change, while the chain with less power faces a prolonged period of slower block production and reduced transaction capacity. This imbalance remains until each chain reaches its next difficulty retargeting, which realigns block production times with the available hashing power.

Soft Forks

We've seen how hard forks can split the Bitcoin network and create separate chains with distinct consensus rules. But is there a way to update the network's rules that is less disruptive and doesn't necessarily lead to a permanent split in the blockchain? What about 'soft forks' – how do they differ from hard forks in terms of network consensus and adoption?"

A soft fork, unlike a hard fork, is a change to the Bitcoin protocol that is backward compatible. This means that while it introduces new rules to the network, nodes that do not upgrade to the new version of the software can still participate in validating and propagating blocks and transactions, albeit with some limitations.

Soft forks add new rules to the protocol without making previously valid blocks invalid. In essence, they introduce new rules that are a subset of the old rules. This means that blocks and transactions created under the new rules are still seen as valid by nodes that have not upgraded. However, the converse is not true: blocks created by non-upgraded nodes might not always be valid under the new rules.

Here’s an example: Suppose a soft fork proposes to reduce the maximum block size from 1 MB to 0.5 MB. Updated nodes will start creating blocks that are up to 0.5 MB in size, which are still valid for non-updated nodes because they fall within the previously acceptable 1 MB limit. However, if a non-updated node creates a block larger than 0.5 MB (but still within the old 1 MB limit), this block will be rejected by the updated nodes.

In a soft fork scenario, as long as a majority of the mining power updates to the new rules, the network tends to follow the updated chain, as these miners will reject blocks from non-updated nodes that violate the new rules. Gradually, even non-updated nodes start seeing the updated chain as the longest (or most work-intensive), and thus the most valid chain, leading to a convergence back to a single chain. This is unlike a hard fork, where non-updated nodes continue to see their chain as valid, leading to a permanent split.

The activation of a soft fork in the Bitcoin network relies on the principle of miner consensus, which is different from the requirement for all nodes to upgrade to a hard fork. Since soft forks are designed to be backward compatible, non-upgraded nodes can still participate in the network post-soft fork, albeit with some limitations. The key to activating a soft fork, therefore, lies in securing the agreement and readiness of a majority of miners to enforce the new consensus rules.

To achieve a consensus on a soft fork, miners use a signaling mechanism. This mechanism is a way for miners to communicate their readiness and support for the new consensus rules proposed in the soft fork.

Here’s how it works:

Proposal of New Rules: When a soft fork is proposed, it comes with new rules that miners need to enforce. These rules are embedded in a new version of the Bitcoin software.

Signaling Readiness: Miners show their support for the soft fork by upgrading to the new software version and then signaling their readiness to enforce the new rules. This signaling is typically done within the blocks they mine. For example, a miner might include a specific piece of data in the blocks they mine that indicates they are ready for the soft fork.

Reaching a Threshold: For the soft fork to be activated, a certain threshold of miner support must be reached. This is usually defined as a percentage of the total mining power. For instance, a common threshold is 95% miner support, meaning that 95% of the blocks mined during a certain period must signal support for the new rules.

Activation: Once the threshold is met, the new rules become active, and all miners start enforcing them. This is the point at which the soft fork is considered to have been activated.

Continued Participation of Non-Upgraded Nodes: Nodes that have not upgraded to the new software continue to operate under the old rules. However, as long as they don't contradict the new rules, their blocks and transactions remain valid. This is the backward compatibility feature of soft forks.

This mechanism of signaling and threshold ensures that soft forks are only activated when there is broad consensus among miners. It's a way to gauge the readiness of the network to adopt new rules without forcing every participant to upgrade immediately.

Wallets

Now that we've explored how accounts are generated, understood the workings of transactions, and learned about the construction of blocks that store these transactions, you might wonder: how do we actually connect to this network and submit our own transactions?

Enter the world of Bitcoin wallets. Think of wallets as user-friendly applications that bridge the gap between you and the Bitcoin network. They're not just programs; they're your personal finance managers in the Bitcoin ecosystem. A wallet manages your private keys, the critical component for securing and executing transactions. With your private key, the wallet can generate addresses to receive bitcoins, track the values in these addresses, manage your overall balance, and handle the creation, signing, and submission of new transactions to the network.

Here are two intriguing facts about Bitcoin wallets:

• Their main function is to store and manage your private keys.

• Contrary to what the name suggests, wallets don't actually store bitcoins (as we have already seen, the coins are stored on the blockchain in the form of transaction outputs);

This raises an interesting point about terminology. Is 'wallet' really the best name for this type of application? Given their functions, these tools resemble a 'keychain' more closely. They securely store your private keys, which, in turn, grant you access to your funds and enable you to transfer values to others.

So, whenever we mention a 'wallet' in the context of Bitcoin, feel free to visualize a 'keychain' if that makes more sense to you. It's all about securely holding the keys to your digital treasure.

While there are various types of wallets out there, we're going to zoom in on HD (hierarchical deterministic) wallets in this discussion.

Think of an HD Wallet as a one-stop-shop for all your key and address needs. It's like a magic box that creates every single key and address you'll ever need from just one source, which we'll dive into in a bit.

'Deterministic' in this context means that the wallet spits out keys and addresses in the same way every time you ask it to. No surprises there! And 'hierarchical'? That's just a fancy way of saying that these keys and addresses can be neatly organized into a tree-like structure.

The real kicker with an HD wallet is this: you get one seed to rule them all. From this single seed, you can conjure up a master private key. And from this master key? You can generate literally billions of 'child' private keys and public keys.

Remember how we talked about private and public keys before? Well, here’s how it all comes together in an HD wallet:

You start with your seed. This seed is used to create your master private key. Once you've got that, you're set to generate a seemingly endless stream of 'child' private keys and public keys. The cool part? All you need to back up is your seed. Because the master private key, derived from this seed, will always churn out your wallet's keys in the same, predictable manner (that's the deterministic part for you!).

In short, an HD wallet keeps things simple yet secure. One seed, one backup, and you're good to go with billions of keys at your fingertips.

So, let's dive into the world of the seed.

A seed in the Bitcoin universe is a whopping 512-bit number. That means you can pick any number that fits into those 512 bits. But how big is a 512-bit number, really? Let's break it down. You know how a 256-bit number is roughly in the same ballpark as the number of atoms in the universe, right? That's the kind of number we talked about when discussing SHA256.

Now, when we talk about 512 bits, it is a number that surpasses any order of magnitude ever observed in the universe!

So, choose any atom in the universe! Okay, this is now your seed!

And what are the chances of someone choosing the same atom?

None, right?

So here we have a problem: We humans!

We humans are not very good at dealing with randomness.

A study conducted by Schulz et al. in 2012 called "Analyzing Humanly Generated Random Number Sequences: A Pattern-Based Approach", focused on analyzing humanly generated random number sequences. The researchers aimed to understand how humans generate what they perceive to be random sequences and to identify the underlying patterns in these sequences.

In the experiment, participants were asked to produce sequences of random numbers, typically digits from 1 to 9. These human-generated sequences were then scrutinized using a pattern-based analysis, contrasting them with truly random sequences generated by a computer. The key methodology involved predicting the next item in a sequence based on its immediate history, using a model built on the Damerau-Levenshtein distance, a metric that calculates the number of edits needed to transform one string into another.

The results were revealing: when predicting the next number based on a history of seven items, the success rate for correctly guessing the next number rose significantly above chance levels. This high prediction rate indicated that the sequences were not truly random but followed certain identifiable patterns.

Furthermore, the study also attempted to distinguish sequences generated by different individuals. It was found that an algorithm could often correctly identify sequences generated by a particular person, suggesting person-specific patterns within the humanly generated sequences.

The conclusion drawn from this experiment was quite significant: while humans believe they can generate random sequences, their outputs often follow discernible patterns and are not truly random. This study sheds light on the cognitive processes involved in human attempts at randomness and demonstrates a clear distinction between human-generated and computer-generated randomness. It highlights the inherent biases and tendencies in human thought processes, even when randomness is the goal.

Alright, so what are your options for creating a seed? Well, you can go random. First up, we need to generate some entropy. Put simply, entropy is just a fancy word for randomness. There are a bunch of ways to do this, but one popular method is the good old coin flip.

Imagine flipping a coin 512 times. Each flip gives you a binary choice, right? Heads or tails, 0 or 1. So, after 512 flips, you've got a string of 512 bits – a mix of 0s and 1s. But hey, not everyone's up for flipping a coin that many times. That's why most wallets give you a break and let you generate a seed with just 128 or 256 bits. Less flipping, less work!

The easiest way to get this done? Grab a coin and flip it 128 times. Heads, you jot down a 0; tails, it's a 1. There you go – a random sequence of 128 bits, also known as your entropy. Want more security? Do it 256 times. Longer entropy equals a more secure wallet.

Another route? Let your wallet software generate the seed for you.

Now, back to our 128-bit sequence. There's an extra step here: adding a checksum. Think of the checksum like a fingerprint. It's tacked on to the end of your sequence to make sure you didn't goof up while copying it down. The wallet takes care of this, generating a 4-bit fingerprint of your entropy.

This fingerprint gets added to your 128 bits, giving you a 132-bit sequence.

Let's face it: trying to memorize or jot down a string of 132 bits, which are just 0s and 1s, is no walk in the park. That's why a much simpler method was developed: turning these bit sequences into a series of English words, also known as mnemonic code words.

This approach has become pretty standard in the world of Bitcoin wallets. It's all about making seeds easier to write, remember, transfer, and restore. With this method, most Bitcoin wallets today can export and import seeds for backup and recovery using these handy mnemonics.

What's really cool is that a user can take a mnemonic generated in one wallet and then import it into another. Just like that, you've got all your transactions, keys, and addresses back.

Now you might be wondering, how do we turn that humongous string of 0s and 1s into something as simple as words? Well, let's dive in!

We start by taking our 132-bit sequence and splitting it into 11-bit chunks. Since our sequence is 132 bits long, dividing by 11 gives us 12 chunks. If you're working with a 256-bit sequence, you'll end up with 24 chunks.

For example, let's say we have a sequence that breaks down into these chunks:

10101001101

00011010101

11000011101

01000100010

11011110000

00110010001

01001011100

01111110100

01001110111

10101000000

01001111100

10001110000

As you can notice, each chunk is a binary number. The lowest value of the chunk can be 00000000000 which is 0 in decimal. Whereas, the maximum value can be 11111111111 which is 2047 in decimal.

So, each chunk is valued between 0-2047. Mnemonic defined 2048 words, each word representing one number from 0 to 2047.

Word 0 is: abandon

Word 1 is: ability

Word 2047 is: zoo

You can see the full list of words here: https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt#L1

So, in our example, from the table, you can see that the decimal values of our chunks are: 1357, 213, 1565, 546, 1776, 401, 604, 1012, 631, 1344, 636, 1136.

Picking the words from the list,  we got the following mnemonic code: predict, boy, senior, dust, task, cram, entire, leader, exclude, pool, exhibit, mix

Now, the mnemonic words are used to generate the master private key. This master private key is the root from which a tree of private keys can be derived. Each branch of this tree corresponds to a specific private key.

These private keys, in turn, are used to generate their corresponding public keys. The public keys undergo a cryptographic transformation to produce wallet addresses. These addresses are what users share publicly to receive cryptocurrency transactions.

The beauty of an HD wallet lies in its ability to generate a multitude of private and public keys, and consequently, addresses, all stemming from the original mnemonic seed. This structure not only enhances security but also improves the organization and management of your bitcoins, as each branch can represent different accounts or purposes.

Alright, so we've got our HD wallet all set up with our mnemonic words and seed. Now, what can this tool actually do for us in the Bitcoin world? Let's break down some of its super handy functions:

Generating an Address to Receive Bitcoins: First things first, you want to get some bitcoins, right? Your wallet's got you covered. Once it's loaded with your seed, it does some digital gymnastics to generate a private key. From this private key, it figures out your public key. And voilà, it then whips up your very own Bitcoin address. This is like your unique digital mailbox where people can send you bitcoins. Just share this address, and watch your digital treasure grow.

Checking Your Account Balance: Want to keep an eye on your Bitcoin stash? Your wallet can either be a know-it-all that stores the entire Bitcoin blockchain (that’s a full node wallet) or a lightweight wallet that connects to another full node to get the scoop (that’s your more common lightweight wallet, perfect for everyday devices like cellphones). Either way, it's always on top of your balance, letting you know how much Bitcoin you've got at any given moment.

Submitting a Transfer: So you want to send some bitcoins to a friend or maybe pay for something? Your wallet checks how much Bitcoin you have, decides which inputs to send, and where to send them (outputs). Then it gets down to business, putting together the whole transaction structure. The wallet even signs off on this digital deal with your private key, a cryptographic signature. Once that's all done, it sends the transaction over to the neighbor nodes in the Bitcoin network, making sure your transaction gets around and is propagated through the network until it reaches some mining node.

Remember:

Bitcoin doesn’t have accounts like a traditional bank does.

Bitcoin doesn’t have a customer support hotline you can call when things go sideways.

There’s no big boss or central authority in charge of the Bitcoin world.

And most importantly, there’s no one out there distributing and keeping track of Bitcoin seeds for you.

So, what does all this mean for you? Well, it puts you in the driver's seat. You’re the one responsible for generating and keeping track of your own seeds. Think of it like being handed the keys to a super secure, high-tech vault. Those seeds are your keys, and there's no duplicate. If you lose them, well, there’s no locksmith in the Bitcoin world to help you out.

Your seed is the master key to all your Bitcoin transactions and balances. Lose it, and it’s like losing a treasure map where 'X' marks the spot of your digital gold. No one can recover it for you, and there’s no 'forgot my password' option. That might sound a bit daunting, but it's also empowering. It means you have complete control over your digital assets.

So, treat your seed with the same care as you would a wad of cash or your most precious possessions. Write it down, keep it safe, and maybe even have a backup in another secure location. In the world of Bitcoin, being your own bank means taking the security of your seeds seriously. They're your ticket to the decentralized finance world, so guard them like a treasure!

Improvement Proposals

Now that we have a grasp of how the Bitcoin Network operates, a natural question arises: given that Bitcoin is essentially software running on numerous machines globally, has this software ever been updated? And if a bug is discovered, how is it fixed in the code, considering there's no central authority overseeing the network? How does a decentralized system like Bitcoin handle updates and maintain its integrity?

Bitcoin, at its core, is a protocol, a set of rules that govern how the system operates. These rules are translated into computer code by developers. There are various versions of the Bitcoin protocol, known as implementations, and the most widely recognized one is Bitcoin Core.

Most of these implementations are open source, which means two things: firstly, anyone can view the entire code, and secondly, if you have programming skills, you're welcome to contribute improvements. Open source is all about collaborative, community-driven development.

However, altering the Bitcoin protocol itself isn't as simple as just making changes to the code. Since there's no central authority, any modifications require consensus from the broader Bitcoin community, which includes miners, full node operators, and users. Changes to the protocol are typically introduced through a process known as a 'fork'. In this decentralized system, anyone can propose a change, along with an implementation of how it would work.

This is where Bitcoin Improvement Proposals, or BIPs, come into play. A BIP is essentially a formal proposal to improve Bitcoin. It’s a document that details the proposed changes and the rationale behind them. Once a BIP is submitted, it's open for the community to review, discuss, and give feedback. If a BIP gains enough support, it can be considered for inclusion in the next protocol update.

So, while Bitcoin doesn't have a central authority calling the shots, it has a democratic and transparent process for making changes. This process ensures that updates to the Bitcoin protocol reflect the collective agreement and wisdom of its global community.

When a new Bitcoin Improvement Proposal (BIP) comes up, it's not just a small group of people who decide what happens next. The entire Bitcoin Network community, including miners, wallets, and nodes, gets a say in whether this proposal gets the green light. This is where the concept of a soft fork comes into play. Soft forks are like the network’s way of getting a makeover – they introduce new features and improvements without splitting the Bitcoin blockchain into two.

However, opinions on when and how to adopt these changes can vary. Traditionally, it's the miners who've had a big say in this through something called a Miner Activated Soft Fork, or MASF. In a MASF, miners use their hashing power to signal whether they're cool with a proposed change. They do this by tweaking the version bit numbers in the blocks they mine. Think of it like miners raising their hands in a digital world.

For instance, a BIP might require that 75% of blocks within the last 1,000 blocks must signal approval. Let's say 750 out of 1,000 blocks mined have a 'version 2' tag – that's like a collective 'thumbs up' from miners, activating the fork. This approach gives miners time to get their systems ready for the changes without rushing everyone to upgrade at once.

But wait, what if not everyone agrees with the miners? That's where a User Activated Soft Fork (UASF) comes into play. Imagine a scenario where it’s not just about what the miners think, but the whole Bitcoin economy – including you, me, wallet providers, and exchanges gets to call the shots. With a UASF, if the majority of the economy decides to go with a new update, they start ignoring any transactions and blocks that don't follow the new rules.

Miners could technically go against these new rules, but why would they? If a block they mine doesn't play by the new rules, the broader Bitcoin community might just shrug it off as invalid. So, miners have a vested interest in keeping in step with the rest of the network. In essence, a UASF can nudge miners to upgrade, as not doing so could mean their efforts (and the electricity, time, and money spent) go to waste.

So, regarding updating the Bitcoin Network, there's no set-in-stone rulebook. It's really up to the community (collective of users, developers, miners, nodes, exchanges) to brainstorm and propose new upgrades. What's cool is that everyone also gets to pitch in on deciding how we all reach a consensus on these changes. Sometimes it's a Miner Activated Soft Fork (MASF), other times it's a User Activated Soft Fork (UASF), or even a blend of both.

The Bitcoin Network is still relatively young, and each update is like a learning curve. It's an ongoing process of trial and error, figuring out what works best and fixing what didn’t quite hit the mark previously.

One thing’s for sure: the Bitcoin we know today has evolved quite a bit since Satoshi Nakamoto first set it in motion back in early 2009. Its protocol has seen a bunch of improvements over the years. And lucky, no single group or entity was able to promote any changes alone in the protocol.

To get an upgrade rolling, it has to go through the entire process of submitting a proposal, sparking discussions and debates, and making necessary improvements. It's a collaborative effort, with various parties offering their input. The final green light for any change depends heavily on the majority of the network's users agreeing that, yeah, this is the right move forward.