Curriculum
Course: What is Crypto
Login
Video lesson

The Bitcoin Whitepaper

The Building Blocks of Bitcoin

Bitcoin’s Blueprint: Analyzing the Whitepaper’s Impact

Why did a nine-page paper on electronic cash, sent to a cryptography mailing list in 2008, spark a global financial revolution? The Bitcoin Whitepaper by Satoshi Nakamoto challenged traditional finance by proposing a purely peer-to-peer (P2P) currency model that operates without intermediaries. This “trustless” digital money model was groundbreaking, offering a decentralized alternative to banks and centralized institutions. Today, Bitcoin’s whitepaper is regarded as a pioneering document that laid the foundation for cryptocurrencies and decentralized finance (DeFi). In this lesson, we’ll analyze the mechanics and principles of Bitcoin as presented in the whitepaper, while exploring how these ideas have redefined finance and prompted the rise of an entire crypto ecosystem. This critical exploration aligns with our CFIRE program’s mission to equip learners with a deep understanding of the concepts reshaping modern finance.


Double-Spending: How Bitcoin Changed Digital Finance Forever

Bitcoin is more than just “digital money”; it’s a response to the inefficiencies and risks of traditional banking. The whitepaper opens with Satoshi’s assertion that Bitcoin can solve what he calls the “double-spending problem” without needing a trusted intermediary. He then explains Bitcoin’s P2P network, the importance of cryptographic proof, and how miners—individuals or entities validating transactions—play a role in Bitcoin’s decentralized security model. Through this design, transactions can be verified without relying on banks, and users maintain control over their funds via private keys. Nakamoto’s arguments provide a blueprint for a self-sustaining currency model, powered by incentives and consensus among network participants rather than centralized oversight. Each section of the whitepaper addresses a core component of this model, from transaction mechanics to mining incentives, bringing together technical rigor and an ideological stance on decentralization.


Critical Analysis

Strengths of Nakamoto’s Vision

  1. Decentralization as a Foundational Principle
    Nakamoto’s decentralized approach challenged a core assumption in finance: the need for centralized intermediaries. By removing banks from the process, Bitcoin creates a more accessible, censorship-resistant system. This shift has empowered people globally who lack access to traditional banking and finance, and it’s particularly impactful in regions with unstable banking systems or high inflation.

  2. Proof of Work (PoW) as a Security Mechanism
    PoW is an elegant solution to network security, requiring miners to solve complex mathematical problems that validate transactions. This process is energy-intensive, but it deters malicious actors from attempting to manipulate the network. Bitcoin’s PoW model also ensures transparency, as each transaction is public and immutable, a stark contrast to the often opaque traditional financial system.

  3. The Solution to Double-Spending
    Satoshi’s insight into the double-spending problem was revolutionary. By recording every transaction on a public blockchain, Bitcoin ensures each digital coin can only be spent once, something that earlier digital currencies failed to address adequately. This approach has led to the development of countless secure digital assets that use blockchain as a reliable source of record.

Potential Weaknesses and Limitations

  1. Scalability Challenges
    While PoW offers security, it also slows transaction processing, which raises concerns about scalability. As Bitcoin adoption grows, the network may struggle to handle increased transaction volumes, affecting its viability as a mainstream payment solution. Solutions like the Lightning Network attempt to address this but introduce a level of complexity and centralization that some argue undermines Bitcoin’s original ethos.

  2. Energy Consumption of Mining
    Bitcoin’s mining process is energy-intensive, leading to environmental concerns. PoW requires vast amounts of electricity, sparking debates about Bitcoin’s environmental impact and prompting some to argue for alternative consensus mechanisms, like Proof of Stake (PoS). Bitcoin’s energy consumption presents a potential barrier to adoption in a world increasingly concerned about sustainability.

  3. Privacy Considerations
    Although Bitcoin transactions are pseudonymous, they are also publicly accessible on the blockchain. This transparency can compromise user privacy, as transactions can be traced back to individuals through exchanges and other regulatory checkpoints. While privacy-centric coins like Monero offer more anonymity, Bitcoin’s open ledger makes it less private than cash or other privacy-focused cryptocurrencies.


Connections to Cryptocurrency and Blockchain

Bitcoin’s success has inspired countless cryptocurrencies and sparked an era of decentralized finance (DeFi), which brings traditional financial services—like lending, borrowing, and trading—onto blockchain networks without intermediaries. For example, Ethereum expanded on Bitcoin’s decentralized principles by introducing smart contracts, enabling programmable agreements that execute automatically when conditions are met. This functionality supports DeFi applications like Compound and Uniswap, which allow users to earn interest, trade assets, and more without needing a bank.

Moreover, the concept of “hard money” introduced by Bitcoin’s 21 million coin supply limit has also influenced DeFi and crypto ecosystems. For instance, Ethereum has adopted a partial burn mechanism, where a fraction of transaction fees are destroyed, creating a deflationary effect. Additionally, DeFi projects like MakerDAO’s DAI cryptocurrency use collateralized debt to stabilize value, echoing Bitcoin’s principles of decentralization while aiming for a more stable, spendable asset.

The Decentralized Advantage
Bitcoin’s decentralized design offers distinct advantages, such as censorship resistance and the potential for global, borderless transactions. These attributes are powerful in nations with unstable currencies or authoritarian governments, where Bitcoin provides an alternative to potentially unreliable local banking systems.

Challenges in the Decentralized Ecosystem
However, decentralization also introduces regulatory challenges. As cryptocurrencies grow, governments face pressure to implement regulations to protect investors and prevent illicit activity. Bitcoin’s transparency could become a double-edged sword in this scenario, as regulators push for more transparency that could compromise the privacy of users.


Broader Implications and Future Outlook

Bitcoin’s introduction has forever changed the financial landscape, and its principles are gradually permeating other areas of finance and technology. Concepts like decentralized autonomous organizations (DAOs) have emerged, where groups can govern themselves using blockchain protocols, enabling a community-driven approach to management and decision-making. While DAOs are still in their infancy, they hold the potential to decentralize everything from charities to corporate governance.

In finance, Bitcoin’s deflationary model is sparking renewed debate about inflation and monetary policy. Bitcoin’s fixed supply stands in stark contrast to fiat currencies, where central banks can print money as they see fit, potentially leading to inflation. As economic uncertainty continues, Bitcoin’s limited supply may make it more attractive as a hedge against inflation, much like gold. Additionally, central banks worldwide are experimenting with digital currencies (CBDCs), but unlike Bitcoin, CBDCs are typically centralized, raising concerns about surveillance and control.

Looking ahead, Bitcoin’s foundational principles could influence emerging fields like artificial intelligence and the Internet of Things (IoT). As devices become more autonomous, decentralized networks like Bitcoin may provide the infrastructure for secure, peer-to-peer data sharing and micropayments. Such developments underscore Bitcoin’s relevance as more than just digital money but as a technology that could underpin future advancements across multiple sectors.


Personal Commentary and Insights

Reflecting on Bitcoin’s inception, it’s remarkable how a seemingly niche technological experiment has evolved into a global phenomenon. As someone deeply engaged in the intersection of finance and technology, I see Bitcoin as both a technical marvel and a cultural movement. It challenges the traditional financial power structures by empowering individuals to take control of their wealth, an idea that resonates with people across socioeconomic boundaries.

