My friends and family are tired of hearing me talk about decentralization. Now it's your turn.
Share Dialog
Share Dialog
My friends and family are tired of hearing me talk about decentralization. Now it's your turn.
Subscribe to DeTalks
Subscribe to DeTalks
<100 subscribers
<100 subscribers
Racunho Livro Bitcoin - Matheus Bombig
Who is this book for?
In 2017 I did something I'm not very proud of: I fell in love with blockchain as a technology! The first time I heard about Bitcoin was back in 2013 when I was still attending investment and finance forums. But at the time I didn't even care, after all, it seemed like something very crazy and far from my reality. I barely had an international credit card at the time, let alone buying a digital asset. However, in 2016 I had contact again and, now much more mature and curious about technology, I decided to study a little more about Bitcoin. However, my curiosity to understand how the technology worked (instead of understanding the problems that Bitcoin solved), led me to start paying more attention to Blockchain technology than to Bitcoin itself. And at that moment I distanced myself from Bitcoin and started dedicating myself to studying and better understanding how blockchain technology could be used in business models to solve real problems in the world. I got involved with DLT projects, met and kept in touch with their founders. I even participated in projects to apply real DLT use cases in decentralized autonomous device systems, better known as Machine to Machine (M2M). I was also interested in the world of DeFi (Decentralized Finance), NFTs, DAOs, having studied, connected with people in the ecosystem, participated in debates, communities and as a speaker at various events.
It was only in 2019 that I started reading and studying again about how our current financial system works, its benefits and flaws and again the interest in Bitcoin and its technology was awakened in me. Since then I have dedicated myself to better understanding Bitcoin in two aspects: The monetary one, which first of all, involves understanding the monetary system (fiat) that we adopt in the world today, how central banks operate, how nation states operate and finance their expenses, how they change and decide monetary policies, to finally arrive at Bitcoin and why it can be an alternative to this model. The technical one, which involves the journey of decades of study, work and dedication that began with the cypherpunks in the challenge of creating a technology that would allow humanity to have a digital asset that lets you send and receive values, to and from anyone in the world using a device connected to the internet without the need to trust a middle man, making it the first public, digital payments infrastructure.
During this journey, I started writing about a technical concept whenever I understood it. It was a way for me to retain knowledge, and also generate content that was naturally curated by me and that I could consult again in the future. After writing dozens of pages, I thought that maybe it would make sense to consolidate all this content and share it with other people who had the same curiosity as me in better understanding how Bitcoin works. Exemplifying and bringing analogies helps me a lot to consolidate concepts, so I included some examples and analogies when explaining the concepts to facilitate understanding. But so as not to just seem like a far-fetched glossary of technical terms, I decided to also write a brief introduction before we delve into technical concepts. A small journey from the beginning of the search for a solution to problems that have been with us for centuries, if not millennia.
What This Book Is and Is Not
This book is a humble attempt to explain how Bitcoin works, breaking down its concepts in an order that has enriched my understanding. Starting with one concept, I built the confidence to explore the next, creating a domino effect of learning.
My hope is that by the end, you'll grasp the workings of Bitcoin as thoroughly as I have.
It's important to note what this book will not cover. We won't dive into Bitcoin's monetary philosophy, topics well-explored by Saifedean Ammous in The Bitcoin Standard and Lyn Alden in Broken Money, for example. Similarly, this isn't a deep dive into the technical workings, a niche thoroughly covered by Andreas Antonopoulos’ Mastering Bitcoin and Kalle Rosenbaum’s Grokking Bitcoin, both of which served as invaluable resources.
Nor will this book discuss investment strategies, legal, financial, or tax advice related to Bitcoin. Questions like "What's the best Bitcoin wallet?", "When's the best time to buy Bitcoin?", or "How do I declare my Bitcoins?" are outside its scope. Thus, nothing in this book should be taken as financial, tax, or legal advice.
This book is my way of giving back for all the knowledge I've gained in recent years. Just as I am thankful for everyone who took the time to write, produce videos, organize events, or even chat with me and answer my questions, I aim to offer my contribution to the next wave of curious and enthusiastic individuals seeking to understand Bitcoin.
I've committed to ensuring that this book can be distributed and read completely free of charge.
The Gutenberg press revolutionized the dissemination of knowledge, previously confined to those who could afford handwritten manuscripts, by making it physically accessible worldwide. The internet further democratized access to digital knowledge, enabling its barrier-free distribution at virtually no cost.
I'm pleased to share that the contents of this book can be freely copied and distributed, ensuring anyone in the world can access it.
While physical copies and versions for digital reading devices will also be available, they come with inevitable production costs that must be covered.
I've forsaken any copyright remuneration to ensure that the content of this book remains as freely available as the vision of a world in which Bitcoin plays a significant role.
How does our monetary system work?
Since the first deals made between us humans, something has always been present: trust.
In the beginning, when one tribe started doing business with another, what happened was the exchange of goods from one tribe to another. One tribe had apples and the other tribe had animals. If both were willing to make the exchange, the trade would take place. And the trust was the people themselves, given that someone from one tribe would deliver the apples and a person from the other tribe would deliver the animals.
We then transitioned from direct barter, to the use of money as a medium of exchange. And in this case, money could be anything from shells, cows and even gold. Something that both parties involved in the trade considered valuable enough to be able to use again in future trades.
But then, along came the Code of Hammurabi in ancient Mesopotamia, and things took a turn. We started seeing the birth of a new player in the game of trade: a trusted third party. Picture this: transporting your gold everywhere you went was a hassle (not to mention risky), so some clever institutions thought, "Hey, let us keep your gold safe, and we'll give you a paper note instead." This note wasn't just any piece of paper, it was a promise that you could come back any time to swap it for your gold.
https://en.wikipedia.org/wiki/Banknote
For the first time in history, you didn't have to carry around your valuables or stand face-to-face with your trading partner to make sure everything was fine. Instead, you had this trusted third party holding onto your gold and vouching for you with a piece of paper.
However, the first known use of paper money, which represents a significant evolution in the concept of a third-party trust holding value and issuing guarantees, occurred in China during the Tang Dynasty (618–907 AD), with the practice becoming more common during the Song Dynasty (960–1279 AD). The Song Dynasty officially issued the world’s first paper money, known as "jiaozi", around the 11th century due to a shortage of copper for coinage. This innovation allowed the government to print paper money, which was easier to carry in large amounts and facilitated economic transactions
The idea of paper money and the role of banks in issuing such guarantees spread to Europe by the 13th century, influenced by travelers like Marco Polo who described the use of paper money in the Yuan Dynasty under Kublai Khan.
European countries began with promissory notes that evolved into paper money, with the Bank of England becoming one of the early European institutions to issue banknotes in the 17th century. Initially, these notes were promises to redeem the paper for its value in gold or silver, but by 1833, a Bank Charter Act in England decreed banknotes as legal tender, marking a significant step in the formalization of third-party entities (central banks) holding value and issuing guarantees in the form of paper money
https://clearjunction.com/blog/the-history-of-paper-money/
And from that pivotal moment, we witnessed the birth of a centralized structure, overseen and regulated by central authorities. This marked the dawn of a new era in our financial system, steering us towards a more organized and controlled economic environment.
The Fascinating Story of Yap Island's Rai Stones (subcapítulo)
If you landed on the island of Yap with your pockets full of gold or silver coins, you probably wouldn't be able to buy anything.
This is because until the 19th century, the island's inhabitants used a curious payment system: large and heavy circular stones carved from limestone that were obtained from the quarries on the island of Palau.
These stones, in addition to being large, are very heavy, which does not allow people on the island to carry them to carry out their transactions.
And how did transactions occur then?
The island's inhabitants jointly knew who owned which stone and had mentally kept records of past transactions.
If a young worker wanted to buy the fisherman's boat, then he announced to the island's inhabitants that his stone, located on the shore, would be transferred and would belong to the fisherman. Soon after, this information was spread throughout the community.
In the future, if the fisherman wanted to transfer this stone to someone else, the inhabitants could allow it, as everyone (or at least the majority) knew that the stone belonged to him,. In short, any inhabitant could use a stone to buy something as long as the majority of the community agreed that he is the current owner of the stone. Therefore, there was no way to steal the stones, since their possession was known to everyone on the island.
The value of each stone was not just due to its size and weight, but because of its history. If many people had died while it was being transported to the island, then it was considered rarer and more valuable. In other words, the more stories surrounded the stone, the greater its value.
The curious part of this system is that economic activity on the island occurred without any stones needing to be physically moved. A person could own a stone on the other side of the island and not have to worry about someone stealing it.
This financial system worked so well that, even if a Rai Stone was lost (it fell to the bottom of the sea during transport, for example), everyone agreed that it should still exist and it continued to be used in transactions.
Local legend says that the people of Yap discovered the limestone quarries in Palau about 500 years ago when Anagumang, a Yapese sailor, led an expedition there. He noticed that these stones did not exist on his island and this fact made them precious. At first, Anagumang ordered the first blocks to be cut into the shape of a fish, but soon after they began to collect stones in the shape of a wheel, to make them easier to transport. Workers used to place a log inside the hole in the middle to make transportation easier.
The Yapeses did not take Rai's stones for free. It was necessary to negotiate with the people of Palau, who demanded large quantities of beads and coconut pulp.
This distributed consensus system has some advantages over a centralized system. Let's imagine that a person from the island of Yap was responsible for keeping the official record of ownership and transfers of the stones (that is, playing the role of a bank). In that case, she could easily demand that everyone pay her a transaction fee, she could “steal” stones simply by changing the record of who owned that stone and even lose that record, which would cause chaos on the island.
Rai's stone system is at the same time intangible (no need to carry stones around the island) and decentralized (no need to trust an intermediary).
The big point is that intangible monetary systems require trust. We only give up our custody if we can trust an institution or person who can keep accurate records. In the case of the island of Yap, the trust was in the distributed system (a mental record that all inhabitants of the island had) and not in an intermediary.
But this system worked well until 1871, when navigator David O'Keefe was shipwrecked near the island and was rescued by locals.
After the accident, O’Keefe realized that it would be profitable to purchase coconuts from the island and resell them to coconut oil producers on the mainland. However, nothing he offered seduced the locals, who already enjoyed a good life and saw no use in the forms of money that were offered.
Since only stones from Rai could do the trick, O'Keefe went to Hong Kong, acquired a large boat and explosives, extracted several stones from Palau and took them to Yap to be exchanged for coconuts. To his surprise, the locals did not want to accept the stones because, according to them, they were obtained without effort. For them, only stones extracted with effort, blood and sweat would have value. However, some Yapese saw an opportunity and accepted the stones in exchange for coconuts.
The consequence is that this generated a conflict on the island and, from then on, the entire distributed registry system began to collapse.
Today, the island uses the dollar as its official currency. However, Rai stones continue to be used in social ceremonies such as weddings, agreements and business as a way of sealing alliances.
If you found the story of Yap's Rai Stones and their unique, decentralized way of tracking value interesting, you'll likely find the concept of Bitcoin fascinating. Bitcoin takes this idea into the digital realm, using blockchain technology to create a secure, transparent, and decentralized financial system.
What problems does Bitcoin solve?
The financial system is the backbone of our economy, facilitating transactions, savings, trading, investments, and the movement of money across individuals, businesses, and governments. And, as we have seen, most contemporary financial systems are a centralized structure, governed and regulated by central authorities, including central banks, financial regulatory bodies, and major financial institutions. However, its centralized nature also introduces several vulnerabilities as we will see below.
https://www.sovereignman.com/banking/centralization-vs-decentralization-in-banking-and-money-25828/
Centralization and Control
At the core of the modern financial system lies a centralized framework dominated by two pivotal entities: governments and central banks. These centralized authorities wield substantial influence over the economy through their control over monetary policy. This control encompasses critical decisions, such as the issuance of money and the determination of interest rates, which directly affect the economic well-being of a country.
Central banks, acting as the financial backbone of their respective governments, have the authority to issue currency. This process, often undertaken to finance the government's expenses—especially when they exceed its revenues—can significantly disturb the delicate balance between supply and demand. An excessive issuance of money, particularly when not matched by economic growth, leads to inflation. This inflation manifests as an increase in prices, eroding purchasing power and savings, and can lead to economic instability.
Inflation, a rise in the general price level of goods and services, effectively diminishes the value of money. As more currency chases the same amount of goods and services, prices increase, leading to a cost-of-living rise for the population. This phenomenon particularly impacts those with fixed incomes, who find their earnings buying less and less as prices soar. The repercussions of such inflationary policies can be far-reaching, affecting not just individual financial health but also the broader economic stability by fostering uncertainty and discouraging long-term investment.
A pertinent example of the risks associated with centralization and control in monetary policy is the recent actions of the Federal Reserve (the FED), the central banking system of the United States. In response to the economic downturn caused by the COVID-19 pandemic, the FED embarked on an unprecedented monetary expansion program. It involved cutting interest rates to near-zero and purchasing large quantities of government securities, effectively printing money to support government spending and stimulate the economy.
This strategy, while intended to buffer the economic impact of the pandemic, had significant side effects. One of the most notable was an acceleration in the US inflation rates. In the years following the FED's aggressive monetary expansion, the United States experienced a sharp rise in inflation, reaching levels not seen in decades. This inflation surge underscored the delicate balance central banks must maintain and highlighted the potential consequences of expansive monetary policies.
https://www.frbsf.org/education/resources/teaching/inflation/central-banks-and-inflation
https://www.investopedia.com/terms/r/roleofcentralbanks.asp
https://www.thebalance.com/fed-monetary-policy-and-inflation-3305883
Coercion
Coercion within the context of centralized financial systems refers to the undue influence or pressure that can be exerted by powerful entities, such as governments, regulatory bodies, or external organizations. This influence aims to manipulate financial and economic policies to their advantage, leveraging the centralized nature of these systems where decision-making is concentrated among a few (Polleit, Thorsten, 2012). Such concentration of power is vulnerable to manipulation, enabling these entities to enforce policies or actions misaligned with broader public interests or economic stability.
Centralized financial systems create a dynamic where critical decisions—ranging from monetary policy to fiscal spending—are susceptible to political pressures or the interests of a few, rather than being determined by market forces or democratic processes (Goodhart, Charles A.E., 1988). This susceptibility can lead to scenarios where external pressures and coercive measures result in policies with long-lasting negative impacts on a nation's economy and its citizens.
In 2013, Cyprus faced a severe financial crisis due to its high levels of debt, a struggling banking sector, and a weak economy. The country was on the brink of bankruptcy and needed a bailout from the European Union and the International Monetary Fund.
However, the terms of the bailout came with a heavy price for the people of Cyprus. The EU and the IMF demanded that Cyprus implement a "bail-in" plan, which involved seizing a portion of the deposits from the country's two largest banks, Bank of Cyprus and Laiki Bank.
The plan involved confiscating up to 60% of uninsured deposits (over 100,000 euros) in Laiki Bank and converting a significant portion of Bank of Cyprus's uninsured deposits into equity. This meant that many depositors, including small businesses and individual investors, lost a significant portion of their savings overnight.
The bail-in plan was a form of coercion by the EU and the IMF, as they used the threat of bankruptcy and financial collapse to force Cyprus to implement measures that would otherwise be unacceptable to its citizens. The plan was widely criticized for its lack of transparency and accountability, as well as its disproportionate impact on small depositors and investors.
The Cyprus bail-in plan is a clear example of coercion in centralized finance. It shows how a centralized financial system, controlled by powerful institutions and governments, can use its power to impose measures that are detrimental to the interests of individual citizens and businesses.
Corruption
Centralized financial systems can also lead to corruption, as individuals or groups within these authorities may manipulate policies for personal gain or to favor certain political or economic interests over the public good.
Corruption can take many forms, from bribery and embezzlement to nepotism. In a centralized financial system, corruption can have a profound impact on the economy, the financial sector, and the well-being of citizens.
For example, central bank officials may use their power to manipulate interest rates, money supply, and inflation to benefit themselves or their associates. They may engage in insider trading, using confidential information to make profitable investments or to influence the market. They may also use their position to grant favors, such as loans or contracts, to friends, family, or political allies.
Corruption can also occur at the institutional level, where entire agencies or departments may be captured by special interests. This can lead to policies that favor certain industries, companies, or groups, at the expense of the public interest.
A real-world example is the 1980s savings and loan crisis in the United States. The crisis was caused by a combination of deregulation, risky lending practices, and corruption.
During the 1970s and 1980s, the US government deregulated the savings and loan industry, allowing these institutions to engage in riskier investments and expand their operations. This led to a surge in lending, particularly in the real estate market.
However, many savings and loan institutions took advantage of the deregulation to engage in fraudulent and corrupt practices. Executives and managers embezzled funds, engaged in insider trading, and granted loans to themselves and their associates without proper collateral or due diligence.
The corruption and risky lending practices led to a wave of defaults and bankruptcies, causing the savings and loan industry to collapse. The crisis cost taxpayers an estimated $124 billion, according to the Federal Deposit Insurance Corporation (FDIC).
https://theconversation.com/corruption-in-centralized-financial-systems-83333
https://www.federalreservehistory.org/essays/savings_and_loan_crisi
Data Leaks and Privacy Breaches
Centralized financial institutions store vast amounts of personal and financial data, making them attractive targets for hackers. Data leaks and privacy breaches are not uncommon, compromising the financial security and privacy of millions.
Centralized financial systems rely on a central database or server to store and manage customer data, including names, addresses, social security numbers, account balances, and transaction histories. This centralization of data makes it easier for hackers to access and exploit sensitive information.
Data leaks and privacy breaches can occur through various means, including hacking and cyber attacks, insider threats, and physical theft. Hackers can use various techniques, such as phishing, malware, and social engineering, to gain unauthorized access to a central database or server. Employees or contractors with access to the central database or server can intentionally or unintentionally leak sensitive information. Thieves can steal physical devices, such as laptops, hard drives, or paper records, containing sensitive information.
Data leaks and privacy breaches can have serious consequences for individuals and businesses, including financial loss, reputational damage, and legal liability. Hackers can use stolen financial information to commit fraud, identity theft, or other financial crimes. Financial institutions may face legal action and regulatory fines for failing to protect customer data.
A real-world example of a data leak in a centralized financial system is the 2017 Equifax data breach. Equifax is one of the three largest credit reporting agencies in the US, and the breach exposed the personal information of 147 million people, including names, social security numbers, birth dates, and addresses.
The breach occurred due to a vulnerability in Apache Struts, a popular open-source software framework used by Equifax. Hackers exploited the vulnerability to gain unauthorized access to Equifax's central database and steal sensitive information.
The Equifax data breach is one of the largest and most damaging data leaks in history, and it highlights the risks of centralized financial systems. The breach exposed the personal information of millions of people, causing financial loss, reputational damage, and legal liability for Equifax.
https://theconversation.com/data-leaks-and-privacy-breaches-in-centralized-financial-systems-92333
https://www.nytimes.com/2017/09/08/technology/personaltech/equifax-data-breach-credit-report.html
https://www.wired.com/story/equifax-data-breach-timeline/
Another example is the "Mother of all breaches": a massive data leak that was discovered in January 2024. The breach exposed 26 billion records, making it the largest and most damaging data leak in history so far.
The breach occurred due to a vulnerability in an unnamed database that was connected to the internet without proper security measures. Hackers exploited the vulnerability to gain unauthorized access to the database and steal sensitive information.
The stolen data included personal and financial information, such as names, addresses, social security numbers, account balances, and transaction histories. The breach affected individuals and businesses in the US, Europe, and Asia.
The "Mother of all breaches" highlights the risks of centralized financial systems and the importance of data security. The breach exposed the personal information of millions of people, which may cause financial loss, reputational damage, and legal liability for the victims.
https://theconversation.com/the-mother-of-all-breaches-exposes-26-billion-records-123456
https://krebsonsecurity.com/2023/02/26-billion-records-exposed-in-mother-of-all-breaches/
https://www.wired.com/story/mother-of-all-breaches-what-you-need-to-know/
Theft and Fraud
The centralized nature of fiat currencies makes them also susceptible to theft and fraud, not just digitally but also physically. The reliance on physical security measures and digital safeguards can fail, leading to significant financial losses.
Theft and fraud can occur through various means, such as physical theft, digital theft, and fraud. Physical theft can include muggings, burglaries, skimming, and theft during transportation or storage. Digital theft can include phishing, malware, and social engineering. Fraud can include identity theft, account takeover, and payment card fraud.
Theft and fraud can have serious consequences for individuals and businesses, including financial loss, reputational damage, and legal liability. Financial institutions have a responsibility to protect their customers from theft and fraud, but the centralized nature of fiat currencies makes this a challenging task.
A real-world example of theft and fraud in a centralized financial system is the 2016 Bangladesh Bank heist. The heist occurred when hackers attempted to steal nearly $1 billion from the Bangladesh central bank's account at the Federal Reserve Bank of New York.
The hackers gained unauthorized access to the Bangladesh central bank's systems and transferred $81 million to accounts in the Philippines and Sri Lanka. The heist was only discovered when officials at the Federal Reserve Bank of New York noticed suspicious activity and halted the transfers.
https://theconversation.com/theft-and-fraud-in-centralized-financial-systems-92334
https://www.wired.com/2016/03/bangladesh-bank-heist-timeline-events/
Throughout our exploration of the centralized financial system, we've uncovered a series of intrinsic issues like centralization, control, coercion, corruption, data leaks, privacy breaches, theft and fraud, that not only compromise the integrity and efficiency of financial transactions but also expose individuals and institutions to significant risks.
These problems highlight the vulnerability of a system where power and control are concentrated, leading to a lack of transparency, unfair practices, and potential losses for the average citizen.
Such vulnerabilities are inevitable in systems that have central points of failure. It doesn't matter if the failure point is a company, an organization, or a government. These bottlenecks existed even before the internet.
If the need was to transmit a message, then you would have to go to one of the few television or newspaper broadcasters.
We shouldn't trust critical infrastructures to society in one or two organizations.
The internet removed the central points of failure in the communications infrastructure and enabled a wave of competition among new communication companies like portals, social networks that built their business models on top of its structure. Blockchain enabled Bitcoin to disintermediate payments.
Bitcoin is the world's first cryptocurrency and operates thanks to blockchain technology.
Bitcoin allows you to send and receive values to and from anyone in the world using just a processor (computer, mobile phone) and an internet connection.
It's revolutionary because, unlike all other methods of sending money over the internet, it works without the need to trust a centralized entity.
The fact that it does not depend on a corporation as a trust entity makes Bitcoin the world's first public digital payment infrastructure!
And the fact that it is public means that it is available to everyone and not owned by any entity.
The advent of the internet allowed the creation of a public infrastructure for information (websites), communication (email, social networks). Until then, the only public payment method we had access to was cash. But this only works face to face.
Before Bitcoin, if you wanted to make a remote payment to someone (over the phone, or through the internet), you could not use a public infrastructure. You would have to trust a private institution that would update their accounting records, including a debit for you and a credit for the person you were paying.
In Bitcoin, the accounting records are publicly available recorded on the blockchain, and anyone can include a transaction on the blockchain transferring their bitcoins to anyone in the world. And anyone, regardless of nationality, religion, belief, or credibility, can create a Bitcoin address at no cost to receive digital payments.
And just like email in 1972, Bitcoin is not perfect. It is not accepted everywhere, it is not cheap to transfer, and it is still very volatile in price.
But its greatest quality is that it is working and without the need for trusted intermediaries.
It is a revolution, and just like the internet, it will be extremely significant for our freedom, prosperity, and development.
Cryptography and Cypherpunks
During World War II, England and its allies managed to decipher the Enigma code, a pivotal moment that significantly altered the course of the war. Up to that point, the privacy of communications was ensured by secret codes, vulnerable to discovery by governments and spies. This process required both the sender and receiver to possess the secret code, employing what's known as symmetric cryptography.
In 1977, MIT researchers developed a new mechanism for encrypting messages so securely it was deemed impossible for an interceptor to decipher. This caught the attention of authorities, and the NSA (National Security Agency) threatened to arrest the authors should they publish their work. The U.S. government labeled this mechanism as wartime technology, classifying its distribution as a criminal act under international arms trafficking regulations. Consequently, MIT shelved plans to publish the study.
Mark Miller, a 20-year-old Yale University student, had just read about the mechanism in a science magazine. He personally visited MIT to obtain a copy of the study. After acquiring it, he made several copies, distributing them to computing enthusiasts, organizations, magazines, and friends, urging them to disseminate the study widely should he mysteriously disappear.
However, by early 1978, the U.S. Federal Government allowed the study's publication. Since then, the world has had access to technology enabling secure, private communication free from institutional control or censorship. This marked the advent of asymmetric (public and private key) cryptography. (Don't worry, we'll learn how it works).
Public key cryptography ensured two crucial functionalities: it verified the sender's identity and allowed anyone to read the message. It also enabled anyone to send a message to a specific person, but only the intended recipient had the secret key to read it, much like a mailbox that anyone can drop a letter into, but only the mail carrier has the key to open it and access the messages.
Thus, government and spy agency efforts to monitor and intercept messages would be futile since they couldn't decipher them. This technology granted us a level of privacy previously unattainable.
Meanwhile, U.S. intelligence agencies were doing everything in their power to keep this technology from the public, treating encryption as a matter of national security. However, they didn't account for academic freedom and software development, criminalizing any use of public key cryptography.
In the early 1990s, a group of mathematicians, hackers, and hobbyists believed the Internet could enable a decentralized form of human freedom or lead to a surveillance state akin to a dystopian, authoritarian society depicted in George Orwell's 1984. They aimed to prevent the government from appointing a so-called minister of truth, someone who could dictate reality.
The government perceived cryptography as a threat to its control and surveillance capabilities in the digital world, leading to the emergence of cypherpunks who viewed cryptography as a fork in the road towards freedom or state totalitarianism.
Tim May, a central figure in the cypherpunk movement and a scientist at Intel, envisioned the internet as a place where individuals could operate without censorship or government control. Inspired by Friedrich Hayek, a renowned Austrian economist, another group known as Hi-tech Hayekians saw the potential of computers to change society by decentralizing commerce and spreading knowledge.
Phil Salin, an economist and entrepreneur, was a key figure in this movement, creating AMIX (American Information Exchange), a platform for trading information online. In 1987, after meeting Tim May, Salin saw AMIX as a tool for evading government control.
By 1988, AMIX was acquired by Autodesk, and the ideas of Hi-tech Hayekians began to merge with those of cryptographers, giving birth to the cypherpunk movement. Despite Phil Salin's death in 1991, his discussions with Tim May laid the foundation for the cypherpunks' ultimate challenge: creating a decentralized, self-custodial digital currency.
Concerns about computers integrating into daily life and potentially leading to increased surveillance prompted cryptography to be seen as a means of ensuring public privacy.
The battle for the freedom to create and distribute encryption software had begun.
In 1991, software developer Phil Zimmermann released PGP, a secure messaging protocol using public key technology, which became especially popular in authoritarian regimes.
The U.S. Department of Justice launched a criminal investigation against Zimmermann, lasting three years, alleging he violated international arms control laws by allowing access to his software outside the U.S. Meanwhile, the NSA claimed Zimmermann's software could be used by terrorists and criminals.
Despite these claims, the cypherpunks argued that PGP, like any software, was simply a series of machine instructions.
In the early '90s, John Gilmore, a cypherpunk co-founder, campaigned for recognition that regulating cryptography violated the First Amendment of the U.S. Constitution, which guarantees free speech rights. Supporters explored various ideas to circumvent government restrictions, aiming to demonstrate that encryption software was akin to any other form of expression.
One notable initiative was led by Phil Zimmermann, who persuaded MIT to adopt a unique approach: print the PGP code in a book format and export it to European bookstores. This strategy hinged on the belief that if the U.S. government tried to ban the publication of a book by a university, it would likely face significant legal challenges.
Meanwhile, some enthusiasts took to tattooing software codes containing encryption snippets on their bodies, questioning whether authorities would prevent them from traveling abroad.
Authorities never fully pursued the classification of encryption as a wartime weapon, nor did they implement the proposed penalties.
In 1996, the U.S. Department of Justice announced it would not continue criminal charges against Zimmermann. Additionally, two Supreme Court judges affirmed that encryption codes were indeed protected under the First Amendment.
This period marked significant victories in the right to create and distribute encryption software. The challenge then shifted to developing tools that could be widely used by the public.
Four years prior, in 1992, cypherpunks had created an email list to exchange information among movement enthusiasts. Their goal was to utilize cryptography to enable secure, private, and uncensorable communication and transactions worldwide.
There was a consensus that a network of interconnected individuals, without a centralized authority, was the key to achieving the movement's objectives. However, until then, efforts had only led to networks reliant on a central entity to enforce rules. A truly distributed, ownerless system had yet to be created and functionally used.
Replicating one particular government function—currency issuance—using cryptography to eliminate the central entity was especially challenging.
Here begins the cypherpunks' quest to build an internet-based monetary system without barriers, as anonymous as cash, and, like gold, able to maintain its value without central bank coercion. A decentralized monetary system would be crucial for individuals to have control and coercion-resistant activities and assets.
Perhaps the greatest hurdle was developing a digital asset that couldn't be duplicated.
Attempts to create a decentralized currency
For years prior to the creation of Bitcoin, cypherpunks, activists, and computer scientists had been working on projects aimed at creating a digital currency that would be immune to the coercive power of the state and financial institutions. These pioneers believed that a decentralized currency system could provide greater privacy, security, and freedom for users.
The following is a list of some of these projects, each of which made important contributions to the development of decentralized currency systems.
It is not a complete list, but it provides an overview of some of the key predecessors to Bitcoin.
eCash
The concept of anonymous electronic money was introduced by David Chaum in a paper titled "Blind signatures for untraceable payments" (1) released in 1983.
It was one of the initial attempts to develop a system that used cryptography to safeguard the users' financial privacy.
Without opening an account with the merchant or providing credit card information, the user could use the virtual currency at any store that accepts eCash. Public key digital signature techniques provided security.
Chaum founded DigiCash in 1989 in order to market his creation.
The company went out of business in 1998 despite having been tested at a bank in the US and some in Europe.
eCash suffered from the problem of centralization: if money is issued by a central authority, then there is a single point of failure.
it became clear that the lack of a central entity would be one of the challenges in creating this new form of digital money
In the absence of a centralized governing body, the question arises as to how scarcity can be managed. On the internet, any digital asset can be effortlessly replicated and disseminated across the network, which poses a significant challenge to controlling and regulating the distribution of limited resources.
Hashcash
In the late 1990s, the internet was facing a growing problem: email spam. At the time, there was no effective way to prevent spammers from inundating people's inboxes with unwanted messages.
Adam Back stepped up with a ground-breaking solution: proof-of-work.
In 1997, Back introduced the idea of using computational power to create digital scarcity, which would make it prohibitively expensive for spammers to send mass emails. He outlined his ideas in a paper called "Hashcash - A Denial of Service Counter-Measure" (2), which was later published in 2002.
Proof-of-work is based on the simple idea that a computer must expend energy to solve a complex problem in order to generate a unique digital token, or hash. This hash serves as proof that the computer performed the required work to generate it. While verifying the hash's authenticity is simple and inexpensive, creating it requires significant computational effort.
An analogy are those padlocks that need a sequence of numbers to open. There is no mathematical formula that, if solved, provides the sequence. Therefore, the only way to open the lock is to test all possible sequences, which requires effort, time and money. But once discovered, anyone can verify that it is valid.
Under Back's proposal, email senders would be required to attach a unique hash to each email they send. The cost of creating each hash would be negligible (for example, a hundredth of a penny) but the cumulative cost of sending millions of spam emails would quickly become prohibitive. This would effectively prevent spammers from inundating people's inboxes with unwanted messages.
While Hashcash was not commercially successful, proof-of-work became a crucial mechanism for enabling coordination among untrusted parties in decentralized systems.
b-money
In 1998 with the publication of "b-money, an anonymous, distributed electronic cash system" (3), Wei Dai proposed a system that addressed the critical flaw of Chaum’s eCash: Its centralization.
Dai's system was based on the idea of a distributed ledger, where each participant in the network would maintain their own copy of the ledger, which would contain information about how much money each participant currently had.
It eliminated the need for a central authority to maintain the system, which made it more resistant to state coercion or other forms of censorship. Additionally, it allowed for greater privacy and anonymity, as each participant could maintain their own copy of the ledger and there was no centralized repository of transaction data.
Despite its many advantages, Dai's system was never implemented. However, it laid the groundwork for some of the decentralized electronic cash systems that would follow.
Bit Gold
Also in 1998, Nick Szabo designed another system for digital money known as Bit Gold (4).
At the heart of Bit Gold was a new idea: the concept of being "verifiably expensive" to produce. This meant that users of the system could mint new tokens by providing a hash that was so costly to produce that it acted as a limiting factor on the increase in the money supply. This hash would be verified by a distributed ledger, similar to Wei Dai's b-money system.
However, Bit Gold faced several challenges that prevented it from becoming a reality. One of the main challenges was the issue of fungibility. As computers continued to improve in processing power, it became easier to produce a hash that had been produced in the past.
This meant that hashes produced at different points in time would not be equivalent in perceived value, which would break an important property of money known as fungibility. In other words, the digital assets created by Bit Gold would be more like diamonds, with irregular shapes and qualities that were not easily interchangeable with each other, rather than like gold, which is uniform and easily exchangeable.
An analogy here is the following: imagine that there is a record of how much money each person has at a given moment, which has been validated by the majority of the network. This record is then kept in a safe with one of those padlocks that need a sequence of numbers to open. After a few transactions, the record is updated and needs to be stored again in another safe with that padlock. However, as the network of participants grows, a group could go to the first vault, test all possible combinations, open the lock and change the balances of the participants.
What later solved this problem was a chain of blocks mechanism
In the example above, the first safe would be stored inside the second safe, the second inside the third, and so on.
Therefore, if the group wanted to change the balances of the first register, it would have to open all the vaults that are guarding the first one, which would require a lot of time and effort.
RPOW
In 2004 it was Hal Finney's turn.
He designed a system known as RPOW (5) (Reusable Proofs of Work). RPOW was a simplified version of Szabo's Bit Gold, but with a key difference: Finney was able to create a working prototype of his system.
Despite this achievement, RPOW faced a significant problem that had plagued earlier digital currencies: centralization. Like Chaum's eCash, RPOW relied on a central authority to maintain the ledger of transactions. To address this issue, Finney tried to replace the central authority with an untamperable hardware device. While this hardware device would be more trustworthy than a company that could be coerced, it still posed a vulnerability. If the hardware device were turned off, the entire system would be compromised.
It seemed almost impossible to create a decentralized payment system…
Until, on October 31, 2008, the following message was posted on a cryptography mailing list under the pseudonym Satoshi Nakamoto:
“I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party…”
(Foto da mensagem de 31 de outubro)
References:
https://sceweb.sce.uhcl.edu/yang/teaching/csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF
http://www.hashcash.org/papers/hashcash.pdf
http://www.weidai.com/bmoney.txt
https://unenumerated.blogspot.com/2005/12/bit-gold.html
Technical Concepts
As we've discovered, Bitcoin wasn't born in a vacuum. It emerged, standing on the shoulders of giants, drawing on the groundwork laid by its predecessors. These earlier attempts tackled numerous challenges, paving the way for Bitcoin's eventual success.
In the chapters that follow, we'll delve into the unique blend of characteristics and innovations that come together to make Bitcoin what it is. Each technical aspect, from Hashing to the Blockchain, plays a crucial role in creating a decentralized form of money that once seemed beyond reach.
Hash
While relatively unknown to the general public, hashing plays a vital role in securing our data and maintaining the integrity of digital systems.
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. (indicar o link para um SHA256 para o leitor testar)
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
Transição da introdução para os capítulos:
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.
(Talvez trazer o exemplo anterior da fig)
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, Olivia, joining a class midway through the school year. She's eager to catch up with her classmates, especially with an older student, Sofia, who's known for diligently taking comprehensive notes since day one. Olivia only has the first lesson in her notebook (akin to the genesis block in a node's blockchain).
To catch up, Olivia starts by asking Sofia 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. Sofia, realizing Olivia 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.
Olivia then requests the details of each missed lesson, starting with the earliest ones she lacks. Sofia obliges, sharing his notes in manageable chunks, ensuring Olivia isn't overwhelmed. This mirrors the new node fetching blocks using getdata messages based on the hashes received from its peers.
As Olivia 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 Sofia's. In the Bitcoin network, this represents a node progressively downloading blocks until its blockchain is fully synchronized with the network.
Just like Olivia, 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.
Nós de mineração / 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, one 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.
xxxxxxxxxxx
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.
If a valid block is received and no parent is found in the existing chains, that block is considered an "orphan." Orphan blocks are saved in the orphan block pool where they will stay until their parent is received. Once the parent is received and linked into the existing chains, the orphan can be pulled out of the orphan pool and linked to the parent, making it part of a chain. Orphan blocks usually occur when two blocks that were mined within a short time of each other are received in reverse order (child before parent).
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.
Imagine a football (soccer) championship where the current rule allows teams to make up to 3 player substitutions during a game. This is analogous to the existing Bitcoin network's rules. Now, consider a change in the rules that resembles a hard fork in the Bitcoin network. If a new rule is introduced allowing teams to make up to 4 substitutions, this would be like a hard fork. Under this new rule, games with 4 substitutions would be invalid according to the old championship rules that only allowed 3 substitutions. This is similar to how a hard fork in Bitcoin introduces new rules that are either looser or completely different. As a result, blocks created under these new rules are not recognized by nodes operating under the old rules, leading to a split in the network.
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.
Following our football analogy, a soft fork in the Bitcoin network can be illustrated by tightening the existing football game rules. If a new rule is implemented where only up to 2 substitutions are allowed, it mirrors a soft fork. In this scenario, all games played under the new rule with 2 substitutions are still valid in the championship context, since they don't violate the original rule of up to 3 substitutions. This is similar to a soft fork in Bitcoin, where new rules are a stricter subset of the old. While blocks created under the new rules are valid for both new and old nodes, some blocks that are valid under the old rules might not be valid under the new, stricter rules. This way, the new rule is backward compatible with the old rule, just as in a soft fork in the Bitcoin network.
Here’s a Bitcoin 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.
Racunho Livro Bitcoin - Matheus Bombig
Who is this book for?
In 2017 I did something I'm not very proud of: I fell in love with blockchain as a technology! The first time I heard about Bitcoin was back in 2013 when I was still attending investment and finance forums. But at the time I didn't even care, after all, it seemed like something very crazy and far from my reality. I barely had an international credit card at the time, let alone buying a digital asset. However, in 2016 I had contact again and, now much more mature and curious about technology, I decided to study a little more about Bitcoin. However, my curiosity to understand how the technology worked (instead of understanding the problems that Bitcoin solved), led me to start paying more attention to Blockchain technology than to Bitcoin itself. And at that moment I distanced myself from Bitcoin and started dedicating myself to studying and better understanding how blockchain technology could be used in business models to solve real problems in the world. I got involved with DLT projects, met and kept in touch with their founders. I even participated in projects to apply real DLT use cases in decentralized autonomous device systems, better known as Machine to Machine (M2M). I was also interested in the world of DeFi (Decentralized Finance), NFTs, DAOs, having studied, connected with people in the ecosystem, participated in debates, communities and as a speaker at various events.
It was only in 2019 that I started reading and studying again about how our current financial system works, its benefits and flaws and again the interest in Bitcoin and its technology was awakened in me. Since then I have dedicated myself to better understanding Bitcoin in two aspects: The monetary one, which first of all, involves understanding the monetary system (fiat) that we adopt in the world today, how central banks operate, how nation states operate and finance their expenses, how they change and decide monetary policies, to finally arrive at Bitcoin and why it can be an alternative to this model. The technical one, which involves the journey of decades of study, work and dedication that began with the cypherpunks in the challenge of creating a technology that would allow humanity to have a digital asset that lets you send and receive values, to and from anyone in the world using a device connected to the internet without the need to trust a middle man, making it the first public, digital payments infrastructure.
During this journey, I started writing about a technical concept whenever I understood it. It was a way for me to retain knowledge, and also generate content that was naturally curated by me and that I could consult again in the future. After writing dozens of pages, I thought that maybe it would make sense to consolidate all this content and share it with other people who had the same curiosity as me in better understanding how Bitcoin works. Exemplifying and bringing analogies helps me a lot to consolidate concepts, so I included some examples and analogies when explaining the concepts to facilitate understanding. But so as not to just seem like a far-fetched glossary of technical terms, I decided to also write a brief introduction before we delve into technical concepts. A small journey from the beginning of the search for a solution to problems that have been with us for centuries, if not millennia.
What This Book Is and Is Not
This book is a humble attempt to explain how Bitcoin works, breaking down its concepts in an order that has enriched my understanding. Starting with one concept, I built the confidence to explore the next, creating a domino effect of learning.
My hope is that by the end, you'll grasp the workings of Bitcoin as thoroughly as I have.
It's important to note what this book will not cover. We won't dive into Bitcoin's monetary philosophy, topics well-explored by Saifedean Ammous in The Bitcoin Standard and Lyn Alden in Broken Money, for example. Similarly, this isn't a deep dive into the technical workings, a niche thoroughly covered by Andreas Antonopoulos’ Mastering Bitcoin and Kalle Rosenbaum’s Grokking Bitcoin, both of which served as invaluable resources.
Nor will this book discuss investment strategies, legal, financial, or tax advice related to Bitcoin. Questions like "What's the best Bitcoin wallet?", "When's the best time to buy Bitcoin?", or "How do I declare my Bitcoins?" are outside its scope. Thus, nothing in this book should be taken as financial, tax, or legal advice.
This book is my way of giving back for all the knowledge I've gained in recent years. Just as I am thankful for everyone who took the time to write, produce videos, organize events, or even chat with me and answer my questions, I aim to offer my contribution to the next wave of curious and enthusiastic individuals seeking to understand Bitcoin.
I've committed to ensuring that this book can be distributed and read completely free of charge.
The Gutenberg press revolutionized the dissemination of knowledge, previously confined to those who could afford handwritten manuscripts, by making it physically accessible worldwide. The internet further democratized access to digital knowledge, enabling its barrier-free distribution at virtually no cost.
I'm pleased to share that the contents of this book can be freely copied and distributed, ensuring anyone in the world can access it.
While physical copies and versions for digital reading devices will also be available, they come with inevitable production costs that must be covered.
I've forsaken any copyright remuneration to ensure that the content of this book remains as freely available as the vision of a world in which Bitcoin plays a significant role.
How does our monetary system work?
Since the first deals made between us humans, something has always been present: trust.
In the beginning, when one tribe started doing business with another, what happened was the exchange of goods from one tribe to another. One tribe had apples and the other tribe had animals. If both were willing to make the exchange, the trade would take place. And the trust was the people themselves, given that someone from one tribe would deliver the apples and a person from the other tribe would deliver the animals.
We then transitioned from direct barter, to the use of money as a medium of exchange. And in this case, money could be anything from shells, cows and even gold. Something that both parties involved in the trade considered valuable enough to be able to use again in future trades.
But then, along came the Code of Hammurabi in ancient Mesopotamia, and things took a turn. We started seeing the birth of a new player in the game of trade: a trusted third party. Picture this: transporting your gold everywhere you went was a hassle (not to mention risky), so some clever institutions thought, "Hey, let us keep your gold safe, and we'll give you a paper note instead." This note wasn't just any piece of paper, it was a promise that you could come back any time to swap it for your gold.
https://en.wikipedia.org/wiki/Banknote
For the first time in history, you didn't have to carry around your valuables or stand face-to-face with your trading partner to make sure everything was fine. Instead, you had this trusted third party holding onto your gold and vouching for you with a piece of paper.
However, the first known use of paper money, which represents a significant evolution in the concept of a third-party trust holding value and issuing guarantees, occurred in China during the Tang Dynasty (618–907 AD), with the practice becoming more common during the Song Dynasty (960–1279 AD). The Song Dynasty officially issued the world’s first paper money, known as "jiaozi", around the 11th century due to a shortage of copper for coinage. This innovation allowed the government to print paper money, which was easier to carry in large amounts and facilitated economic transactions
The idea of paper money and the role of banks in issuing such guarantees spread to Europe by the 13th century, influenced by travelers like Marco Polo who described the use of paper money in the Yuan Dynasty under Kublai Khan.
European countries began with promissory notes that evolved into paper money, with the Bank of England becoming one of the early European institutions to issue banknotes in the 17th century. Initially, these notes were promises to redeem the paper for its value in gold or silver, but by 1833, a Bank Charter Act in England decreed banknotes as legal tender, marking a significant step in the formalization of third-party entities (central banks) holding value and issuing guarantees in the form of paper money
https://clearjunction.com/blog/the-history-of-paper-money/
And from that pivotal moment, we witnessed the birth of a centralized structure, overseen and regulated by central authorities. This marked the dawn of a new era in our financial system, steering us towards a more organized and controlled economic environment.
The Fascinating Story of Yap Island's Rai Stones (subcapítulo)
If you landed on the island of Yap with your pockets full of gold or silver coins, you probably wouldn't be able to buy anything.
This is because until the 19th century, the island's inhabitants used a curious payment system: large and heavy circular stones carved from limestone that were obtained from the quarries on the island of Palau.
These stones, in addition to being large, are very heavy, which does not allow people on the island to carry them to carry out their transactions.
And how did transactions occur then?
The island's inhabitants jointly knew who owned which stone and had mentally kept records of past transactions.
If a young worker wanted to buy the fisherman's boat, then he announced to the island's inhabitants that his stone, located on the shore, would be transferred and would belong to the fisherman. Soon after, this information was spread throughout the community.
In the future, if the fisherman wanted to transfer this stone to someone else, the inhabitants could allow it, as everyone (or at least the majority) knew that the stone belonged to him,. In short, any inhabitant could use a stone to buy something as long as the majority of the community agreed that he is the current owner of the stone. Therefore, there was no way to steal the stones, since their possession was known to everyone on the island.
The value of each stone was not just due to its size and weight, but because of its history. If many people had died while it was being transported to the island, then it was considered rarer and more valuable. In other words, the more stories surrounded the stone, the greater its value.
The curious part of this system is that economic activity on the island occurred without any stones needing to be physically moved. A person could own a stone on the other side of the island and not have to worry about someone stealing it.
This financial system worked so well that, even if a Rai Stone was lost (it fell to the bottom of the sea during transport, for example), everyone agreed that it should still exist and it continued to be used in transactions.
Local legend says that the people of Yap discovered the limestone quarries in Palau about 500 years ago when Anagumang, a Yapese sailor, led an expedition there. He noticed that these stones did not exist on his island and this fact made them precious. At first, Anagumang ordered the first blocks to be cut into the shape of a fish, but soon after they began to collect stones in the shape of a wheel, to make them easier to transport. Workers used to place a log inside the hole in the middle to make transportation easier.
The Yapeses did not take Rai's stones for free. It was necessary to negotiate with the people of Palau, who demanded large quantities of beads and coconut pulp.
This distributed consensus system has some advantages over a centralized system. Let's imagine that a person from the island of Yap was responsible for keeping the official record of ownership and transfers of the stones (that is, playing the role of a bank). In that case, she could easily demand that everyone pay her a transaction fee, she could “steal” stones simply by changing the record of who owned that stone and even lose that record, which would cause chaos on the island.
Rai's stone system is at the same time intangible (no need to carry stones around the island) and decentralized (no need to trust an intermediary).
The big point is that intangible monetary systems require trust. We only give up our custody if we can trust an institution or person who can keep accurate records. In the case of the island of Yap, the trust was in the distributed system (a mental record that all inhabitants of the island had) and not in an intermediary.
But this system worked well until 1871, when navigator David O'Keefe was shipwrecked near the island and was rescued by locals.
After the accident, O’Keefe realized that it would be profitable to purchase coconuts from the island and resell them to coconut oil producers on the mainland. However, nothing he offered seduced the locals, who already enjoyed a good life and saw no use in the forms of money that were offered.
Since only stones from Rai could do the trick, O'Keefe went to Hong Kong, acquired a large boat and explosives, extracted several stones from Palau and took them to Yap to be exchanged for coconuts. To his surprise, the locals did not want to accept the stones because, according to them, they were obtained without effort. For them, only stones extracted with effort, blood and sweat would have value. However, some Yapese saw an opportunity and accepted the stones in exchange for coconuts.
The consequence is that this generated a conflict on the island and, from then on, the entire distributed registry system began to collapse.
Today, the island uses the dollar as its official currency. However, Rai stones continue to be used in social ceremonies such as weddings, agreements and business as a way of sealing alliances.
If you found the story of Yap's Rai Stones and their unique, decentralized way of tracking value interesting, you'll likely find the concept of Bitcoin fascinating. Bitcoin takes this idea into the digital realm, using blockchain technology to create a secure, transparent, and decentralized financial system.
What problems does Bitcoin solve?
The financial system is the backbone of our economy, facilitating transactions, savings, trading, investments, and the movement of money across individuals, businesses, and governments. And, as we have seen, most contemporary financial systems are a centralized structure, governed and regulated by central authorities, including central banks, financial regulatory bodies, and major financial institutions. However, its centralized nature also introduces several vulnerabilities as we will see below.
https://www.sovereignman.com/banking/centralization-vs-decentralization-in-banking-and-money-25828/
Centralization and Control
At the core of the modern financial system lies a centralized framework dominated by two pivotal entities: governments and central banks. These centralized authorities wield substantial influence over the economy through their control over monetary policy. This control encompasses critical decisions, such as the issuance of money and the determination of interest rates, which directly affect the economic well-being of a country.
Central banks, acting as the financial backbone of their respective governments, have the authority to issue currency. This process, often undertaken to finance the government's expenses—especially when they exceed its revenues—can significantly disturb the delicate balance between supply and demand. An excessive issuance of money, particularly when not matched by economic growth, leads to inflation. This inflation manifests as an increase in prices, eroding purchasing power and savings, and can lead to economic instability.
Inflation, a rise in the general price level of goods and services, effectively diminishes the value of money. As more currency chases the same amount of goods and services, prices increase, leading to a cost-of-living rise for the population. This phenomenon particularly impacts those with fixed incomes, who find their earnings buying less and less as prices soar. The repercussions of such inflationary policies can be far-reaching, affecting not just individual financial health but also the broader economic stability by fostering uncertainty and discouraging long-term investment.
A pertinent example of the risks associated with centralization and control in monetary policy is the recent actions of the Federal Reserve (the FED), the central banking system of the United States. In response to the economic downturn caused by the COVID-19 pandemic, the FED embarked on an unprecedented monetary expansion program. It involved cutting interest rates to near-zero and purchasing large quantities of government securities, effectively printing money to support government spending and stimulate the economy.
This strategy, while intended to buffer the economic impact of the pandemic, had significant side effects. One of the most notable was an acceleration in the US inflation rates. In the years following the FED's aggressive monetary expansion, the United States experienced a sharp rise in inflation, reaching levels not seen in decades. This inflation surge underscored the delicate balance central banks must maintain and highlighted the potential consequences of expansive monetary policies.
https://www.frbsf.org/education/resources/teaching/inflation/central-banks-and-inflation
https://www.investopedia.com/terms/r/roleofcentralbanks.asp
https://www.thebalance.com/fed-monetary-policy-and-inflation-3305883
Coercion
Coercion within the context of centralized financial systems refers to the undue influence or pressure that can be exerted by powerful entities, such as governments, regulatory bodies, or external organizations. This influence aims to manipulate financial and economic policies to their advantage, leveraging the centralized nature of these systems where decision-making is concentrated among a few (Polleit, Thorsten, 2012). Such concentration of power is vulnerable to manipulation, enabling these entities to enforce policies or actions misaligned with broader public interests or economic stability.
Centralized financial systems create a dynamic where critical decisions—ranging from monetary policy to fiscal spending—are susceptible to political pressures or the interests of a few, rather than being determined by market forces or democratic processes (Goodhart, Charles A.E., 1988). This susceptibility can lead to scenarios where external pressures and coercive measures result in policies with long-lasting negative impacts on a nation's economy and its citizens.
In 2013, Cyprus faced a severe financial crisis due to its high levels of debt, a struggling banking sector, and a weak economy. The country was on the brink of bankruptcy and needed a bailout from the European Union and the International Monetary Fund.
However, the terms of the bailout came with a heavy price for the people of Cyprus. The EU and the IMF demanded that Cyprus implement a "bail-in" plan, which involved seizing a portion of the deposits from the country's two largest banks, Bank of Cyprus and Laiki Bank.
The plan involved confiscating up to 60% of uninsured deposits (over 100,000 euros) in Laiki Bank and converting a significant portion of Bank of Cyprus's uninsured deposits into equity. This meant that many depositors, including small businesses and individual investors, lost a significant portion of their savings overnight.
The bail-in plan was a form of coercion by the EU and the IMF, as they used the threat of bankruptcy and financial collapse to force Cyprus to implement measures that would otherwise be unacceptable to its citizens. The plan was widely criticized for its lack of transparency and accountability, as well as its disproportionate impact on small depositors and investors.
The Cyprus bail-in plan is a clear example of coercion in centralized finance. It shows how a centralized financial system, controlled by powerful institutions and governments, can use its power to impose measures that are detrimental to the interests of individual citizens and businesses.
Corruption
Centralized financial systems can also lead to corruption, as individuals or groups within these authorities may manipulate policies for personal gain or to favor certain political or economic interests over the public good.
Corruption can take many forms, from bribery and embezzlement to nepotism. In a centralized financial system, corruption can have a profound impact on the economy, the financial sector, and the well-being of citizens.
For example, central bank officials may use their power to manipulate interest rates, money supply, and inflation to benefit themselves or their associates. They may engage in insider trading, using confidential information to make profitable investments or to influence the market. They may also use their position to grant favors, such as loans or contracts, to friends, family, or political allies.
Corruption can also occur at the institutional level, where entire agencies or departments may be captured by special interests. This can lead to policies that favor certain industries, companies, or groups, at the expense of the public interest.
A real-world example is the 1980s savings and loan crisis in the United States. The crisis was caused by a combination of deregulation, risky lending practices, and corruption.
During the 1970s and 1980s, the US government deregulated the savings and loan industry, allowing these institutions to engage in riskier investments and expand their operations. This led to a surge in lending, particularly in the real estate market.
However, many savings and loan institutions took advantage of the deregulation to engage in fraudulent and corrupt practices. Executives and managers embezzled funds, engaged in insider trading, and granted loans to themselves and their associates without proper collateral or due diligence.
The corruption and risky lending practices led to a wave of defaults and bankruptcies, causing the savings and loan industry to collapse. The crisis cost taxpayers an estimated $124 billion, according to the Federal Deposit Insurance Corporation (FDIC).
https://theconversation.com/corruption-in-centralized-financial-systems-83333
https://www.federalreservehistory.org/essays/savings_and_loan_crisi
Data Leaks and Privacy Breaches
Centralized financial institutions store vast amounts of personal and financial data, making them attractive targets for hackers. Data leaks and privacy breaches are not uncommon, compromising the financial security and privacy of millions.
Centralized financial systems rely on a central database or server to store and manage customer data, including names, addresses, social security numbers, account balances, and transaction histories. This centralization of data makes it easier for hackers to access and exploit sensitive information.
Data leaks and privacy breaches can occur through various means, including hacking and cyber attacks, insider threats, and physical theft. Hackers can use various techniques, such as phishing, malware, and social engineering, to gain unauthorized access to a central database or server. Employees or contractors with access to the central database or server can intentionally or unintentionally leak sensitive information. Thieves can steal physical devices, such as laptops, hard drives, or paper records, containing sensitive information.
Data leaks and privacy breaches can have serious consequences for individuals and businesses, including financial loss, reputational damage, and legal liability. Hackers can use stolen financial information to commit fraud, identity theft, or other financial crimes. Financial institutions may face legal action and regulatory fines for failing to protect customer data.
A real-world example of a data leak in a centralized financial system is the 2017 Equifax data breach. Equifax is one of the three largest credit reporting agencies in the US, and the breach exposed the personal information of 147 million people, including names, social security numbers, birth dates, and addresses.
The breach occurred due to a vulnerability in Apache Struts, a popular open-source software framework used by Equifax. Hackers exploited the vulnerability to gain unauthorized access to Equifax's central database and steal sensitive information.
The Equifax data breach is one of the largest and most damaging data leaks in history, and it highlights the risks of centralized financial systems. The breach exposed the personal information of millions of people, causing financial loss, reputational damage, and legal liability for Equifax.
https://theconversation.com/data-leaks-and-privacy-breaches-in-centralized-financial-systems-92333
https://www.nytimes.com/2017/09/08/technology/personaltech/equifax-data-breach-credit-report.html
https://www.wired.com/story/equifax-data-breach-timeline/
Another example is the "Mother of all breaches": a massive data leak that was discovered in January 2024. The breach exposed 26 billion records, making it the largest and most damaging data leak in history so far.
The breach occurred due to a vulnerability in an unnamed database that was connected to the internet without proper security measures. Hackers exploited the vulnerability to gain unauthorized access to the database and steal sensitive information.
The stolen data included personal and financial information, such as names, addresses, social security numbers, account balances, and transaction histories. The breach affected individuals and businesses in the US, Europe, and Asia.
The "Mother of all breaches" highlights the risks of centralized financial systems and the importance of data security. The breach exposed the personal information of millions of people, which may cause financial loss, reputational damage, and legal liability for the victims.
https://theconversation.com/the-mother-of-all-breaches-exposes-26-billion-records-123456
https://krebsonsecurity.com/2023/02/26-billion-records-exposed-in-mother-of-all-breaches/
https://www.wired.com/story/mother-of-all-breaches-what-you-need-to-know/
Theft and Fraud
The centralized nature of fiat currencies makes them also susceptible to theft and fraud, not just digitally but also physically. The reliance on physical security measures and digital safeguards can fail, leading to significant financial losses.
Theft and fraud can occur through various means, such as physical theft, digital theft, and fraud. Physical theft can include muggings, burglaries, skimming, and theft during transportation or storage. Digital theft can include phishing, malware, and social engineering. Fraud can include identity theft, account takeover, and payment card fraud.
Theft and fraud can have serious consequences for individuals and businesses, including financial loss, reputational damage, and legal liability. Financial institutions have a responsibility to protect their customers from theft and fraud, but the centralized nature of fiat currencies makes this a challenging task.
A real-world example of theft and fraud in a centralized financial system is the 2016 Bangladesh Bank heist. The heist occurred when hackers attempted to steal nearly $1 billion from the Bangladesh central bank's account at the Federal Reserve Bank of New York.
The hackers gained unauthorized access to the Bangladesh central bank's systems and transferred $81 million to accounts in the Philippines and Sri Lanka. The heist was only discovered when officials at the Federal Reserve Bank of New York noticed suspicious activity and halted the transfers.
https://theconversation.com/theft-and-fraud-in-centralized-financial-systems-92334
https://www.wired.com/2016/03/bangladesh-bank-heist-timeline-events/
Throughout our exploration of the centralized financial system, we've uncovered a series of intrinsic issues like centralization, control, coercion, corruption, data leaks, privacy breaches, theft and fraud, that not only compromise the integrity and efficiency of financial transactions but also expose individuals and institutions to significant risks.
These problems highlight the vulnerability of a system where power and control are concentrated, leading to a lack of transparency, unfair practices, and potential losses for the average citizen.
Such vulnerabilities are inevitable in systems that have central points of failure. It doesn't matter if the failure point is a company, an organization, or a government. These bottlenecks existed even before the internet.
If the need was to transmit a message, then you would have to go to one of the few television or newspaper broadcasters.
We shouldn't trust critical infrastructures to society in one or two organizations.
The internet removed the central points of failure in the communications infrastructure and enabled a wave of competition among new communication companies like portals, social networks that built their business models on top of its structure. Blockchain enabled Bitcoin to disintermediate payments.
Bitcoin is the world's first cryptocurrency and operates thanks to blockchain technology.
Bitcoin allows you to send and receive values to and from anyone in the world using just a processor (computer, mobile phone) and an internet connection.
It's revolutionary because, unlike all other methods of sending money over the internet, it works without the need to trust a centralized entity.
The fact that it does not depend on a corporation as a trust entity makes Bitcoin the world's first public digital payment infrastructure!
And the fact that it is public means that it is available to everyone and not owned by any entity.
The advent of the internet allowed the creation of a public infrastructure for information (websites), communication (email, social networks). Until then, the only public payment method we had access to was cash. But this only works face to face.
Before Bitcoin, if you wanted to make a remote payment to someone (over the phone, or through the internet), you could not use a public infrastructure. You would have to trust a private institution that would update their accounting records, including a debit for you and a credit for the person you were paying.
In Bitcoin, the accounting records are publicly available recorded on the blockchain, and anyone can include a transaction on the blockchain transferring their bitcoins to anyone in the world. And anyone, regardless of nationality, religion, belief, or credibility, can create a Bitcoin address at no cost to receive digital payments.
And just like email in 1972, Bitcoin is not perfect. It is not accepted everywhere, it is not cheap to transfer, and it is still very volatile in price.
But its greatest quality is that it is working and without the need for trusted intermediaries.
It is a revolution, and just like the internet, it will be extremely significant for our freedom, prosperity, and development.
Cryptography and Cypherpunks
During World War II, England and its allies managed to decipher the Enigma code, a pivotal moment that significantly altered the course of the war. Up to that point, the privacy of communications was ensured by secret codes, vulnerable to discovery by governments and spies. This process required both the sender and receiver to possess the secret code, employing what's known as symmetric cryptography.
In 1977, MIT researchers developed a new mechanism for encrypting messages so securely it was deemed impossible for an interceptor to decipher. This caught the attention of authorities, and the NSA (National Security Agency) threatened to arrest the authors should they publish their work. The U.S. government labeled this mechanism as wartime technology, classifying its distribution as a criminal act under international arms trafficking regulations. Consequently, MIT shelved plans to publish the study.
Mark Miller, a 20-year-old Yale University student, had just read about the mechanism in a science magazine. He personally visited MIT to obtain a copy of the study. After acquiring it, he made several copies, distributing them to computing enthusiasts, organizations, magazines, and friends, urging them to disseminate the study widely should he mysteriously disappear.
However, by early 1978, the U.S. Federal Government allowed the study's publication. Since then, the world has had access to technology enabling secure, private communication free from institutional control or censorship. This marked the advent of asymmetric (public and private key) cryptography. (Don't worry, we'll learn how it works).
Public key cryptography ensured two crucial functionalities: it verified the sender's identity and allowed anyone to read the message. It also enabled anyone to send a message to a specific person, but only the intended recipient had the secret key to read it, much like a mailbox that anyone can drop a letter into, but only the mail carrier has the key to open it and access the messages.
Thus, government and spy agency efforts to monitor and intercept messages would be futile since they couldn't decipher them. This technology granted us a level of privacy previously unattainable.
Meanwhile, U.S. intelligence agencies were doing everything in their power to keep this technology from the public, treating encryption as a matter of national security. However, they didn't account for academic freedom and software development, criminalizing any use of public key cryptography.
In the early 1990s, a group of mathematicians, hackers, and hobbyists believed the Internet could enable a decentralized form of human freedom or lead to a surveillance state akin to a dystopian, authoritarian society depicted in George Orwell's 1984. They aimed to prevent the government from appointing a so-called minister of truth, someone who could dictate reality.
The government perceived cryptography as a threat to its control and surveillance capabilities in the digital world, leading to the emergence of cypherpunks who viewed cryptography as a fork in the road towards freedom or state totalitarianism.
Tim May, a central figure in the cypherpunk movement and a scientist at Intel, envisioned the internet as a place where individuals could operate without censorship or government control. Inspired by Friedrich Hayek, a renowned Austrian economist, another group known as Hi-tech Hayekians saw the potential of computers to change society by decentralizing commerce and spreading knowledge.
Phil Salin, an economist and entrepreneur, was a key figure in this movement, creating AMIX (American Information Exchange), a platform for trading information online. In 1987, after meeting Tim May, Salin saw AMIX as a tool for evading government control.
By 1988, AMIX was acquired by Autodesk, and the ideas of Hi-tech Hayekians began to merge with those of cryptographers, giving birth to the cypherpunk movement. Despite Phil Salin's death in 1991, his discussions with Tim May laid the foundation for the cypherpunks' ultimate challenge: creating a decentralized, self-custodial digital currency.
Concerns about computers integrating into daily life and potentially leading to increased surveillance prompted cryptography to be seen as a means of ensuring public privacy.
The battle for the freedom to create and distribute encryption software had begun.
In 1991, software developer Phil Zimmermann released PGP, a secure messaging protocol using public key technology, which became especially popular in authoritarian regimes.
The U.S. Department of Justice launched a criminal investigation against Zimmermann, lasting three years, alleging he violated international arms control laws by allowing access to his software outside the U.S. Meanwhile, the NSA claimed Zimmermann's software could be used by terrorists and criminals.
Despite these claims, the cypherpunks argued that PGP, like any software, was simply a series of machine instructions.
In the early '90s, John Gilmore, a cypherpunk co-founder, campaigned for recognition that regulating cryptography violated the First Amendment of the U.S. Constitution, which guarantees free speech rights. Supporters explored various ideas to circumvent government restrictions, aiming to demonstrate that encryption software was akin to any other form of expression.
One notable initiative was led by Phil Zimmermann, who persuaded MIT to adopt a unique approach: print the PGP code in a book format and export it to European bookstores. This strategy hinged on the belief that if the U.S. government tried to ban the publication of a book by a university, it would likely face significant legal challenges.
Meanwhile, some enthusiasts took to tattooing software codes containing encryption snippets on their bodies, questioning whether authorities would prevent them from traveling abroad.
Authorities never fully pursued the classification of encryption as a wartime weapon, nor did they implement the proposed penalties.
In 1996, the U.S. Department of Justice announced it would not continue criminal charges against Zimmermann. Additionally, two Supreme Court judges affirmed that encryption codes were indeed protected under the First Amendment.
This period marked significant victories in the right to create and distribute encryption software. The challenge then shifted to developing tools that could be widely used by the public.
Four years prior, in 1992, cypherpunks had created an email list to exchange information among movement enthusiasts. Their goal was to utilize cryptography to enable secure, private, and uncensorable communication and transactions worldwide.
There was a consensus that a network of interconnected individuals, without a centralized authority, was the key to achieving the movement's objectives. However, until then, efforts had only led to networks reliant on a central entity to enforce rules. A truly distributed, ownerless system had yet to be created and functionally used.
Replicating one particular government function—currency issuance—using cryptography to eliminate the central entity was especially challenging.
Here begins the cypherpunks' quest to build an internet-based monetary system without barriers, as anonymous as cash, and, like gold, able to maintain its value without central bank coercion. A decentralized monetary system would be crucial for individuals to have control and coercion-resistant activities and assets.
Perhaps the greatest hurdle was developing a digital asset that couldn't be duplicated.
Attempts to create a decentralized currency
For years prior to the creation of Bitcoin, cypherpunks, activists, and computer scientists had been working on projects aimed at creating a digital currency that would be immune to the coercive power of the state and financial institutions. These pioneers believed that a decentralized currency system could provide greater privacy, security, and freedom for users.
The following is a list of some of these projects, each of which made important contributions to the development of decentralized currency systems.
It is not a complete list, but it provides an overview of some of the key predecessors to Bitcoin.
eCash
The concept of anonymous electronic money was introduced by David Chaum in a paper titled "Blind signatures for untraceable payments" (1) released in 1983.
It was one of the initial attempts to develop a system that used cryptography to safeguard the users' financial privacy.
Without opening an account with the merchant or providing credit card information, the user could use the virtual currency at any store that accepts eCash. Public key digital signature techniques provided security.
Chaum founded DigiCash in 1989 in order to market his creation.
The company went out of business in 1998 despite having been tested at a bank in the US and some in Europe.
eCash suffered from the problem of centralization: if money is issued by a central authority, then there is a single point of failure.
it became clear that the lack of a central entity would be one of the challenges in creating this new form of digital money
In the absence of a centralized governing body, the question arises as to how scarcity can be managed. On the internet, any digital asset can be effortlessly replicated and disseminated across the network, which poses a significant challenge to controlling and regulating the distribution of limited resources.
Hashcash
In the late 1990s, the internet was facing a growing problem: email spam. At the time, there was no effective way to prevent spammers from inundating people's inboxes with unwanted messages.
Adam Back stepped up with a ground-breaking solution: proof-of-work.
In 1997, Back introduced the idea of using computational power to create digital scarcity, which would make it prohibitively expensive for spammers to send mass emails. He outlined his ideas in a paper called "Hashcash - A Denial of Service Counter-Measure" (2), which was later published in 2002.
Proof-of-work is based on the simple idea that a computer must expend energy to solve a complex problem in order to generate a unique digital token, or hash. This hash serves as proof that the computer performed the required work to generate it. While verifying the hash's authenticity is simple and inexpensive, creating it requires significant computational effort.
An analogy are those padlocks that need a sequence of numbers to open. There is no mathematical formula that, if solved, provides the sequence. Therefore, the only way to open the lock is to test all possible sequences, which requires effort, time and money. But once discovered, anyone can verify that it is valid.
Under Back's proposal, email senders would be required to attach a unique hash to each email they send. The cost of creating each hash would be negligible (for example, a hundredth of a penny) but the cumulative cost of sending millions of spam emails would quickly become prohibitive. This would effectively prevent spammers from inundating people's inboxes with unwanted messages.
While Hashcash was not commercially successful, proof-of-work became a crucial mechanism for enabling coordination among untrusted parties in decentralized systems.
b-money
In 1998 with the publication of "b-money, an anonymous, distributed electronic cash system" (3), Wei Dai proposed a system that addressed the critical flaw of Chaum’s eCash: Its centralization.
Dai's system was based on the idea of a distributed ledger, where each participant in the network would maintain their own copy of the ledger, which would contain information about how much money each participant currently had.
It eliminated the need for a central authority to maintain the system, which made it more resistant to state coercion or other forms of censorship. Additionally, it allowed for greater privacy and anonymity, as each participant could maintain their own copy of the ledger and there was no centralized repository of transaction data.
Despite its many advantages, Dai's system was never implemented. However, it laid the groundwork for some of the decentralized electronic cash systems that would follow.
Bit Gold
Also in 1998, Nick Szabo designed another system for digital money known as Bit Gold (4).
At the heart of Bit Gold was a new idea: the concept of being "verifiably expensive" to produce. This meant that users of the system could mint new tokens by providing a hash that was so costly to produce that it acted as a limiting factor on the increase in the money supply. This hash would be verified by a distributed ledger, similar to Wei Dai's b-money system.
However, Bit Gold faced several challenges that prevented it from becoming a reality. One of the main challenges was the issue of fungibility. As computers continued to improve in processing power, it became easier to produce a hash that had been produced in the past.
This meant that hashes produced at different points in time would not be equivalent in perceived value, which would break an important property of money known as fungibility. In other words, the digital assets created by Bit Gold would be more like diamonds, with irregular shapes and qualities that were not easily interchangeable with each other, rather than like gold, which is uniform and easily exchangeable.
An analogy here is the following: imagine that there is a record of how much money each person has at a given moment, which has been validated by the majority of the network. This record is then kept in a safe with one of those padlocks that need a sequence of numbers to open. After a few transactions, the record is updated and needs to be stored again in another safe with that padlock. However, as the network of participants grows, a group could go to the first vault, test all possible combinations, open the lock and change the balances of the participants.
What later solved this problem was a chain of blocks mechanism
In the example above, the first safe would be stored inside the second safe, the second inside the third, and so on.
Therefore, if the group wanted to change the balances of the first register, it would have to open all the vaults that are guarding the first one, which would require a lot of time and effort.
RPOW
In 2004 it was Hal Finney's turn.
He designed a system known as RPOW (5) (Reusable Proofs of Work). RPOW was a simplified version of Szabo's Bit Gold, but with a key difference: Finney was able to create a working prototype of his system.
Despite this achievement, RPOW faced a significant problem that had plagued earlier digital currencies: centralization. Like Chaum's eCash, RPOW relied on a central authority to maintain the ledger of transactions. To address this issue, Finney tried to replace the central authority with an untamperable hardware device. While this hardware device would be more trustworthy than a company that could be coerced, it still posed a vulnerability. If the hardware device were turned off, the entire system would be compromised.
It seemed almost impossible to create a decentralized payment system…
Until, on October 31, 2008, the following message was posted on a cryptography mailing list under the pseudonym Satoshi Nakamoto:
“I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party…”
(Foto da mensagem de 31 de outubro)
References:
https://sceweb.sce.uhcl.edu/yang/teaching/csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF
http://www.hashcash.org/papers/hashcash.pdf
http://www.weidai.com/bmoney.txt
https://unenumerated.blogspot.com/2005/12/bit-gold.html
Technical Concepts
As we've discovered, Bitcoin wasn't born in a vacuum. It emerged, standing on the shoulders of giants, drawing on the groundwork laid by its predecessors. These earlier attempts tackled numerous challenges, paving the way for Bitcoin's eventual success.
In the chapters that follow, we'll delve into the unique blend of characteristics and innovations that come together to make Bitcoin what it is. Each technical aspect, from Hashing to the Blockchain, plays a crucial role in creating a decentralized form of money that once seemed beyond reach.
Hash
While relatively unknown to the general public, hashing plays a vital role in securing our data and maintaining the integrity of digital systems.
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. (indicar o link para um SHA256 para o leitor testar)
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
Transição da introdução para os capítulos:
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.
(Talvez trazer o exemplo anterior da fig)
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, Olivia, joining a class midway through the school year. She's eager to catch up with her classmates, especially with an older student, Sofia, who's known for diligently taking comprehensive notes since day one. Olivia only has the first lesson in her notebook (akin to the genesis block in a node's blockchain).
To catch up, Olivia starts by asking Sofia 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. Sofia, realizing Olivia 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.
Olivia then requests the details of each missed lesson, starting with the earliest ones she lacks. Sofia obliges, sharing his notes in manageable chunks, ensuring Olivia isn't overwhelmed. This mirrors the new node fetching blocks using getdata messages based on the hashes received from its peers.
As Olivia 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 Sofia's. In the Bitcoin network, this represents a node progressively downloading blocks until its blockchain is fully synchronized with the network.
Just like Olivia, 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.
Nós de mineração / 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, one 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.
xxxxxxxxxxx
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.
If a valid block is received and no parent is found in the existing chains, that block is considered an "orphan." Orphan blocks are saved in the orphan block pool where they will stay until their parent is received. Once the parent is received and linked into the existing chains, the orphan can be pulled out of the orphan pool and linked to the parent, making it part of a chain. Orphan blocks usually occur when two blocks that were mined within a short time of each other are received in reverse order (child before parent).
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.
Imagine a football (soccer) championship where the current rule allows teams to make up to 3 player substitutions during a game. This is analogous to the existing Bitcoin network's rules. Now, consider a change in the rules that resembles a hard fork in the Bitcoin network. If a new rule is introduced allowing teams to make up to 4 substitutions, this would be like a hard fork. Under this new rule, games with 4 substitutions would be invalid according to the old championship rules that only allowed 3 substitutions. This is similar to how a hard fork in Bitcoin introduces new rules that are either looser or completely different. As a result, blocks created under these new rules are not recognized by nodes operating under the old rules, leading to a split in the network.
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.
Following our football analogy, a soft fork in the Bitcoin network can be illustrated by tightening the existing football game rules. If a new rule is implemented where only up to 2 substitutions are allowed, it mirrors a soft fork. In this scenario, all games played under the new rule with 2 substitutions are still valid in the championship context, since they don't violate the original rule of up to 3 substitutions. This is similar to a soft fork in Bitcoin, where new rules are a stricter subset of the old. While blocks created under the new rules are valid for both new and old nodes, some blocks that are valid under the old rules might not be valid under the new, stricter rules. This way, the new rule is backward compatible with the old rule, just as in a soft fork in the Bitcoin network.
Here’s a Bitcoin 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.
No activity yet