My Notes From The Satoshi Nakamoto Bitcoin WhitePaper 1

Bitcoin has been pretty crazy lately, at the weekend even my Mum asked me about the decentralised cryptocurrency. Anyway, it got me thinking about the origins, and how it all began. So i turned to the bitcoin whitepaper – Bitcoin: A Peer-to-Peer Electronic Cash System – published 9 years ago by Satoshi Nakamoto in November 2008. For this post, i read through the whitepaper and made some notes.

Who is Satoshi Nakamoto?

In short, nobody really knows! Satoshi has opted to keep his – if he is a male, or if he is indeed even one person – identity a secret. There is widespread speculation about Satoshi Nakamoto’s identity, but for now let’s just settle on – we don’t know!

While his identity is interesting, it is Satoshi’s idea’s that are revolutionary…

Bitcoin: A Peer-to-Peer Electronic Cash System

The Bitcoin whitepaper is 9 pages long and consists of an Abstract and 12 sections. While i have read many articles about Bitcoin (see references below), for the purposes of this post i refer to the whitepaper “Bitcoin: A Peer-to-Peer Electronic Cash System” only:

Bitcoin Whitepaper: ABSTRACT –

Satoshi Nakamoto outlines:

• The Problem:
  • There is no way of making peer-to-peer payments online that bypass financial institutions. Some solutions exist that utilise digital signatures, but these require a trusted third party to ensure that the digital value is not spent more than once (double spending)
• The Solution:
  • A pure peer-to-peer network that hashes transactions, using cryptography, into a chain of hash-based proof-of-work records
  • The chain provides proof of the chronological sequence of transactions and the verification from “honest” nodes that collectively control the largest pool of CPU power

1. Bitcoin Whitepaper: INTRODUCTION –

Satoshi speaks about the inefficiencies of commerce on the internet:

• Reliance on financial institutions
• The need for trusted parties to process payments
• Non-reversible transactions which in turn increase transaction costs and further accentuate the need for trusted and centralised third parties
• An acceptance that some fraud is inevitable

The need for a electronic payment system that:

• Uses cryptographic proof rather than trust
• Enables parties to transaction directly with one another bypassing any central or trusted third party
• Protects individuals from fraud

2. Bitcoin Whitepaper: TRANSACTIONS –

This is where it gets interesting. Satoshi explains that:

• Bitcoin is a chain of digital signatures
• Every owner of an electronic coin passes it to the next owner by digitally signing:
  • A hash of the previous transaction
  • The public key of the new owner
  • Adding the above 2 components to the end of the electronic coin
• The new owner is in turn able to verify the signatures which in turn allows him/her to verify the ownership of the electronic coin
• In order to achieve the above without a trusted third party requires that the transactions are:
  • Declared publicly
  • Confirmed through a system whereby all participants (nodes) agree the history and order in which the transaction was received

3. Bitcoin Whitepaper: TIMESTAMP SERVER –

• The timestamp server is software takes the hash of a block of items timestamps them and publicly publishes the hash.
• Each timestamp includes the previous timestamp, creating a chain, and as new timestamp hashes are added the chronological order and links are strengthened

4. Bitcoin Whitepaper: PROOF OF WORK –

Satoshi explains that implementing a distributed time-stamp server requires a proof-of-work system. Proof of work:

• Requires scanning for a value, using an algorithm, which when hashed the hash value starts with a number of zero-bits
• Consists of a verification process which requires significant CPU effort
• Ensures that a verified block cannot be changed because all later blocks that are chained to it will also need to be changed (each subsequent block would need to be verified, requiring increasing CPU)
• Is based on a one-CPU-one-vote system, ensuring that the majority decision is based on the longest chain which requires the most proof-of-work effort
  • Note: the system is not based on a one-IP-address-one-vote since the network could be undermined by somebody who is able to allocate many IPs

5. Bitcoin Whitepaper: NETWORK –

In order to run a network, the following process repeats:

• New transactions must be transmitted to all nodes
• Each node gathers each transaction into a block
• Each node works on a proof-of-work process for each block
• Once the node finds a proof-of-work, this is broadcast to all nodes in the network
• Nodes accept the block if all the transactions within it are valid and not already spent
• Nodes “approve” the block by working on the next block in the chain, using the hash of the approved block as the previous hash from which they can then build the next block
  • As a result, nodes continue to work on the longest chain, which is always the correct one

6. Bitcoin Whitepaper: INCENTIVE –

• The goal in the peer to peer electronic cash system is to encourage nodes to connect to the network and validate transactions
• The first block in a transaction starts a new coin which is owned by the creator of the block
• In order to generate new blocks, and therefore coins (value), CPU and electricity are needed
• If the output of a transaction is less than the input value, a transaction fee is added to the block containing the transaction

7. Bitcoin Whitepaper: RECLAIMING DISK SPACE –

• Any old transactions can be removed to save disk space
• To enable this removal without breaking the block hash value, transactions are hashed in a Merkle Tree
• This allows for old blocks to be consolidated by essentially removing the tree branches, but keeping the root

8. Bitcoin Whitepaper: SIMPLIFIED PAYMENT VERIFICATION –

Payment verification is possible without running a full network node by:

• Getting a copy of the block headers of the longest proof-of-work chain…
• Retrieved by reaching out to the network nodes…
• Verifying independently that you have the longest chain….
• Getting the Merkle branch linking the transaction to the block its timestamped in
• Linking the transaction to the chain
• If the network accepts the transaction, blocks will be added after it

This is fine if the network consists of honest nodes, but is vulnerable to bad transactions that an attacker may create.

9. Bitcoin Whitepaper: COMBINING AND SPLITTING VALUE –

To allow value to be divided and merged, transactions contain various inputs and outputs. For example a single input from a large transaction, or many smaller inputs.

10. Bitcoin Whitepaper: PRIVACY –

Traditional banking limits access to information to just those involved in the transaction and the trusted third party. This is not workable in a model where the transactions are broadcast publicly, but the need for privacy is still important. Privacy is maintained by keeping public keys anonymous. A transfer can happen without knowing who is involved in the transaction.

11. Bitcoin Whitepaper: CALCULATIONS –

Calculations is the longest section in the whitepaper, just over 2 of the 9 pages. In this section the paper considers a scenario where bad actors in the system try to generate an alternative chain faster than the honest chain. In this scenario there is a race between the honest chain and an attacker (bad) chain, and the section steps through the mathematical probability that the attacker chain can catch up with the honest chain.

In short, the section highlights mathematically that the odds are against the attacker chain unless he/she gets lucky!

12. Bitcoin Whitepaper:  CONCLUSION –

The paper concludes:

• Where honest nodes control the majority of CPU power, a peer-to-peer network that uses proof-of-work to record public transactions makes it computationally impractical for attackers to tamper with
• The network strength lies in its unstructured simplicity
• Nodes working independently with little coordination.
• Nodes can leave/rejoin the network as they wish, relying on the proof-of-work chain as proof of what happened while they were gone
• Nodes vote with their CPU power, acceptance of a block is recognised by working to extend it. Rejection of invalid blocks is highlighted by refusing to work on them.
• Any required rules and incentives are enforced through the consensus mechanism

Reference:

• P2P Foundation: Bitcoin open source implementation of P2P currency
• Steemit: Bitcoin White Paper explained… (Bitcoin made easy)
• Coindesk: Bitcoin: A 21st Century Currency Explained By a Wall Street Veteran