However, I also recognize the limitations that Bitcoin faces. While it offers freedom, it’s not yet accessible to everyone due to technical and economic barriers. The future of Bitcoin will depend on its ability to scale while maintaining its core principles. Additionally, as the crypto ecosystem matures, Bitcoin’s role may evolve from a transactional currency to more of a “digital gold,” a stable, secure store of value that complements other blockchain innovations.


Conclusion

Bitcoin’s whitepaper set in motion a financial revolution, proposing a secure, decentralized way to transfer value across borders without intermediaries. Its principles have inspired a movement, leading to thousands of new cryptocurrencies and reshaping how we think about money, privacy, and ownership. As we continue to witness rapid technological advancements, Bitcoin’s foundational ideas remain as relevant as ever, providing a blueprint for decentralization that extends far beyond finance.

With each lesson in the CFIRE training program, we’re delving deeper into these pioneering concepts, bridging traditional finance and the transformative potential of blockchain. As we look to the future, we see Bitcoin not just as digital cash but as the catalyst for a decentralized world. Let’s keep moving forward with this powerful foundation as we explore the next stages in the CFIRE journey.


Quotes

  1. “Bitcoin’s decentralized design isn’t just technical; it’s ideological, challenging the very need for centralized control in finance.”
  2. “By removing intermediaries, Bitcoin empowers people globally who lack access to traditional banking—an opportunity for financial inclusion like never before.”
  3. “Bitcoin’s deflationary model raises an essential question: in an era of limitless fiat supply, could limited digital money redefine our concept of value?”

This lesson offers a critical perspective on the Bitcoin whitepaper, providing context and connections to the broader crypto ecosystem. It aims to encourage CFIRE learners to think about Bitcoin not just as a technology, but as a transformative idea that challenges financial norms and fuels the decentralization movement. Let’s prepare to dive even deeper into this journey!

 

 

Foundation of Bitcoin: Understanding the Whitepaper

In this lesson, we’ll explore the foundational ideas of Bitcoin as outlined by Satoshi Nakamoto in the original whitepaper. This whitepaper doesn’t just define Bitcoin but lays out the bedrock of modern decentralized finance (DeFi) and blockchain technology. Its creation resolved long-standing issues in digital payments, such as the double-spending problem, without relying on intermediaries. Understanding Bitcoin’s framework and its revolutionary decentralized model is essential for grasping the cryptocurrency ecosystem and the potential of blockchain to transform financial systems.


Core Concepts

  1. Peer-to-Peer Network

    • Traditional Finance: Typically requires intermediaries like banks to facilitate transactions.
    • Crypto Application: Bitcoin’s network allows direct transfers, removing the need for third-party involvement.
  2. Double-Spending Problem

    • Traditional Finance: Prevented by centralized systems that track balances.
    • Crypto Application: Solved in Bitcoin via blockchain, ensuring each transaction is unique and irreversible.
  3. Blockchain

    • Traditional Finance: No direct equivalent, but functions like a ledger of all transactions.
    • Crypto Application: A decentralized, immutable ledger where every transaction is recorded.
  4. Proof of Work (PoW)

    • Traditional Finance: Not applicable.
    • Crypto Application: PoW is a consensus algorithm ensuring transaction validation and security, used widely in crypto networks like Bitcoin.
  5. Private and Public Keys

    • Traditional Finance: Used in certain secure communications, like bank transfers.
    • Crypto Application: Essential for securing digital assets; the private key acts as a password, and the public key is like an account number.

Key Sections

  1. Introduction: The Digital Cash Revolution

    • Summary: The section introduces Bitcoin as a solution for online transactions without intermediaries.
    • Detailed Explanation: Nakamoto outlines the intent to create a peer-to-peer (P2P) electronic cash system, which bypasses the need for a bank or any third-party authority, unlike traditional finance where banks control money flows.
    • Crypto Connection: The lack of third-party involvement eliminates transaction fees, making micropayments and global accessibility feasible.
  2. Transactions: Defining Bitcoin as Digital Cash

    • Summary: This section describes what Bitcoin is: a transferable digital asset.
    • Detailed Explanation: Bitcoin transactions follow a model where each transaction output can only be used once, securing against double-spending.
    • Crypto Connection: Bitcoin’s Unspent Transaction Output (UTXO) model is distinct from traditional bank accounts and balances, ensuring transparency and verifiability for every transaction on the network.
  3. Timestamp Server: The Foundation of the Blockchain

    • Summary: Here, Satoshi presents a unique timestamping method that forms the basis of blockchain.
    • Detailed Explanation: Bitcoin’s decentralized network time-stamps all transactions by grouping them into blocks, chaining each block to the previous one to create a timeline. This system is tamper-resistant, as altering any single transaction would disrupt all subsequent blocks.
    • Crypto Connection: The blockchain is foundational in verifying transactions without relying on a single authority, unlike traditional finance’s centralized ledgers.
  4. Proof of Work: Securing the Network

    • Summary: This process, called mining, verifies and secures the network by requiring computational effort.
    • Detailed Explanation: In a decentralized network, PoW aligns incentives by rewarding miners with Bitcoin for contributing computing power to validate blocks, thereby securing the blockchain.
    • Crypto Connection: PoW ensures transparency and trust, countering potential manipulation that would be possible in traditional financial models reliant on centralized systems.
  5. Incentives and Sustainability

    • Summary: Bitcoin’s incentive system encourages network participants to behave honestly.
    • Detailed Explanation: Nakamoto introduces block rewards, a system where miners are compensated with new bitcoins for each valid block added. This incentivizes maintaining network security and stability.
    • Crypto Connection: By limiting Bitcoin to a maximum of 21 million coins, Satoshi built scarcity into Bitcoin, which parallels traditional concepts of supply and demand but in a fully decentralized manner.

Real-World Applications

Bitcoin has directly influenced the development of decentralized finance (DeFi), a rapidly growing sector where financial services operate on blockchain networks, eliminating intermediaries. Concepts such as “smart contracts” on platforms like Ethereum extend Bitcoin’s ideas by enabling programmable transactions.

Challenges and Solutions

  • Challenges: Bitcoin faces high energy consumption due to PoW, which raises environmental concerns. Scaling is another challenge, with the Bitcoin network processing only a limited number of transactions per second.
  • Crypto Solutions: Layer-2 solutions, like the Lightning Network, address scalability issues by enabling faster transactions at lower fees.

Key Takeaways

  1. Bitcoin Eliminates Intermediaries: Enables peer-to-peer transactions without banks.
  2. Blockchain is Immutable: Ensures transparency and trust through a tamper-resistant ledger.
  3. Proof of Work Secures the Network: Provides a decentralized way to verify transactions.
  4. Scarcity Drives Value: Bitcoin’s 21 million supply limit introduces a concept of digital scarcity.
  5. Incentives Foster Honesty: Miners are rewarded for securing the network, aligning their interests with users.

Discussion Questions and Scenarios

  1. How does removing intermediaries impact global finance?
  2. In what ways does Bitcoin’s scarcity model affect its value compared to traditional assets?
  3. Compare Bitcoin’s PoW mechanism to traditional financial safeguards against fraud.
  4. Imagine you are a miner: how would block rewards and transaction fees impact your decision to mine?
  5. Discuss how timestamping contributes to blockchain’s transparency.

Additional Resources and Next Steps

  1. Bitcoin Whitepaper by Satoshi Nakamoto
  2. Mastering Bitcoin by Andreas M. Antonopoulos
  3. Crypto Is FIRE Training Program next lessons (covering topics like Ethereum, Smart Contracts, and DeFi)

