Bitcoin White Paper: A Peer-to-Peer Cash System
PANews Editor's Note: On October 31, 2008, Satoshi Nakamoto published the Bitcoin white paper, and today marks its 17th anniversary. The following is a translation of the white paper by Li Xiaolai, for everyone to revisit this classic work. Summary: 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. While digital signatures offer a partial solution, the main advantage of electronic payments is negated if a trusted third party is still required to prevent double-spending. We propose a scheme using a peer-to-peer network to address the double-spending problem. The peer-to-peer network timestamps each transaction by recording the transaction's hash data onto a continuously expanding, hash-based proof-of-work chain, forming a record that cannot be altered unless completely rewritten. The longest chain serves two purposes: proving witnessed events and their order, and simultaneously proving it originated from the largest pool of CPU power. As long as the vast majority of CPU power is controlled by benign nodes—that is, nodes that do not cooperate with those attempting to attack the network—benign nodes will generate the longest chain and outpace attackers. The network itself requires a minimal structure. Information will propagate on a best-effort basis, and nodes are free to come and go; however, upon joining, they must always accept the longest proof-of-work chain as proof of everything that happened during their absence. 1. Introduction Internet commerce relies almost entirely on financial institutions as trusted third parties to process electronic payments. While this system works reasonably well for most transactions, it is still hampered by the inherent flaws of its trust-based model. Completely irreversible transactions are practically impossible because financial institutions cannot avoid arbitrating disputes. Arbitration costs increase transaction costs, which in turn limit the minimum possible transaction size and effectively prevent many small payments. Beyond this, there are even greater costs: the system cannot provide irreversible payments for irreversible services. The possibility of reversibility creates an omnipresent need for trust. Merchants must be wary of their customers, requiring them to provide additional information that would otherwise be unnecessary (if trusted). A certain percentage of fraud is considered unavoidable. These costs and payment uncertainties, while avoidable when paying with physical currency directly between people, lack any mechanism that allows payments to be made through communication channels when one party is not trusted. What we truly need is an electronic payment system based on cryptographic proofs rather than trust, allowing any two parties to transact directly without needing to trust a third party. Irreversible transactions guaranteed by computational power help sellers avoid fraud, while everyday guarantee mechanisms to protect buyers are easily implemented. In this paper, we propose a solution to double-spending by using peer-to-peer, distributed timestamping servers to generate computational power-based proofs, recording each transaction chronologically. This system is secure as long as honest nodes collectively possess more CPU power than colluding attackers. 2. Transactions We define an electronic coin as a digital signature chain. When an owner transfers a coin to another person, they append the following digital signature to the end of this chain: the hash of the previous transaction and the new owner's public key. The recipient can verify ownership of the digital signature chain by verifying the signature. The problem with this approach is that the recipient cannot verify that none of the previous owners have double-spended the currency. A common solution is to introduce a trusted centralized authority, or "mint," to check every transaction for double-spending. After each transaction, the coin must return to the mint, which then issues a new coin. Thus, only coins directly issued by the mint are considered trustworthy and free from double-spending. The problem with this solution is that the fate of the entire monetary system is tied to the company operating the mint (much like a bank), and every transaction must go through it. We need a way for the recipient to confirm that the previous owner did not sign any previous transactions. For our purposes, only the earliest transaction counts, so we are not concerned with subsequent double-spending attempts. The only way to confirm the non-existence of a transaction is to know all transactions. In the mint model, the mint already knows all transactions and can confirm their order. To accomplish this without the involvement of a "trusted party," the transaction record must be publicly announced, thus requiring a system that allows participants to agree on the same unique transaction history they receive. The recipient needs to prove that at the time each transaction occurs, a majority of nodes agree that it was the first one received. 3. Timestamp Server This solution begins with a timestamp server. A timestamp server works by timestamping the hash of a block of items and then broadcasting the hash, much like a newspaper does or a post in a Usenet newsgroup [2-5]. Clearly, the timestamp proves that the data existed before that point in time; otherwise, the hash couldn't be generated. Each timestamp contains previous timestamps in its hash, thus forming a chain; each new timestamp is added after the previous ones. 4. Proof of Work To implement a peer-to-peer distributed timestamp server, we need a proof-of-work system similar to Adam Burke's HashCash, rather than something like a newspaper or newsgroup post. Proof-of-work involves finding a value that meets the following condition: after hashing it—for example, using SHA-256—the hash must begin with a certain number of zeros. Each additional zero increases the workload exponentially, while verifying this workload only requires calculating a single hash. In our timestamp network, we implement proof-of-work as follows: A random number is continuously added to each block until a value that meets a condition is found: the block's hash begins with a specified number of zeros. Once the CPU's computational power yields a result that satisfies the proof-of-work, the block can no longer be modified unless all previous work is redone. As new blocks are continuously added, modifying the current block means redoing the work for all subsequent blocks. Proof-of-Work (PoL) also solves the problem of determining who represents the majority in making decisions. If the so-called "majority" is determined by a "one IP address, one vote" system, then anyone who can control a large number of IP addresses could be considered part of the "majority." PoL, in essence, is "one CPU, one vote." The so-called "majority decision" is represented by the longest chain, because it's the chain with the most work invested. If the majority of CPU power is controlled by honest nodes, then the honest chain grows the fastest, far outpacing other competing chains. To change an already generated block, an attacker would have to re-complete the proof-of-work for that block and all subsequent blocks, and then catch up with and surpass the work done by the honest nodes. The following section explains why the probability of a delayed attacker catching up decreases exponentially with the number of blocks. To cope with the continuous increase in overall hardware computing power and the potential changes in the number of participating nodes over time, the proof-of-work difficulty is determined by a moving average based on the average number of blocks generated per hour. If blocks are generated too quickly, the difficulty will increase. 5. Network The steps to run a network are as follows: All new transactions are broadcast to all nodes; Each node packages new transactions into a block; Each node begins by finding a challenging proof-of-work for this block; When a block finds its proof of work, it must broadcast this block to all nodes; Many other nodes will accept a block if and only if all of the following conditions are met: all transactions in the block are valid and have not been double-spended; The way numerous nodes indicate to the network that they accept a block is to use the hash of the accepted block as the hash of the previous block when creating the next block. Nodes consistently recognize the longest chain as correct and continuously add new data to it. If two nodes simultaneously broadcast two different versions of the "next block," some nodes will receive one first, while others will receive the other. In this case, nodes will continue working on the block they received first, but will also save the other branch in case the latter becomes the longest chain. When the next proof-of-work is found, and one of the branches becomes the longer chain, this temporary divergence is resolved, and the nodes working on the other branch will switch to the longer chain. New transactions don't necessarily need to be broadcast to all nodes. Once they reach enough nodes, they will soon be packaged into a block. Block broadcasting also allows some messages to be dropped. If a node doesn't receive a block, it will realize it missed the previous block when it receives the next block, and will therefore issue a request to resubmit the missing block. 6. Incentive As agreed, the first transaction of each block is a special transaction that generates a new coin, owned by the block's creator. This rewards nodes that support the network and provides a way to issue coins into circulation—in this system, there's no centralized authority issuing those coins. This steady increase in the number of new coins entering circulation is analogous to gold miners continuously consuming their resources to add gold to the system. In our system, the resources consumed are CPU time and the electricity they use. Rewards can also come from transaction fees. If the output value of a transaction is less than its input value, the difference is the transaction fee; this fee is used to reward nodes for including the transaction in the block. Once a predetermined number of coins are in circulation, the rewards will be entirely distributed through transaction fees, and there will be absolutely no inflation. The reward mechanism may also incentivize nodes to remain honest. If a greedy attacker manages to acquire more CPU power than all honest nodes combined, he must choose: use that power to cheat others by stealing back the money he's spent, or use it to generate new coins? He should be able to see that following the rules is more advantageous; the current rules allow him to acquire more coins than all the others combined, which is clearly more profitable than secretly destroying the system and losing his wealth. 7. Reclaiming Disk Space If a coin's most recent transaction occurred a sufficient number of blocks ago, then all previous transactions involving that coin can be discarded—this is to save disk space. To achieve this without corrupting the block's hash, the transaction hashes are incorporated into a Merkle tree [7, 2, 5], with only the root of the tree included in the block's hash. By pruning the branches, older blocks can be compressed. The internal hashes do not need to be preserved. A block header without any transactions is approximately 80 bytes. Assuming a block is generated every ten minutes, 80 bytes multiplied by 6, 24, and 365 equals 4.2 MB per year. As of 2008, most computers on the market had 2GB of RAM, and according to Moore's Law, this would increase by 1.2 GB per year, so even if block headers had to be stored in memory, it wouldn't be a problem. 8. Simplified Payment Verification Payment confirmation is possible even without running a full network node. A user only needs a copy of the block header from the longest chain with proof-of-work—which they can verify by checking online nodes to confirm it comes from the longest chain—and then obtains the branch node of the Merkle tree, connecting to the transaction at the time the block was timestamped. The user cannot check the transaction themselves, but by connecting to somewhere on the chain, they can see that a network node has accepted the transaction, and subsequent blocks further confirm that the network has accepted it. As long as honest nodes retain control of the network, verification remains reliable. However, verification becomes less reliable if the network is controlled by an attacker. Although network nodes can verify transaction records themselves, simplified verification methods can be fooled by forged transaction records if an attacker maintains control of the network. One countermeasure is for client software to receive alerts from network nodes. When a network node discovers an invalid block, it issues an alert, displays a notification on the user's software, instructs the user to download the complete block, and warns the user to confirm transaction consistency. Merchants with high-frequency transactions should still prefer to run their own full nodes to ensure greater independent security and faster transaction confirmation. 9. Combining and Splitting Value While processing coins one by one is possible, keeping a separate record for each penny is cumbersome. To allow for the division and merging of value, transaction records contain multiple inputs and outputs. Typically, there is either a single input from a relatively large previous transaction, or a combination of many inputs from smaller amounts; meanwhile, there are at most two outputs: one is the payment (to the recipient), and if necessary, the other is the change (to the sender). It's worth noting that "fan-out" isn't the issue here—"fan-out" refers to a transaction that depends on several transactions, which in turn depend on even more transactions. There's never any need to extract a complete, independent historical copy of any single transaction. 10. Privacy Traditional banking models achieve a degree of privacy by restricting access to information about transacting parties and trusted third parties. This approach is rejected due to the need to make all transaction records public. However, maintaining privacy can be achieved by cutting off the flow of information elsewhere—public-key anonymity. The public can see that someone transferred a certain amount to someone else, but no information points to a specific individual. This level of information disclosure is somewhat like stock market transactions, where only the time and the amounts of each transaction are published, but no one knows who the transacting parties are. 11. Calculations Imagine an attacker attempting to generate an alternative chain that is faster than the honest chain. Even if he succeeds, it won't leave the current system in an ambiguous situation; he cannot create value out of thin air, nor can he acquire money that never belonged to him. Network nodes will not accept an invalid transaction as a payment, and honest nodes will never accept a block containing such a payment. At most, the attacker can only modify his own transactions, attempting to retrieve money he has already spent. The competition between the honest chain and the attacker can be described using a binomial random walk. A successful event is when a new block is added to the honest chain, increasing its advantage by 1; while a failed event is when a new block is added to the attacker's chain, decreasing the honest chain's advantage by 1. The probability that an attacker can catch up from a disadvantaged position is similar to the gambler's bankruptcy problem. Suppose a gambler with unlimited chips starts from a deficit and is allowed to gamble an unlimited number of times with the goal of making up the existing deficit. We can calculate the probability that he can eventually make up the deficit, which is the probability that the attacker can catch up with the honesty chain[8], as follows: Since we have already assumed that the number of blocks an attacker needs to catch up with is increasing, their probability of success decreases exponentially. When the odds are against them, if the attacker doesn't manage to make a lucky forward move at the beginning, their chances of winning will be wiped out as they fall further behind. Now consider how long a recipient of a new transaction needs to wait to be fully certain that the sender cannot alter the transaction. Let's assume the sender is an attacker attempting to mislead the recipient into believing they have paid the due, then transfer the money back to themselves. In this scenario, the recipient would naturally receive a warning, but the sender would prefer that by then the damage is done. The recipient generates a new public-private key pair and then informs the sender of the public key shortly before signing. This prevents a scenario where the sender prepares a block on a chain in advance through continuous computation and, with enough luck, gets ahead of the time until the transaction is executed. Once the funds have been sent, the dishonest sender secretly begins working on another parachain, attempting to insert a reverse version of the transaction. The recipient waits until the transaction is packaged into a block, and then another block is subsequently added. He doesn't know the attacker's progress, but can assume the average time for an honest block to be generated in each block generation process; the attacker's potential progress follows a Poisson distribution with an expected value of: To calculate the probability that the attacker can still catch up, we multiply the Passon density of each attacker's existing progress by the probability that he can catch up from that point: To avoid rearranging the data after summing the infinite series of the density distribution… Convert to C language program... From the partial results, we can see that the probability decreases exponentially as Z increases: If P is less than 0.1%... 12. Conclusion We propose an electronic transaction system that does not rely on trust. Starting with a simple coin framework using digital signatures, while providing robust ownership control, it cannot prevent double-spending. To address this, we propose a peer-to-peer network using a proof-of-work mechanism to record a public transaction history. As long as honest nodes control the majority of CPU power, attackers cannot successfully tamper with the system solely from a computational power perspective. The robustness of this network lies in its unstructured simplicity. Nodes can work simultaneously instantaneously with minimal coordination. They don't even need to be identified, as message paths do not depend on a specific destination; messages only need to be propagated with best-effort intent. Nodes are free to join and leave, and upon rejoining, they simply accept the proof-of-work chain as proof of everything that happened while they were offline. They vote with their CPU power, continuously adding new valid blocks to the chain and rejecting invalid ones, indicating their acceptance of valid transactions. Any necessary rules and rewards can be enforced through this consensus mechanism.
