A whitepaper serves as a foundational document, communicating the core ideas and technical workings of a project or technology. It provides deep insight into the conceptual framework and operational mechanics. In this article, we explore the translated content of the original Bitcoin whitepaper, authored by Satoshi Nakamoto in 2008, which outlines the purpose and functionality of Bitcoin. While some concepts may be complex, this guide aims to offer a clear understanding of Bitcoin’s origins and principles.
Key Terminology to Know
- Peer-to-Peer (P2P): A decentralized network where participants interact directly without intermediaries, similar to BitTorrent.
- Digital Signature: A cryptographic method used to verify the authenticity and origin of data, akin to a signature on a legal document.
- Hash: A cryptographic function that converts data into a fixed-length string, making it difficult to reverse-engineer the original input.
- Node: A computer participating in the network.
- Best Effort: A data transmission method that does not guarantee delivery.
- Trust: Reliability or credibility, often referring to financial trust in centralized systems.
- Double Spending: The risk of spending the same digital currency unit more than once.
- Cryptographic: Relating to encryption techniques, such as public-key cryptography, which enables secure data exchange.
- Mint: A central authority that issues currency.
- Block: A container that records transactions.
- Attacker: A malicious actor attempting to defraud or manipulate the system.
- Consensus: General agreement among network participants.
- Proof-of-Work (PoW): A consensus mechanism that requires computational effort to solve cryptographic puzzles, securing the network.
Introduction: The Need for a Decentralized System
Traditional online commerce relies heavily on financial institutions as trusted third parties to process electronic payments. While this system works adequately for most transactions, it has inherent weaknesses. The reliance on trust introduces the possibility of disputes, reversals, and fraudulent chargebacks. Mediated transactions also incur additional costs, limiting the feasibility of small-value payments.
Moreover, the inability to make irreversible payments constrains commercial freedom. What is needed is an electronic payment system based on cryptographic proof rather than trust, allowing any two willing parties to transact directly without a third party. This system would protect sellers from fraud and enable automated escrow mechanisms for buyer protection.
This document proposes a solution to the double-spending problem using a peer-to-peer distributed timestamp server. Transactions are timestamped, hashed, and recorded into an ongoing chain of proof-of-work-based blocks. The longest chain serves as proof of the consensus of the greatest computational effort. As long as the majority of the CPU power is controlled by honest nodes, they will generate the longest chain and outpace any attackers.
How Transactions Work
An electronic coin can be defined 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. The recipient can verify the signatures to confirm the chain of ownership.
The challenge lies in preventing double-spending. The typical solution involves a trusted central authority (or mint) that checks every transaction for duplication. However, this approach centralizes power and requires all transactions to go through the mint.
The proposed system makes transactions publicly announced [1], and participants agree on the order of transactions. The majority decision is represented by the longest chain, which has required the most computational effort to produce.
The Role of the Timestamp Server
A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash. Each timestamp includes the previous timestamp in its hash, forming a chain that reinforces the previous ones.
Proof-of-Work Explained
To implement a distributed timestamp server on a peer-to-peer basis, Bitcoin uses a proof-of-work system similar to Adam Back’s Hashcash [6]. The proof-of-work involves scanning for a value that, when hashed (e.g., with SHA-256), the hash begins with a certain number of zero bits.
The average work required is exponential to the number of zero bits required. For the timestamp network, the proof-of-work is implemented 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 the block 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.
Network Operation Steps
The network executes the following steps:
- New transactions are broadcast to all nodes.
- Each node collects new transactions into a block.
- Each node works on finding a proof-of-work for its block.
- When a node finds a proof-of-work, it broadcasts the block to all nodes.
- Nodes accept the block only if all transactions in it are valid and not already spent.
- Nodes express their acceptance of the block by working on creating the next block in the chain, using the accepted block’s hash as the previous hash.
Nodes always consider the longest chain to be the correct one and will continue to extend 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; nodes then switch to the longer chain.
Incentives and Rewards
The first transaction in a block is a special transaction that creates new coins 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 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 inflation-free.
Incentives encourage nodes to remain honest. If an attacker with more CPU power than all honest nodes were to arise, they would have to choose between using that power to defraud people by stealing back their payments or using it to generate new coins. They ought to find it more profitable to play by the rules and generate new coins.
Efficient Use of 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], with only the root included in the block’s hash. Old blocks can then be compacted by stubbing off branches of the tree. The internal hashes do not need to be stored.
A block header with no transactions would be about 80 bytes. If 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 they can get by querying network nodes until they are convinced they have the longest chain, and obtain the Merkle branch linking the transaction to the block it’s timestamped in.
They can’t check the transaction for themselves, but by seeing it embedded in the chain, they 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 as long as the attacker can continue to overpower the network. One strategy to protect against this is 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 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.
Privacy Considerations
The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted intermediary. Bitcoin transactions are publicly announced, so privacy is maintained 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.
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.
Security Calculations
The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes. Attackers’ ability to rewrite transaction history is limited by the computational power required to outpace the honest chain.
The probability of an attacker catching up from a given deficit is analogous to a Gambler’s Ruin problem. Assuming a honest node has a head start, the probability decreases exponentially as the number of blocks the attacker must catch up increases.
👉 Explore advanced security methodologies
Conclusion
We have proposed a system for electronic transactions without relying on trust. We started with the framework of 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.
Frequently Asked Questions
What is the main goal of the Bitcoin whitepaper?
The Bitcoin whitepaper aims to introduce a peer-to-peer electronic cash system that enables online payments to be sent directly from one party to another without going through a financial institution. It solves the double-spending problem using a decentralized network and cryptographic proof.
How does proof-of-work secure the Bitcoin network?
Proof-of-work requires participants to expend computational effort to solve complex mathematical problems. This process secures the network by making it economically and computationally infeasible for attackers to alter transaction history, as doing so would require outperforming the entire network’s computational power.
What is double-spending and how does Bitcoin prevent it?
Double-spending occurs when the same digital token is spent more than once. Bitcoin prevents it by timestamping transactions and embedding them in a proof-of-work-based chain. Consensus rules ensure that only the first instance of a transaction is accepted by the network.
Can Bitcoin transactions remain private?
While all transactions are publicly recorded on the blockchain, privacy is maintained through pseudonymous public keys. Users can generate new key pairs for each transaction to avoid linking their identities to multiple transactions.
What incentives do nodes have to participate in the network?
Nodes are incentivized by block rewards (newly minted bitcoins) and transaction fees. This encourages them to contribute computational resources to secure the network and validate transactions.
How does the network handle conflicting transactions?
Nodes always adopt the longest valid chain of blocks, which represents the greatest cumulative proof-of-work. Conflicting transactions are resolved through this consensus mechanism, ensuring all participants agree on the state of the ledger.