Glossary

  • Blockchain: A decentralized ledger that records all Bitcoin transactions.
  • Double-Spending Problem: Risk of spending the same digital asset multiple times, prevented by blockchain in Bitcoin.
  • Peer-to-Peer (P2P): A decentralized network where participants directly transact with each other.
  • Proof of Work (PoW): A mechanism that requires computational work to add a block to the blockchain, securing it from attacks.
  • UTXO (Unspent Transaction Output): Bitcoin’s method of ensuring each output from a transaction can only be spent once.

Congratulations on mastering this essential lesson in CFIRE! Bitcoin’s foundations form the backbone of the crypto landscape, and now you’re ready to dive deeper into the world of decentralized finance and blockchain. Let’s gear up for the next exciting stage of your journey in the CFIRE training program!

 

Read Video Transcript

The Bitcoin Whitepaper | Fully Explained 

We all know the story by now. Some fella named Satoshi Nakamoto sent an email to a cryptography mailing list on Halloween 2008.  The email read, I have been working on an electronic cash system that’s fully peer-to-peer.  Here is a link to the paper. Here is the main properties. Here is the title of the paper.
 And here is a copy of the abstract of the paper. Oh, and did I mention, here’s a link to the paper.  My name is definitely Satoshi Nakamoto. Before we get into the white paper, let me give you a  brief outline of each section. The first section is titled the introduction, and this is pretty  self-explanatory. He introduces the paper.
 Section two is called transactions and in this section we define what an electronic coin is  and how exactly we go about transferring it from one person to the other. Section three is entitled  timestamp server and this is basically a centralized blockchain and this technology has been around  since the 1990s but this hasn’t really been applied at all to digital money or electronic money or  Cryptocurrencies or whatever you want to call it until Satoshi did so in this white paper  Section 4 is entitled proof of work and we use proof of work to extend the centralized blockchain into a decentralized blockchain
 Section 5 brings sections 2 3 & 4 together and tells you exactly how the network operates how do we talk to nodes  what do you do when you receive a transaction from a node how do you validate a transaction  how do you validate a block and so forth section six is called incentives and not surprisingly it  is all to do with incentivizing people to strengthen the network to run their own node  and to help secure the blockchain section 7 should should not be overlooked. It is entitled Reclaiming Disk Space, which sounds
 boring as fuck, but I assure you this is extremely important. It is important because it enables  something called Simplified Payment Verification, which is absolutely essential for the long-term  sustainability of Bitcoin. Talking of a simplified payment verification,  that is the name of section eight,  and we’ll explain how on earth this works.
 It basically allows you to run a very lightweight node  without much memory,  and you can run this on your mobile phone  or a small coffee shop can run it.  And of course, if we want Bitcoin to scale  to any substantial size,  it is absolutely essential that we allow people  to participate in the network by running what we call lightweight nodes and  section 9 at this point we say to ourselves hang on if something costs  20,000 so-called electronic coins then it’s got to be a piss take to send 20,000  transactions over the network is there any way we can just say hey combine all
 of my coins here it is 20,000 lump sum enjoy the answer is of course way we can just say, hey, combine all of my coins. Here it is, 20,000 lump sum.  Enjoy.  The answer is, of course, yes, we can do that.  And section nine tells us how we go about doing that.  Section 10, this is pretty much obsolete.  It goes on about privacy and how, oh yes, we’re so private  because we all have public keys identifying us and not our real names.
 But as we shall find out, that is no longer the case.  Section 11 calculations  this part of the paper is all about an attacker trying to attack the network which sounds very  scary and that’s pretty much it. Section 12 is the shortest section in the history of sections  it just says conclusion yep here’s what I’ve done do you like it I hope you like it.
 By liking,  commenting and subscribing what you will do is increase the probability of a brighter future  because more people will be better educated at crypto and they won’t shit to themselves and run away when shit hits the fan.  That’s enough for now. Let’s get into the paper.  Oh yeah, yeah, yeah.  Mr. Banker, please don’t take my coins away.
 We know they won’t be where you say.  I feel lucky because my stomach’s full today. Sometimes I don’t even pray.  Before we get into the paper, we first have to know what a hash function is and what is meant by a digital signature. Some of you already know this, so I’m going to go through  this very, very quickly.
 So a hash function, if you ever see the pink H throughout this  video, that means hash function. It takes any input X, it could be the whole works of  Shakespeare. It could be the number zero. It could be the number 110001, whatever. The  main thing is this, no matter the size,  it will accept it and it will spit out a 256-bit number.
 This function has very, very special  properties. Any change whatsoever in x will result in an entirely different output and it’s impossible  to invert. And so we can treat this as a pseudo-random function. So why are we going to use  it? Later, as we shall see, what we are going to require is that when we take the hash of something  called a block, that the output begins with a certain number of zeros.
 And so the best thing  we can do in this case, because H just spits out random numbers, is a brute force approach,  which is going to keep trying numbers over and over and over again until we get the desired output. This will then  serve as our proof of work.
 Hey look I have these zeros that is proof that I’ve done the work and if  that doesn’t make sense then do not worry it will make sense in a bit. We will also use hash functions  in another way. We’re going to be taking the hash of transactions. In this case we’re just going to  get whatever it gives us. Transactions are fixed. We’re not going to be taking the hash of transactions. In this case, we’re just going to get whatever it gives us.
 Transactions are fixed.  We’re not going to be changing the number here.  It will spit out a unique number.  Well, basically unique because there is two to the power of 256 different possible outputs.  Basically unique.  And what this number is going to do, it’s going to serve as a transaction ID.  And we will see how we’re going to use that in section five.
 Private keys and public keys. Okay,  here we go. Anytime you see a red key, think private, only known by one person. Anytime you  see a public key, think public, known by everybody. And what we’re going to do is we’re going to send  a message to the rest of the Bitcoin network. Let’s call it M for now.
 And what this M will say  is, hello, I have the private key  corresponding to this public key and I wish to transfer my coins to somebody else here is the  proof that it is from me I will encrypt the message with my private key and everyone else will go okay  if you really did have access to the private key then if I get your public key and apply that to  this number then because they are inverses we should be  left with M and then they’re all satisfied.
 Now these private and public  keys are just numbers but as you’ve just heard I’ve been using terminology such  as applying to which kind of implies that they are functions and yes okay  they are numbers but when you have a private and public key used in  conjunction with a digital signature algorithm they act as the parameters  which implicitly define a function.
 Don’t worry about that, I will make another video on that very  soon and if you want to see that of course you know what to do, subscribe. Just as a side note,  it’s not mentioned in this paper and you don’t need to know, Bitcoin uses something called the  Elliptic Curve Digital Signature Algorithm, ECDSA for short, and it uses a particular version called SECP256K1.
 Okay,  let’s get into the actual paper. Let’s start with the abstract. Bitcoin is described as a system.  If you see Bitcoin with a capital B, it refers to the system as a whole, the protocols involved,  etc. If you see a lowercase b, that refers to the number go up coin, i.e. the currency. If you want  an example of each using  a sentence then here we go.
 I am learning about capital B it coin versus I just sent three lower  case B it coins to my friend. Okay so the whole point of this paper is that Satoshi is able to  solve something called the double spending problem using a peer-to-peer network that goes through any  third party. In the late 90s and early 2000s there were  a few attempts to solve this.
 B-money and Bitgold were only theoretical, they never got off the  ground. RPOW was implemented by somebody called Hal Finney who actually received the first ever  Bitcoin from Satoshi himself but his solution was centralised and I’m not going to go into that any  further. Basically they could not solve the double spending problem in a decentralised way. Now this  problem is really really simple in a decentralized way.
 Now this problem is really  really simple in a centralized banking model that we’re all familiar with. Let’s say we have two  women Alicia and Karen and Alicia wishes to send Karen some money. She’ll say hello bank pay Karen  $1051. They’ll check if she has enough. They’ll subtract it from her account and they’ll add it  to Karen’s account and then Alicia cannot send that money to anybody else because her balance  has been updated and she hasn’t got it.
 Now this is trivial in the centralized model, but the  question is how do we prevent somebody from double spending money in a decentralized system?  Now, one thing to point out is that Ethereum does use this account model. That is, it has basically  names and the balance or public keys and balances. Bitcoin has something called a UTXO or unspent  transaction output model.
 And this is going to be something different if you’re not familiar  with Bitcoin at all. But do not worry, we’re going to explain all of this very, very soon.  The rest of this abstract is repeated in the introduction section. So let’s just move on  to the first section of the paper. What’s worth pointing out here is that Satoshi does not say  the central banks have a monopoly on the issuance of fiat currency and we’re all enslaved.
 No, no,  no. His approach is not what you would think it is based on the current narrative around Bitcoin  being something that offers sovereignty to the individual, offers an escape out of the central  banking system or the banking system. Satoshi’s focus is actually on that of e-commerce on the internet.
 He says  during online transactions, a third party is required to settle disputes when people complain  or say, I want a refund. And so this basically stops us from having micropayment systems on the  internet, whereby we would pay a small amount of money for something such as watching a YouTube  video or reading an article online.
 Instead, as the number of transactions go up, we have the number of disputes going up  and the number of operating costs  for these third parties goes up.  And so basically all these third parties think to themselves,  hang on, this is not profitable.  So a solution is to set a minimum transaction amount.  And this leads us down  to the advertisement based business models.  There’s no need to go into how much shit  that comes along with that.
 And so Satoshi says, we do not need this.  We do not have to have this.  We can have an electronic payment system based on cryptographic proof instead of trust.  And he says, I propose a timestamp server.  That’s going to be a blockchain.  And I’m going to distribute it, make it decentralized.  And we’re going to have a singular chronological order of the transactions.
 And this entire system is going to be secure  unless an attacker accumulates more than 50%  of the CPU power, in which case we are fucked.  Okay, let’s now move on to section two of the paper.  Section two defines what an electronic coin is  and it gives us this pretty diagram here,  which shows us how the current owner transfers  to the next owner. You’ll notice that we us how the current owner transfers to the next owner.
 You’ll notice that we do not know where owner 0 got the coin from.  In section 6 I’ll tell you, and spoiler alert, the miners are rewarded with coins as a reward for securing a blockchain.  Let’s copy this diagram and explain precisely what a transaction is.  A transaction is simply three numbers.  Let’s say Alice wants  to transfer her coin to Bob.
 She will get Bob’s public key, she will get a hash of the previous  transaction. Now of course we don’t have previous transaction to reference right now, but let’s go  with it. And then she signs it, and then Bob does the same when he wants to send to Charlie,  and so forth. So let’s dissect this. Bob’s public key is a number, remember? The hash of the  previous transaction is a number and Alice’s signature, what she does, she gets these two  numbers, she concatenates them and she applies her private key to that.
 And then we have another  number. When Bob wants to send to Charlie, he gets Charlie’s public key, he gets the hash of the  previous transaction. This means get these three numbers, merge them all  into one number and take the hash of that number. And then Bob puts his signature down as the third  number.
 And what that hash, that second number does, it will tell people, hey, look, I am pointing  towards the previous transaction. If you go to the top of that transaction, you will see my public  key, use my public key to decrypt my signature. And you will see that the result is the concatenation of  the first two numbers of this transaction thereby proving that I have indeed transferred ownership  of my el
