The Bitcoin Whitepaper is a very short paper, only 12 short paragraphs. Published by Satoshi Nakamoto on October 31, 2008. The ideas contained in it later developed into blockchain. The whitepaper is definitely worth reading - it’s a classic among classics in this field. This note starts from the perspective of the Bitcoin whitepaper and adds some understanding of implementation details related to the Bitcoin network.
1. Principles of Bitcoin and Blockchain
The goal of the Bitcoin solution is to implement peer-to-peer electronic cash, allowing online payments to be sent directly from one party to another without financial institutions as intermediaries.
It needs to solve several problems in a peer-to-peer network, decentralized environment:
- How to determine whose electronic cash is? You can only spend your own money, not others'.
- How to prevent double spending (the Double Spending mentioned above)? Your money can only be spent once; you can’t initiate two transactions at the same time while bookkeeping isn’t completed to spend the same money twice.
- How to issue currency and drive the network to operate spontaneously?
These problems are easily solved when financial institutions act as intermediaries:
- Banks open accounts for customers, record how much money each customer has, and provide payment passwords. Customers authenticate with their passwords at the bank; after proving identity, they can pay all or part of the amount.
- When spending money, the bank updates the customer’s account balance in real time. As it decreases, there’s no possibility of spending money twice.
- Currency issuance and entire system operation are through financial institutions.
In the Bitcoin system:
- For the first problem, traditional asymmetric encryption mechanism is used. Each account in the Bitcoin system is associated with a public key; users sign their transactions with private keys. The system determines transaction legitimacy by verifying the digital signature.
- For the second problem, Bitcoin system proposes a new method. Pack transactions into blocks, hash them, and link blocks into a distributed continuously growing chain structure based on the hash. The chain structure allows everyone to reach consensus on the transaction sequence in the ledger (forming a Single Source of Truth). If a previous transaction has already spent money, a subsequent transaction trying to spend the same money cannot be recognized by everyone and cannot form consensus on the chain. This mechanism was first proposed in the Bitcoin whitepaper and later called blockchain. Block packaging and chaining work is done through distributed competition among all participants; Bitcoin uses POW (Proof of Work) as the consensus algorithm. For POW, there’s detailed explanation in the mining section below.
- For the third problem, currency issuance and entire transaction system operation are driven by miners’ mining behavior.
Bitcoin uses a public-private key system to solve user authentication. This solution has strong privacy protection capabilities. An extreme example: a person can generate a pair of public-private keys in a small dark room, completely offline, using pen and paper, then derive a Bitcoin address from the public key. As long as this address (e.g., 1J7mdg5rbQyUHENYdx39AWISME7fsLpEoXZy) is published, they can receive payments. After receiving, only the person in the small dark room can operate that money on the blockchain (because only they have the private key corresponding to that Bitcoin account). If deliberately concealed, money on the Bitcoin network is hard to trace to the corresponding person. Of course, privacy may be compromised during Bitcoin and fiat currency conversion.
The above image illustrates Bitcoin’s blockchain. In Block 2’s header, it stores the hash of Block 1’s header. The hash acts like a parent node pointer in a linked list. Based on the sequence of being added to the chain, transactions in Block 2 are later than those in Block 1, transactions in Block 3 are later than those in Block 2. Each block records transactions in the block body; a hash of all transactions in the block body is also made and stored in the block header (in the Merkle Root field).
Through the blockchain, transaction sequence is guaranteed, and transactions that have formed consensus on the blockchain cannot be tampered with (because transaction hashes are also stored in the block header; changing transaction content would cause the Merkle Root hash in the header to not match; if you also change the Merkle Root value, it would cause the block header hash to change, and the changed block header hash would cause the block to be removed from the linked list).
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. — Bitcoin Whitepaper
That’s the theory. Below are implementation details.
2. How Does the Bitcoin Network Operate?
The steps to run the network are as follows:
- New transactions are broadcast to all nodes.
- Each node collects new transactions into a block.
- Each node works on finding a difficult 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 hash of the accepted block as the previous hash. —- Bitcoin Whitepaper
2.1. Users Initiate Transactions
When a user initiates a transfer transaction, they pack their public key, destination account address, amount, etc., and sign it. This creates a packaged transaction. This transaction is then broadcast to a mempool.
The above shows changes in the number of real-time pending transactions in the global mempool.
In reference material 2, you can view the current mempool situation on the Bitcoin network in real time. You can also view details of all on-chain blocks and all pending transactions.
2.2. Miners Record Transactions
Transactions in the mempool can be freely selected by each Bitcoin miner to include in a block for packaging. When selecting, they need to verify transaction legitimacy (whether the sender has enough coins, whether the signature is correct, etc.). Miners also select transactions based on transaction fees (customers giving higher tips get served first). After filling their block, miners start mining (calculating hash). Mining uses brute force, constantly trying to adjust the Nonce in the block header, then hash the block header and check if the resulting hash meets requirements.
The system has requirements for the block header hash (e.g., requiring several consecutive zeros at the beginning). Everyone competes; whoever finds a qualifying hash first gets their block added to the chain tail.
The difficulty is adjusted to probabilistically control how long it takes for the entire network to mine a block. Difficulty is proportional to the expected number of attempts needed to find a qualifying hash. Bitcoin system sets one block every 10 minutes; if blocks are being produced too fast, difficulty increases, and vice versa.
All miners select, package, and hash from transactions in the mempool. When a miner successfully finds a Nonce value (making the current attempt’s block header hash meet requirements), they immediately broadcast the block to the entire network. Other miners, upon receiving the new block, verify it (checking if transactions in the block are all valid, there’s no double spending, also checking block Merkle Root and other data). If valid, they add it to the end of the blockchain. At the same time, they abandon their current block that’s being calculated but not yet complete, and start calculating the next block for the next round of proof-of-work competition.
- Miners add a transaction in the block they mine. It’s the mining income (coinbase). Each block’s reward was initially 50 Bitcoin, halving every 4 years. Currently it’s 6.25 Bitcoin. In Bitcoin blockchain transactions, only mining income has no address source; there’s exactly one mining income transaction per block. Essentially, all Bitcoin’s most original source is mining income. Mining is currency issuance.
- Because there’s a coinbase transaction in the block, after miners find a qualifying Nonce, they can safely broadcast the block. Other miners cannot plagiarize it.
3. Main Data Structures
Bitcoin system’s data structure is relatively simple; data passed between nodes is blocks. The structure of each block is as shown above. Blocks include Header and Body. Header contains:
- Prev Block: Hash of the previous block, used to link different blocks.
- Merkle Root: Hash of all transactions in the block. Used to ensure block body content isn’t modified.
- Time: Unix timestamp.
- Bits: Difficulty coefficient, used to control expected number of attempts needed to get target hash.
- Nonce: Random number, adjusted during mining to get different hash values.
Body contains transactions. Each black or green horizontal bar in the above image represents a transaction. The green one is the mining income transaction.
Note: The system uses Merkle Tree to hash all transactions in the block body. Unlike regular hash algorithms like MD5, SHA256, etc., Merkle Tree can verify if a transaction is in the block without knowing all block body information.
Bitcoin blockchain is a distributed database; its data is a one-way linked list composed of these blocks. Each node can save all these block data to get the entire Bitcoin blockchain state. The current state of the Bitcoin network is the balance corresponding to each address.
Transactions recorded in the blockchain are similar to Redis AOF files or database binlog files. They record one transaction at a time. They don’t record state. State is obtained by replaying transactions.
All Bitcoin transactions can also be logically串联 across blocks through account addresses. The root node is the miner reward transaction. Leaf nodes, also called UTXO (Unspent Transaction Output). Intermediate non-root non-leaf accounts represent money they once owned. This allows tracking funds through transactions. This is one of Bitcoin’s typical characteristics.
To calculate how much Bitcoin is in a wallet, look at which UTXO addresses the wallet’s Bitcoin addresses have, and sum the Bitcoin in those addresses.
4. Other
4.1. POW Computing Power and 51% Attack
What happens when malicious attackers appear on the Bitcoin network? Since Bitcoin’s cryptographic foundation is very secure, attackers choose to attack parts not directly protected by cryptography: transaction order. The attacker’s strategy is simple:
- Send 100 BTC to a seller to buy goods (especially digital goods that don’t need shipping).
- Wait until the goods are shipped.
- Create another transaction, sending the same 100 BTC to their own account.
- Make the Bitcoin network believe the transaction sending to their own account was the first one sent.
Once (1) happens, after a few minutes, miners will pack this transaction into a block, let’s say block #270000. About an hour later, there will be five blocks after this block, each indirectly pointing to this transaction, confirming it. At this point, the seller receives payment and ships to the buyer. Since we assume it’s a digital good, the attacker can receive the goods immediately. Now the attacker creates another transaction sending the same 100 BTC to their account. If the attacker just broadcasts this message to the entire network, this transaction won’t be processed. Miners will run the state transition function APPLY(S,TX) and find this transaction spends a UTXO that’s no longer in the state. So, the attacker forks the blockchain, uses block #269999 as parent to regenerate block #270000, replacing the old transaction with the new one in this block. Because block data is different, this requires redoing proof of work. Also, because the attacker’s new block #270000 has a different hash, the original blocks #270001-#270005 don’t point to it, so the original blockchain and attacker’s new block are completely separate. When a fork happens, the longer blockchain branch is considered the honest one. Legitimate miners will mine after original block #270005; only the attacker mines after the new block #270000. For the attacker to have the longest blockchain, they need more computing power than the rest of the network combined (i.e., 51% attack).
4.2. Byzantine Generals Problem
This story is about a group of generals besieging Byzantium (Istanbul). Byzantium is powerful; it can only be captured if all forces attack, otherwise attacking troops will be destroyed. The generals agree to follow the majority - either all attack or retreat together. But the generals are scattered around the city, with poor communication. Among the generals are traitors who will send different false messages to different generals, causing inconsistent actions.
Modern distributed systems have similar problems - multiple server nodes on the network collaborate and ultimately need to jointly maintain a set of data. There’s no way to guarantee node honesty (a dishonest node sends different information to other nodes), nor guarantee internal system information consistency; nodes have no way to judge information authenticity.
The Bitcoin system’s solution based on POW: view generals as miners. Assuming each team has equal computing power, then within every 10 minutes, one general gets a chance to speak (tell others whether to attack or retreat). After several 10-minute periods, all generals’ messages form a blockchain. The blockchain mechanism ensures each general can express exactly once (otherwise double spending). Generals can reach consensus through this mechanism.
4.3. Full Nodes, Light Nodes, SPV Nodes
Initially in the Bitcoin network, all nodes processed all blocks and stored all data. Later, as network scale expanded, node processing and storage capabilities continuously demanded new requirements. Light nodes and SPV nodes emerged.
- Full nodes are nodes that maintain complete blockchains with all transaction information. Full nodes can verify transaction legitimacy.
- Light nodes: Nodes only locally save transaction data related to themselves (especially spendable transaction data). Light nodes also process all blocks but don’t need to save all blockchain information.
- SPV nodes: Nodes that can only verify whether a payment is real and how many confirmations it has.
SPV nodes don’t need local blockchain data to verify transactions succeeded. Verification method:
- Calculate the transaction hash of the payment to verify;
- Node obtains and stores all block headers of the longest chain locally from the network;
- Node obtains the Merkle tree hash authentication path corresponding to the payment from the blockchain;
- Based on the hash authentication path, calculate the Merkle tree root hash, compare with the local block header’s Merkle root, locate the block containing the payment;
- Based on the block header’s position, verify whether it’s in the known longest chain, determine how many confirmations the payment has; if included, prove payment is valid.
Generally, mobile wallets and other devices with limited computing resources can act as SPV nodes. When someone transfers money to you, you only need to know if the transaction is on the chain and if there are enough blocks following to ensure the transaction succeeds.
4.4. Bitcoin Network Processing Capacity
Bitcoin network’s TPS (transactions per second) is about 5. This value can be calculated from three parameters:
- One block every 10 minutes;
- Block size;
- Average transaction size.
5 TPS is a relatively small number (compare to VISA network, which processes thousands of transactions per second). Methods to improve throughput include shortening block production time, increasing block size, etc. There are also solutions using sidechains or off-chain transactions (e.g., Lightning Network) to address throughput.
4.5. Soft Fork and Hard Fork
Forks occur due to changes in consensus rules. New consensus rules may be a superset, intersection, or subset of the original rules.
- The definition of a hard fork is to expand consensus rules, allowing something that was previously prohibited (superset or intersection case). Previously invalid transactions/blocks become valid after a hard fork.
- A soft fork is to tighten consensus rules, prohibiting something that was previously allowed (subset case). Previously valid transactions may become invalid after a soft fork.
After a fork, some nodes in the network upgrade to support new rules.
- In a soft fork scenario, blocks produced by new rules will also be recognized by old nodes (that haven’t upgraded).
- in a hard fork scenario, blocks produced by new rules may be considered illegal by old nodes. It will fork into two chains with no intersection, developing along their own paths.
If you held tokens before the fork, after a hard fork, tokens become two copies, usable on both the old and new blockchains. The reason for this phenomenon is that after a hard fork, it becomes two networks. Transactions in one network only cause state changes in that network (the current state of the network, defined by the last block in the blockchain).
Whether soft fork or hard fork, the new version of software must be able to correctly handle old block data produced by the old version of software.