ectronic coin over to Charlie i.e. the person who has the private key corresponding to  the public key represented at the top of this transaction. If all these numbers are getting a  bit much for you let’s represent everything in a pictorial format so everything is much more clearer.  But wait, what if Charlie now says, okay, I’m going to try and send this same coin to both  David and Emma. He could do that.
 How do we stop it? The easiest thing to do is to introduce a  central authority, but then we just have the same scenarios with the banks and everything centralized and we know the only way to confirm the absence of transactions is to be aware  of all of the transactions but in order to do this in a distributed setting and not relying on any  third party we’re going to have to publicly announce all transactions and everybody is going  to have to be aware of all of the transactions.
 OK, that sounds easy, but now we need a way for everybody to agree  on a single chronological order of the transactions.  How do we do this?  Now, let’s not take this lightly.  The entire point of the Bitcoin network is to facilitate this.  The whole point of Bitcoin is to come up  with an agreed upon chronological order of the transactions in order to prevent double spending.
 Our solution to this problem begins with something called a timestamp server i.e a centralized  blockchain and so how does this work? Well we’re gonna have something called a chain of hashes,  we’re gonna publish the hashes and somehow that’s gonna prove that the data existed at the time.  Okay let’s expand on this a bit more, Let me explain to you what this pretty diagram is showing us.
 Let’s take three items that for whatever reason,  we need to be able to prove that it existed  at a particular date.  This could be a patent or it could be some photo  or just any text document.  At the lowest level, of course,  all of these things are just numbers.  So let’s represent them as their binary numbers.
 Now let’s group them together and call this thing a block. We’re going to take the hash of the previous block and then we’re going to take  all of these items. I’m going to add them to the hash of the previous block. I’m going to concatenate  them into one big long number.
 We’re going to then take the hash of that number and we’re going to be  left with a nice short 256-bit number. Now let’s just generalize and call these things items. These  will soon become the transactions,  but let’s just stick with items for now. Now we’re going to form a chain like this,  and you can imagine at the end of, say, every day, we publish this hash and let everybody know what the hash is so that if we attempt to change one of these items, even change one bit, it’s going  to change the hash of the block, and it’s going to have this ripple effect, and it’s going to
 completely change the hashes of all the other blocks. This is the main idea. If we claim our item was created on a  different day and everyone call us out on our bullshit because the chain of hashes will be  completely different.
 In the 1990s this technology was implemented and I’ll leave a link in the  description to all of those that are interested in finding out more. And basically what they did is every week they would publish this so-called hash in the New York  Times. That way it was available for everybody to see so they couldn’t change anything and try and  get away with it.
 But of course, because it was centralized, this one company had control over  what items went in. It was trivial to know which chain was the true chain because there was only  one chain. But as soon as we start to decentralize, we’ve run into multiple problems.  We’re going to have multiple chains and we don’t know which chain is the right chain.  We are left with complete and utter chaos.
 And this is where section four comes in.  This is all about how do we choose the chain.  Now this is the most important section of the white paper.  So pay attention.  Now this is the most important section of the white paper.  So pay attention.  In order to implement distributed timestamp server,  i.e.
 in order to have a decentralized blockchain,  we’re going to have to use something called proof of work.  Here is how it works.  Here’s a transaction as we have already seen.  It consists of three numbers.  Let’s just call this for now TX.  So these take the places of what we in the last section called items I’m gonna add two more things to this block  We’re gonna have the previous hash inside the block this time and we’re gonna have something called a nonce  I know this does not mean pedophile for all of you  British people and nonce stands for I think number used once as I mentioned at the beginning of this video
 We’re gonna require the hashes of the block to begin with a certain amount of zeros.  So what do I mean with the hash of the block?  We get each item in the block, i.e. each transaction.  We can merge all of these transactions together.  We’re gonna add that to the hash of the previous block,  and then we’re gonna add to this the nonce.
 We’re gonna start the nonce at zero,  and I’m gonna say, what is the output of this hash?  And it’s probably not going to start  with the number of zeros we require.  So we’re just going to keep increasing the nonce and using CPU power  ie raw energy to compute the hashes of these and remember each and every one  will be completely different it doesn’t matter a nonce is only incrementing by  one so the block looks kind of similar it’s going to be completely different  each and every time we change the nonce by one unit. Finally, we’re
 going to arrive at a nonce such that when we concatenate it with the hash of the previous  block and the transactions in this current block, the hash of this will begin with the required  amount of zeros. So we’ll take a copy of that nonce, put it in the nonce slot, and then we’re  going to feed the hash of this block into the next block.
 We’re going to collect all the transactions  in this block. We’re going to start our nonce at at zero and we’re going to repeat. That is how we’re  going to chain the blocks. It requires energy, physical resources to chain these blocks together.  Okay let’s take a step back and see how this rule plays out in a distributed setting.
 That graph you  see at the top there, each node of that graph, think of that as eight people. I think there’s eight nodes, eight nodes. Think of them as people scattered around the world on the laptop, all  playing along with this game we call Bitcoin. So far, they have this chain that you’ve seen down  below you with these green blocks. They’re all going to be so-called mining the blocks, i.e.
 they’re going to just simply be increasing the nonce of their block until they find a nonce,  such that the hash of  the block starts with the required amount of zeros. Let’s say this fella over here is the  first one to find the nonce that satisfies this requirement for his block. He will then send a  message to all the people he’s connected to, these three people, and say I have come up with a new  block to chain to our blockchain and so all of these other people are going to say okay we are  going to now try to
 chain another block onto your block because the idea is the longest block is the block you work  with but let’s say this guy here also finds a suitable nonce he will then send a message to  all of the people he’s connected to i.e these four people and say hey guys i have mined a new block  and so these two people haven’t seen the red block yet so they’re going to accept and they’re going to start working on the blue block but these other  two blocks here they have just received the red block prior to receiving this guy’s blue block
 so what they’ll say is no I received the red block first I will continue working on this red block  I’ll keep your blue block there in case your chain gets longer of course this little guy up here he’s  connected to these blue guys here so he’s probably going to receive the blue block first and so he’s going to start  work on that too as you can see we appear to be running into problems here because we haven’t  agreed upon which is the correct chain because from each of the nodes perspective there is one
 singular chain but from this objective point of view this bird’s eye view that we have we can see  there is not a unanimous agreement among the nodes  about which is the correct block now before long some node let’s say this node is going to find  another block he’s going to send it out to everyone he’s connected to those two red nodes are hopefully  going to accept his block and work with that this blue node will soon realize that he has gone down  a different path but will accept that it is longer and so he will just simply transfer over to this
 red chain over here he will then forward this on to all of the nodes he is in direct contact with  and they will do the same and assuming that nobody else has managed to find another block within this  small time delay of the nodes communicating with one another we will have reached a unanimous  agreement as you can see there’s kind of two distinct regions of the blockchain here we have  those blocks that are old enough such that everyone agrees on the order.
 But then the most recent blocks, there is some ambiguity due to different nodes claiming  they have lengthened the blockchain.  But then whilst one sends his message that he has extended the blockchain to the rest  of the network, another node also does the same.  And so some nodes are going to receive one block first  and vice versa and so we have this kind of split between order and chaos.
 Let’s move on to section  five this tells us how to run the network in six steps. Step one new transactions are broadcast to  all nodes so what this means if I want to buy a car I will have to send the transaction that is  the three numbers to every  node I am connected with and they will then forward it on to every node they’re connected with.
 So  although it’s presented as a peer-to-peer payment system really what we’re doing is sending it to  the entire network and then we’re kind of by this proof of work mechanism all coming to an agreement  on a chronological order and so we don’t really have to go through a third party. Step two each  node collects new transactions into a block and so these blocks’t really have to go through a third party. Step two, each node collects new transactions into a block.
 And so these blocks are actually listening  for new transactions because they want to fill up their block  so that they can start working on finding a suitable nonce.  Speaking of suitable nonces,  once they have enough transactions,  they focus on finding the suitable nonce.  When a node finds a proof of work,  that is the hash of its block starts  with the required amount of zeros,  it broadcasts this block to all of the nodes. So those first four steps are pretty easy.
 This  fifth step here, it says we have to accept the blocks only if all of the transactions are valid  and not spent. I think it’s worth going over exactly what this means. How do we validate a  block? Okay, we have transactions in it, we have the previous hash, and we have a nonce. Apart from  the obvious of checking that once we hash all of these things, we get the required amount of zeros,  we also have to check that these transactions have not already been spent.
 How do we do this?  Okay, let’s take this first transaction. We get the transaction ID, and here is a representation  of the blockchain we’re working with. Let’s say we are this red block here, and so this previous hash  refers to the hash of  this block here.
 So with this transaction ID this is meant to tell us which block our transaction  is in and then within that block is our transaction in the first slot, the second slot, the third slot  etc. How do we find that? Well we could go through each and every block, take the hashes of every  transaction in that block and compare it to our transaction ID and see if they match. But this isn’t the smartest way to go about it.
 The computational cost of this  is big O of N and as the blockchain scales this will become very very slow. Instead every node,  so let’s say back in the day you had a laptop, you were using your CPU and you were a node in  the Bitcoin network, what you would do is you would keep this simple database in RAM. You’d  have transaction IDs and then their corresponding block number and then  the transaction slot number within that block where it is to be found.
 Notice that I’ve ordered  these transactions in ascending order and so they are ordered. And how do you sort through an ordered  list to find the element of interest? Well, we can perform a binary search. Now this is of computational  cost big O of log of n. This is far, far,  far faster and this scales way better than the previous naive brute force approach.
 So let’s say  after we do this we find the block where our transaction is, we get that transaction and we  get the public key from that and we attempt to decrypt this signature. We end up with a number  after we apply the public key to that number and all we have to do is simply verify that the output  of this is the result of concatenating the first two numbers  of the transaction.
 If this is the case then we have verified that this  transaction is valid. We then go over to this transaction over here that we have  just referenced and we make sure to delete this out of our local transaction  ID data set we have stored in RAM. We repeat this for all transactions in the block and if they all  pass then we have validated the block and we accept it.
 We express our acceptance of the block  by then working on the next block in the chain using the hash of the accepted block as the  previous hash. Now what is mentioned here we’ve already shown that there could be competing chains  near the present moment and then the tie will be eventually broken and then everyone will agree on a single chain eventually.
 This  part says don’t worry if you’re not connected to every single node in the  blockchain because once you pass it on to everyone you’re connected with  they’ll pass it on to everyone they’re connected with so it exponentially runs  through the network and it reaches everybody. But why would anyone bother  running a node?  What do they get out of it?  Well, here is where section six comes in, incentives.
 Remember when I said in section two,  where the fuck does this owner zero get his coin from?  Well, it turns out that when you successfully mine a block,  you are allowed to, as the first transaction in that block,  simply say, I award myself a coin.  This adds incentives for the nodes to support the networks and then this is the mechanism by which coins come into circulation. This part says we could cap the maximum number of coins allowed which is obviously has been done 21 million thereby having no inflation and we can transition into a network whereby the miners are incentivized with transaction fees instead. And this last part
 here says this incentive will help to encourage nodes to stay honest, because if you had more CPU  power than all of the honest nodes combined, you could just be honest and mine the blocks and be  rewarded with Bitcoins. Moving on to section seven, or should I say seven and eight, these two sections  are very, very, very closely related.
 The technology in section 7  allows for something called simplified payment verification or SPV and these would not be  possible without section 7 here. So SPV allows us to verify payments without running a full node  on the network which as I briefly mentioned earlier is extremely important for the sustainability of  the Bitcoin network.
 If we run a small barbershop or  whatever, we need to be able to have access to the network to ensure that we have been paid.  Now Vitalik Buterin himself in the Ethereum white paper, as an aside, subscribe if you want to have  this kind of similar video, but for the Ethereum white paper instead. I plan to do that video very,  very, very soon. The Ethereum white paper mentions these two sections, I mentioned just how important they are. Let’s take a closer look at section 7.
 So basically we’re in this  situation, we can discard all of the transactions that have already been spent because we only need  to know the latest transaction in any coin. So to illustrate this, let’s take our blockchain,  we have this kind of certain region and uncertain  region.
 Remember that every coin is created in the first transaction slot in every new  block. So let’s say a coin was created in this block and was rewarded to whoever mined  this block. Let’s say this guy then sent this coin to somebody else in this block and the  same happened in this block and this block and this block. So this creation block here will just have the successful miners public key in it.
 This  second block will look something like this where this hash will refer to the hash of  this transaction or in this case just the hash of the public key and then we will use  that public key in this transaction in order to decrypt the signature in the most recent  transaction thereby verifying that the owner of the coin has given permission to transfer the coin.
 Now, this is the process of transacting,  and this is the chain of digital signatures that define the coin.  As you can see, it gets a bit confusing,  because this chain exists within the blockchain,  and it’s kind of implicit.  It’s not stored anywhere.  But anyway, as you can see, this public key with an e stamped on it is the most recent transaction therefore edward is the owner of this  coin and all of the previous transactions can actually be disregarded because we won’t actually  ever have to refer to them but then as we saw in section three if we change or in this case remove
 a transaction from the block the hash of the block is going to change. And so this will  have a ripple effect and break the entire chain of hashes. So the question is, can we delete  transactions whilst not breaking the chain of hashes? The answer is yes. And in order to do  this, we’re going to have to hash the transactions into something called a Merkle tree.
 And so we  have a nice diagram to look at again and we have this down here which feel free  to read it just says how great it’ll be and how much memory we will save. Okay so let’s just take  a step back here. Here’s what we have so far let’s call these transactions 0, 2, 3 to just show that  they are actually different transactions. We have a chain of them.
 Here’s the problem if we delete  one and this changed the hash of the block and so this has the ripple effect and it fucks up the  entire chain and all of our security is completely gone because all of the proof of works are completely  messed up so here’s what we’re going to do instead just going to have this thing called a block  header and this block header is going to include the hash of the previous block header the root  something called the root hash as well as the knots so what is this root hash? Okay so what we do we get each of our
 transactions and we take their hashes and then for each pair we concatenate them and then take  another hash and we keep doing this until eventually we will concatenate two numbers,  take the hash and we will have no more pairs left and we will call this the root hash and we will  include this within the block header.
 So let’s just be clear about  what’s going on here. Everything with a green box around it is what we have stored in our memory.  All of these red things are not stored because if we have these green boxes we can simply calculate  the red ones. Of course everything in the block header is always stored. That is permanently in  our memory. Let’s say we no longer need to ever reference transaction one here ever again.
 What we could do is simply instead of storing the transaction we could store the hash of the transaction and  notice that we can still  reproduce the root hash from everything we have stored in these green boxes.  Similarly if we never have to reference transaction zero we can delete that and simply store the hash of transaction zero but then at  that point why are we storing both the hash of the first transaction and the hash of the well  the zeroth and the first transaction we could simply get rid of both of them and just store  the hash of the result of concatenating these two hashes yes and i’m aware this gets really really
 confusing but it’s really take if you pause the video and really go through it you’ll’ll find it’s quite simple. So we can do the same with transaction number two.  Now, let me just give a quick example here. If somebody says, hi, can I have proof that  transaction three was included in this block at the time of creation? Then we can say, sure,  no problem.
 Take this number, take this number, get your transaction, hash that transaction to  get this number, concatenate it with this number, and then take that transaction to get this number concatenate it with  this number and then take the hash to get this number and then concatenate these two numbers  and take the hash again you will be left with the root hash so then the guy goes okay i am satisfied  that this transaction was part of this block at the time of the creation of this block why is he  satisfied because the probability that i am able to give these random numbers in that order to be able to be used with the transaction in order to give the
 root hash is one in two to the power of 256, i.e. zero. Now for illustrative purposes, I’ve only  included four transactions in each block here. Usually we have between one and two thousand  transactions in a block, and so at that scale, you can really start to see  why this is such a powerful tool  in terms of saving disk space.
 So now we can see different people running their nodes  have these different types of blockchains.  They all have the same block header,  but then some people choose to, as they go along,  remove transactions they no longer need.  As you can see, the ones that are closest  to the most present block may look like a full block  because those  transactions haven’t yet been spent whereas blocks from a while back could have literally every  Transaction no longer ever being needed to be referred to and so it can simply store the block header So we have these big brain folks here that know everything these medium sized brain folks here
 They know quite a bit and then we have these peanut sized brain people  They just keep a copy of the block header. So these people who merely keep a copy of the block  header can ask for a proof that a transaction has been accepted. These people here can mine blocks  as well as independently verifying that a transaction has been accepted.
 And then these  people, they are omniscient and they know absolutely everything that’s ever happened  in the Bitcoin blockchain.  They can trace any coin to the origin and any new node that joins the network has to ask these people for the entire history so that they can work through the entire history themselves to  verify every transaction.
 So these peanut-sized brain people, they’re actually the ones who run  the SPV nodes. So let’s walk through an example of some car shop running an SPV node and then this  guy comes up to them says hey  Can I buy a car? This guy says yeah sure. He says can I buy in Bitcoin? He says yeah sure  He says okay  I just sent the transaction and this car the car owner is going to wait until he can get verification or a proof this  Transaction which sends this customers calling over to him is indeed valid and has been accepted by the network.
 So he says to either the medium-sized brain nodes or these big omniscient brain nodes,  hey guys send me a proof that my transaction has been included. Some guy replies he says yeah here’s  a transaction right he says yes that is my transaction. So he says okay so if you just go  and hash that you’ll get a number and he goes yes I’ll get a number.
 If you concatenate it with this  one and then hash it you will get if you concatenate it with this one  and then hash it you will get this number concatenate it with this one and then hash it  and you’ll get the root hash you know the chain of block headers so you know what the root hash is  and I have just given you what is called a Merkle proof that your transaction was indeed included  within this block at the time of creation and so the guy running the SPV node, the peanut sized brain nodes can see, okay,  lots of blocks have been mined on top of this,
 which means it’s extremely likely to be a valid transaction  as basically the entire network has accepted it as valid.  So I am happy.  Up until now, we have been transferring  a single electronic coin, but that is a piss take.  And it gives us yet another pretty diagram which doesn’t  really tell us a lot but basically we can have multiple inputs and always have two outputs the  first output is sent to the receiver and then the second output we’re going to send change back to  ourselves so as far as the bitcoin network is concerned we’re actually sending coins to ourselves
 here which of course is actually valid there’s no need to worry about all these transactions getting all complicated and fanning out everywhere because value is conserved. In each  transaction, if you count the value of all the inputs, they will equal that of the outputs.  Okay, so our transactions so far have just been these three numbers.
 I’m going to slightly  rearrange this transaction here and we’re going to allow for multiple inputs. That is multiple  transaction IDs which refer to different coins. And then we’re going to allow for multiple inputs that is multiple transaction  ids which refer to different coins and then we’re going to have two public keys one is going to be  the guy we’re sending it to and then we’re going to have our own public key send ourselves any  leftover change what’s this signature here it’s the same as before we simply just use our private
 key to sign it okay let’s turn to pictures because they’re always easier to work with any keys with  the silver metal bit they’re ours and any keys with the gold bits, they’re somebody else’s.  Let’s give these transaction IDs different shades of pink just to highlight that they are actually  different and this is our signature down here.
 Let’s say we wanted to send 20 electronic coins  to somebody. We have at our disposal previous transactions in the bitcoin blockchain sending us 11 8 and 4 coins  to our public key as you can see we can’t just have the first two inputs because that would only  add up to 19 and the rule is we have to use the entire value of the transaction output so we have  to include these entire four coins in this transaction that of course adds up to 23 so  we’re going to send three coins back to ourselves.
 So let’s just make this clearer with an illustration of our blockchain once again.  Remember that we have this local transaction ID database stored in our RAM. And so we can use these three transaction IDs and look up where they exist in the blockchain. And so let’s say  after we found them, we go to each individual one. we say this is the output I am referring to, I claim this is my public key.
 But of course, because there’s two outputs, what we really need in our inputs is not only  the transaction ID, but the index of the output within that transaction that we are referring  to.  Now, of course, this gets confusing because we have a blockchain which is composed of  blocks, which is composed of transactions.
 And then those transactions are composed  of transaction inputs,  which are composed of transaction IDs and indexes,  as well as transaction outputs and the signature.  And this could get even more complicated  because we can actually have multi signature transactions,  but this paper does not mention anything about that.  If you want to find out more  about multi signature transactions,  how they made Bitcoin’s lightning network possible, then you know what to do, subscribe.
 Okay so this is our public key we claim we have the private key to and so now we just  check that we can indeed decrypt the signature with this public key which proves that we  were the owners of the previous 11 coins and so this transaction is valid and so we are  allowed to include this transaction input in our transaction.
 So of course we’ll delete this transaction ID  out of our database.  Well, not exactly because a transaction now has two outputs.  And so what we really need is both the transaction ID  as well as the index,  indicating whether it is the first or second  or zeroth or first output in the transaction.  So we’ll actually have two entries for each  transaction id in here nevertheless we delete the output the transaction output that we have just  used up and we do the same for each of the other ones and hopefully they all correspond to the
 public key which is able to decrypt that digital signature and everything goes swimmingly and it’s  accepted if this is getting a bit confusing to understand, imagine you go into a store and the  cashier says that is $1.55 please and you have in your pocket a $1 note and then you have 50 cent  and 10 cent coin.
 What will happen? You can’t just say I’ll split that 10 cent coin in half and give  you five cents. Nope, no, no, no. You send over all of it and then the cashier takes 155 and gives you change of 5 cents and so that’s  how it works in bitcoin now time for a super short section 10 this is all about privacy but this  section is obsolete and i’ll tell you why okay so here it says all the transactions are public  they’re all on a public decentralized ledger but it’s okay because all of our identities are tied  to our public keys so we don’t give our real world identities away so it’s okay because all of our identities are tied to our public keys. So we don’t give our
 real world identities away. So it’s all good. Contrast this with the legacy financial system  where we get our privacy, but at the cost of not having an absolute clue what is going on because  everything is so opaque. But remember that this white paper was written before we had exchanges  like Coinbase.
 So nowadays, if we want to gain access to coins what we’ll do is transfer  money from our bank to an exchange then if we actually control our own keys we will send it to  our public key or bitcoin address which is very similar to a public key but in this video I’m  trying to keep to the white paper as much as possible. So in the early days you could just  get your laptop use your CPU and mine coins directly but of course that is far too expensive now  and so we really don’t have any privacy in the Bitcoin network.
 Now on to section 11. In it Satoshi simulates an attack on the Bitcoin network but he does  so with somebody with less than 50% of CPU power. So we kind of already agree if he has  more than 50% CPU power we’re fucked. If he has less than 50, does it mean he cannot attack the network?  Well, no, that doesn’t have to be the case.
 Just think of an extreme example where we are super, super, super lucky  and we only have to try a few nonces in order that our block has a hash,  which starts with a suitable number of zeros.  We would just keep winning and winning and mining all the blocks.  But what does it actually mean by attack?  Well, here is our blockchain.
 And let’s say we bought our car at this block here. The guy who sold us the car is  gonna say I want to wait for a bit to make sure that transaction is valid and  has gone through and exists in the blockchain. So we could say okay yep fair  enough we can wait but then what we could do is simply go to a block before  that transaction occurred and then just mine our own blocks which includes all  of the valid transactions that were included in these other blocks except one specific transaction  that transaction being the transaction whereby we sent him the bitcoins from our address to his
 address or our public key to his public key so this becomes a race because obviously the main  blockchain is still going to be adding blocks whilst we’re trying to catch up. But notice that if we do catch up at any point, then we will send proof that we  have a valid chain, which is longer than everyone else’s.
 And all of the other nodes are just going  to accept, okay, this is the best, the longest chain, which has the most work invested in it.  And so I’m not actually going to go through this section because it’s purely just a standard  textbook probability example and I’m  not going to explain to everyone what a Poisson distribution is or the gambler’s ruin problem.
 If you have studied any stats or probability in a university or in an American college level,  you will be able to understand this section pretty easily. And it’s not really a blockchain  specific section here, it’s actually just a probability question.  It is worth pointing out some of these results so this Q here this refers to the proportion of hashing power or the CPU power that an attacker has so let’s say he has 10%  and what he’s saying is if we wait for the transaction to be in zero confirmed blocks
 then he can obviously attack us and reclaim the money because he could just send us absolutely anything because no note have confirmed it. If we wait for our transaction to be included in one  block, then he has a 20.5% chance of attacking us and reclaiming his money back. If we wait for,  and this is industry standard, if we wait for our transaction to be included in a block,  which is six blocks deep into the Bitcoin network,  then the chances of him attacking the network is pretty much non-existent. If he had 30% of the hashing power of the network, we can see how it compares. If it’s five blocks deep, there’s still
 a 17.7% chance he can attack. If it’s 10 blocks deep, it’s 4.2%, etc etc etc and finally the shortest section in the history of  sections the conclusion it basically says here’s what we’ve done and feel free to read that yourself  because all he does is tell you what he’s done if you are listening to me now that means you have  watched the entire video which probably means you are interested in learning lots more about  blockchain and so in that case i would highly recommend you subscribe to this channel.
 Have a great day. Ain’t no medicine But ooh, we got cash for NASA  Can’t remember the last time I saw a lunar landing  Maybe that was just a dream

 

 

Read Full Bitcoin Whitepaper

Bitcoin: A Peer-to-Peer Electronic Cash System

author

: Satoshi Nakamoto

email

: [email protected]

site

: http://www.bitcoin.org/

Abstract. A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they\’ll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.

Introduction

Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model. Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible services. With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need. A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party

What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers. In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.

Transactions

We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.

The problem of course is the payee can\’t verify that one of the owners did not double-spend the coin. A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending. After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank.

We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don\’t care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions. In the mint based model, the mint was aware of all transactions and decided which arrived first. To accomplish this without a trusted party, transactions must be publicly announced[^1], and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.

Timestamp Server

The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post[^2][^3][^4][^5]. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.

Proof-of-Work

To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back\’s Hashcash [^6], rather than newspaper or Usenet posts. The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.

For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block\’s hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it

The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.

To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they\’re generated too fast, the difficulty increases.

Network

The steps to run the network are as follows:

  1. New transactions are broadcast to all nodes.
  2. Each node collects new transactions into a block.
  3. Each node works on finding a difficult proof-of-work for its block.
  4. When a node finds a proof-of-work, it broadcasts the block to all nodes.
  5. Nodes accept the block only if all transactions in it are valid and not already spent.
  6. Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.

Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proof-of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.

New transaction broadcasts do not necessarily need to reach all nodes. As long as they reach many nodes, they will get into a block before long. Block broadcasts are also tolerant of dropped messages. If a node does not receive a block, it will request it when it receives the next block and realizes it missed one.

Incentive

By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them. The steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation. In our case, it is CPU time and electricity that is expended.

The incentive can also be funded with transaction fees. If the output value of a transaction is less than its input value, the difference is a transaction fee that is added to the incentive value of the block containing the transaction. Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.

The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.

Reclaiming Disk Space

Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. To facilitate this without breaking the block\’s hash, transactions are hashed in a Merkle Tree[^7][^8][^9], with only the root included in the block\’s hash. Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored.

A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore\’s Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.

Simplified Payment Verification

It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he\’s convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it\’s timestamped in. He can\’t check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.

As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker\’s fabricated transactions for as long as the attacker can continue to overpower the network. One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user\’s software to download the full block and alerted transactions to confirm the inconsistency. Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.

Combining and Splitting Value

Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer. To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.

It should be noted that fan-out, where a transaction depends on several transactions, and those transactions depend on many more, is not a problem here. There is never the need to extract a complete standalone copy of a transaction\’s history.

Privacy

The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party. The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone. This is similar to the level of information released by stock exchanges, where the time and size of individual trades, the \”tape\”, is made public, but without telling who the parties were.

As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.

Calculations

We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker. Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them. An attacker can only try to change one of his own transactions to take back money he recently spent.

The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk. The success event is the honest chain being extended by one block, increasing its lead by +1, and the failure event is the attacker\’s chain being extended by one block, reducing the gap by -1.

The probability of an attacker catching up from a given deficit is analogous to a Gambler\’s Ruin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven. We can calculate the probability he ever reaches breakeven, or that an attacker ever catches up with the honest chain, as follows[^10]:

| p = probability an honest node finds the next block | q = probability the attacker finds the next block | qz = probability the attacker will ever catch up from z blocks behind

$$\begin{aligned} q_z = \begin{cases} 1 & \text{if } p \leqslant q\ \left(q/p\right)^z & \text{if } p > q \end{cases} \end{aligned}$$

Given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases. With the odds against him, if he doesn\’t make a lucky lunge forward early on, his chances become vanishingly small as he falls further behind.

We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can\’t change the transaction. We assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed. The receiver will be alerted when that happens, but the sender hopes it will be too late

The receiver generates a new key pair and gives the public key to the sender shortly before signing. This prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead, then executing the transaction at that moment. Once the transaction is sent, the dishonest sender starts working in secret on a parallel chain containing an alternate version of his transaction.

The recipient waits until the transaction has been added to a block and z blocks have been linked after it. He doesn\’t know the exact amount of progress the attacker has made, but assuming the honest blocks took the average expected time per block, the attacker\’s potential progress will be a Poisson distribution with expected value:

$$\lambda = z \frac{q}{p}$$

To get the probability the attacker could still catch up now, we multiply the Poisson density for each amount of progress he could have made by the probability he could catch up from that point:

$$\begin{aligned} \sum _{k=0}^\infty \frac{\lambda ^k e^{-\lambda}}{k!} \cdot \begin{cases} \left(q/p\right)^{(z-p)} & \text{if } k \leqslant z \ 1 & \text{if } k > z \end{cases} \end{aligned}$$

Rearranging to avoid summing the infinite tail of the distribution…

$$1 – \sum _{k=0}^z \frac{\lambda ^k e^{-\lambda}}{k!} \left(1 – \left(q/p\right)^{(z-k)}\right)$$

Converting to C code…

#include <math.h>
double AttackerSuccessProbability(double q, int z)
{
    double p = 1.0 - q;
    double lambda = z * (q / p);
    double sum = 1.0;
    int i, k;
    for (k = 0; k <= z; k++)
    {
        double poisson = exp(-lambda);
        for (i = 1; i <= k; i++)
            poisson *= lambda / i;
        sum -= poisson * (1 - pow(q / p, z - k));
    }
    return sum;
}

Running some results, we can see the probability drop off exponentially with z.

q=0.1
z=0 P=1.0000000
z=1 P=0.2045873
z=2 P=0.0509779
z=3 P=0.0131722
z=4 P=0.0034552
z=5 P=0.0009137
z=6 P=0.0002428
z=7 P=0.0000647
z=8 P=0.0000173
z=9 P=0.0000046
z=10 P=0.0000012

q=0.3
z=0 P=1.0000000
z=5 P=0.1773523
z=10 P=0.0416605
z=15 P=0.0101008
z=20 P=0.0024804
z=25 P=0.0006132
z=30 P=0.0001522
z=35 P=0.0000379
z=40 P=0.0000095
z=45 P=0.0000024
z=50 P=0.0000006

Solving for P less than 0.1%…

P \< 0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=11
q=0.25 z=15
q=0.30 z=24
q=0.35 z=41
q=0.40 z=89
q=0.45 z=340

Conclusion

We have proposed a system for electronic transactions without relying on trust. We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending. To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power. The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.

References

[^1]: W. Dai, \”b-money,\” http://www.weidai.com/bmoney.txt, 1998.

[^2]: H. Massias, X.S. Avila, and J.-J. Quisquater, \”Design of a secure timestamping service with minimal trust requirements,\” In 20th Symposium on Information Theory in the Benelux, May 1999.

[^3]: S. Haber, W.S. Stornetta, \”How to time-stamp a digital document,\” In Journal of Cryptology, vol 3, no 2, pages 99-111, 1991.

[^4]: D. Bayer, S. Haber, W.S. Stornetta, \”Improving the efficiency and reliability of digital time-stamping,\” In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993.

[^5]: S. Haber, W.S. Stornetta, \”Secure names for bit-strings,\” In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997.

[^6]: A. Back, \”Hashcash – a denial of service counter-measure,\” http://www.hashcash.org/papers/hashcash.pdf, 2002.

[^7]: R.C. Merkle, \”Protocols for public key cryptosystems,\” In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, April 1980.

[^8]: H. Massias, X.S. Avila, and J.-J. Quisquater, \”Design of a secure timestamping service with minimal trust requirements,\” In 20th Symposium on Information Theory in the Benelux, May 1999.

[^9]: S. Haber, W.S. Stornetta, \”Secure names for bit-strings,\” In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997.

[^10]: W. Feller, \”An introduction to probability theory and its applications,\” 1957.