PANews Editor's Note: On October 31, 2008, Satoshi Nakamoto released the Bitcoin white paper, marking today as the 17th anniversary. Below is the content of the white paper translated by Li Xiaolai for everyone to revisit this classic.
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 provide some solutions, if a trusted third party is still needed to prevent double spending, the main advantage of electronic payments is negated. We propose a solution that uses a peer-to-peer network to solve the double spending problem. The peer-to-peer network will timestamp each transaction by hashing the transaction data and recording it into an ongoing chain of hash-based proof of work, forming a record that cannot be changed without redoing the work. The longest chain serves to prove that a given event has occurred and its order, while also proving that it came from the largest pool of CPU power. As long as the majority of CPU power is controlled by honest nodes—meaning they are not cooperating with nodes attempting to attack the network—then honest nodes will generate the longest chain and outpace any attackers. The network itself requires minimal structure. Information will be disseminated on a best-effort basis, with nodes free to join and leave; however, upon joining, they must accept the longest proof of work chain as proof of everything that has occurred 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 burdened by the inherent flaws of a trust-based model. Truly irreversible transactions are not possible because financial institutions cannot avoid arbitrating disputes. The cost of arbitration increases transaction costs, limiting the minimum possible transaction size and outright preventing many small payments. Beyond that, there are greater costs: the system cannot provide irreversible payments for irreversible services. The possibility of reversal creates a pervasive need for trust. Merchants must be wary of their customers, requiring them to provide unnecessary additional information unless trust is established. A certain percentage of fraud is considered unavoidable. These costs and payment uncertainties, while avoidable in direct physical currency transactions between people, cannot be mitigated by any mechanism when payments are made through communication channels where one party is untrusted.
What we really need is an electronic payment system based on cryptographic proof rather than trust, allowing any two parties to transact directly with each other without the need to trust a third party. CPU-backed irreversible transactions can help sellers avoid fraud, while protecting buyers' everyday assurance mechanisms can be easily implemented. In this paper, we will propose a solution to the double spending problem using a peer-to-peer, distributed timestamp server to generate proof based on computational work, recording each transaction in chronological order. This system is secure as long as honest nodes collectively control more CPU power than any cooperating attackers.
2. Transactions
We define an electronic coin as a chain of digital signatures. When one owner transfers a coin to another person, they do so by adding their digital signature to the end of the chain: the hash of the previous transaction and the new owner's public key. The recipient can verify ownership of the coin by verifying the signatures.
The problem with this chain is that the recipient cannot verify that the previous owners did not double spend. A common solution is to introduce a trusted centralized authority, known as a "mint," to check each 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 trusted and not double spent. The problem with this solution is that the fate of the entire currency system is tied to the company operating the mint (just like a bank), and every transaction must go through it.
We need a way for the recipient to confirm that previous owners did not sign any previous transactions. For our purposes, only the earliest transaction counts, so we do not care about subsequent double spending attempts. The only way to confirm that a transaction does not exist is to know all transactions. In the mint model, the mint knows all transactions and can confirm their order. To accomplish this without a "trusted party," transaction records must be publicly announced, and we need a system that allows participants to agree on the same unique transaction history they receive. The recipient needs to prove that at the time of each transaction, the majority of nodes could agree that it was the first one received.
3. Timestamp Server
This solution starts with a timestamp server. A timestamp server works by taking a hash of a set of records (items) and timestamping it, then broadcasting the hash, similar to how a newspaper does, or like a post in a Usenet newsgroup. Clearly, the timestamp proves that the data existed at that point in time; otherwise, the hash could not have been generated. Each timestamp contains the hash of the previous timestamp, forming a chain; each new timestamp is added after the previous one.
4. Proof-of-Work
To implement a peer-to-peer distributed timestamp server, we need to use a proof-of-work system similar to Adam Back's Hashcash, rather than something like a newspaper or Usenet post. The so-called proof-of-work involves finding a number that satisfies the following condition: when its hash is extracted—using SHA-256, for example—the hash must start with a certain number of zeros. Each additional zero requirement increases the workload exponentially, and this workload can only be verified by computing a hash.
In our timestamp network, we implement proof-of-work by continuously adding a random number (Nonce) in the block until a satisfactory number is found; this condition is that the block's hash starts with a specified number of zeros. Once the result obtained from the CPU's computational power meets the proof-of-work, the block cannot be changed unless all previous work is redone. As new blocks are continuously added, changing the current block means redoing all the work of the subsequent blocks.
Proof-of-work also solves the problem of how to decide who can represent the majority in making decisions. If the so-called "majority" is determined by "one IP address, one vote," then anyone who can manage many IP addresses could be considered the "majority." Proof-of-work is essentially "one CPU, one vote." The so-called "majority decision" is represented by the longest chain, as the chain with the most work put into it is the one that counts. If the majority of CPU power is controlled by honest nodes, then the honest chain grows the fastest, outpacing any competing chains. To change a block that has already been produced, an attacker would have to redo the proof-of-work for that block and all subsequent blocks, and then catch up and exceed the work of the honest nodes. The following sections will show why the likelihood of a delayed attacker catching up decreases exponentially as more blocks are added.
To address the increasing aggregate hardware power and the potential changes in the number of participating nodes over time, the difficulty of proof-of-work is determined by a moving average based on the average number of blocks produced per hour. If blocks are generated too quickly, the difficulty will increase.
5. Network
The steps to run the network are as follows:
- All new transactions are broadcast to all nodes;
- Each node packages the new transactions into a block;
- Each node begins to find a proof-of-work for this block;
- When a block finds its proof-of-work, it broadcasts this block to all nodes;
- Many other nodes will accept this block only if the following conditions are met: all transactions are valid and not double spent;
- Nodes indicate their acceptance of this block to the network by including the hash of the accepted block as the previous hash in the creation of the next block.
Nodes always consider the longest chain to be the correct one and will continue to add new data to it. If two nodes broadcast two different versions of the "next block" simultaneously, 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 keep the other branch in case it becomes the longest chain. When the next proof-of-work is found and one of the branches becomes the longer chain, this temporary divergence will be resolved, and nodes working on the other branch will switch to the longer chain.
New transactions do not necessarily have to be broadcast to all nodes. As long as they reach enough nodes, these transactions will soon be packaged into a block. Block broadcasting also allows for some messages to be dropped. If a node does not receive a certain block, it will realize it has missed the previous block when it receives the next block and will issue a request to retrieve the missing block.
6. Incentive
By convention, the first transaction in each block is a special transaction that generates a new coin, with ownership belonging to the creator of that block. This incentivizes nodes to support the network and provides a way to issue coins into circulation—since there is no centralized authority to issue those coins in this system. This steadily increases a certain number of new coins into circulation, similar to how gold miners continuously expend their resources to add gold to circulation. In our system, the resources expended are CPU working 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 packaging the transaction into this block. Once a predetermined number of coins have entered circulation, rewards will be entirely based on transaction fees, and there will be no inflation.
The reward mechanism may also encourage nodes to remain honest. If a greedy attacker can amass more CPU power than all the honest nodes combined, they must make a choice: will they use that power to deceive others by stealing back the money they spent? Or will they use that power to generate new coins? They should find that acting according to the rules is more profitable, as the current rules allow them to earn more coins than all others combined, which is clearly more advantageous than secretly destroying the system and rendering their wealth null.
7. Reclaiming Disk Space
If a coin's recent transactions occurred sufficiently far back in the blockchain, the spending transaction records prior to that can be discarded—this is to save disk space. To achieve this without compromising the hash of the block, the transaction records' hashes will be included in a Merkle tree, with only the root of the tree being included in the block's hash. By pruning branches, old blocks can be compressed. The internal hashes do not need to be preserved.
A block header without any transaction records is about 80 bytes. Assuming a block is generated every ten minutes, 80 bytes multiplied by 6 multiplied by 24 multiplied by 365 equals 4.2M per year. As of 2008, most computers for sale came with 2GB of memory, and according to Moore's Law, this will increase by 1.2GB each year, so even if block headers must be stored in memory, it will not be a problem.
8. Simplified Payment Verification
It is possible to verify payments without running a full network node. A user only needs a copy of the block header of the longest chain with proof of work—they can confirm that the copy they have indeed comes from the longest chain by querying online nodes—and then obtain the branch nodes of the Merkle tree to connect to the transaction that was timestamped in that block. The user cannot check the transaction themselves, but by connecting to some point on the chain, they can see that a network node has accepted the transaction, and subsequent blocks further confirm that the network has accepted this transaction.
As long as honest nodes still control the network, this verification is reliable. However, if the network is controlled by attackers, the verification becomes less reliable. Although network nodes can verify transaction records themselves, as long as attackers continue to control the network, the simplified verification method may be deceived by forged transaction records. One countermeasure is for client software to accept warnings from network nodes. When a network node discovers an invalid block, it issues an alert, popping up a notification on the user's software to inform them to download the complete block and warn them 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 confirmations.
9. Combining and Splitting Value
While it is possible to handle coins one by one, setting a separate record for every penny is cumbersome. To allow for the splitting and combining of value, transaction records include multiple inputs and outputs. Generally, there is either a single input from a relatively large previous transaction or many inputs from smaller amounts combined; at the same time, there are at most two outputs: one for payment (pointing to the recipient) and, if necessary, another for change (pointing back to the sender).
It is worth noting that "fan-out" is not an issue here—"fan-out" refers to a transaction relying on multiple transactions, which in turn rely on even more transactions. There has never been a need to extract a complete independent historical copy of any transaction.
10. Privacy
Traditional banking models achieve a certain degree of privacy protection by restricting others from accessing information about the transactor and trusted third parties. However, the demand for public access to all transaction records negates this approach. Nevertheless, privacy can be maintained by severing the information flow 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 release is somewhat akin to stock market transactions, where only the time and amounts of each transaction are published, but no one knows who the parties involved are.
11. Calculations
Consider a scenario where an attacker is trying to generate an alternative chain that is faster than the honest chain. Even if they succeed, it will not put the current system in an ambiguous predicament; that is, they cannot create value out of thin air, nor can they obtain money that never belonged to them. Network nodes will not treat an invalid transaction as a payment, and honest nodes will never accept a block that contains such a payment. The attacker can at most modify their own transactions in an attempt to reclaim the money they have 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; a failure event is when a new block is added to the attacker's chain, decreasing the honest chain's advantage by 1.
The probability of the attacker catching up from a lagging position is similar to the gambler's ruin problem. Suppose a gambler with infinite chips starts from a deficit and is allowed to gamble infinitely, aiming to fill the existing deficit. We can calculate the probability that they will eventually fill the deficit, which is the probability that the attacker can catch up to the honest chain.
Since we have assumed that the number of blocks the attacker needs to surpass is increasing, their probability of success will decrease exponentially. When the odds are against them, if the attacker does not get lucky with an early lead, their chances of winning will diminish as they fall further behind.
Now consider how long a recipient of a new transaction needs to wait to be sufficiently certain that the sender cannot change the transaction. We assume the sender is an attacker attempting to make the recipient believe they have paid for a period of time, only to later transfer the money back to themselves. In such a case, the recipient will certainly receive a warning, but the sender hopes that by then it will be too late.
The recipient generates a new pair of public and private keys and informs the sender of the public key shortly before signing. This prevents a scenario where the sender prepares a block on a chain through continuous computation in advance, and with enough luck, gets far enough ahead to execute the transaction at that time. Once the funds have been sent, the dishonest sender secretly begins working on another parallel chain, attempting to include a reverse version of the transaction.
The recipient waits until the transaction is packaged into a block, and a subsequent block has been added. They do not know how far along the attacker's work is, but they can assume the average time spent generating honest blocks; 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 need to multiply the Poisson density of each of the attacker's existing progress by the probability that they can catch up from that point:
To avoid summing and rearranging the infinite series of density distributions…
Convert to a C language program…
Obtaining partial results, we can see that the probability decreases exponentially with the increase of Z:
If P is less than 0.1%…
12. Conclusion
We have proposed an electronic transaction system that does not rely on trust; starting from a standard coin framework using digital signatures, which, while providing robust ownership control, cannot prevent double spending. To solve this problem, we propose a peer-to-peer network using a proof-of-work mechanism to record a public transaction history, ensuring that as long as honest nodes can control the majority of CPU power, attackers cannot successfully tamper with the system from a computational standpoint. The robustness of this network lies in its unstructured simplicity. Nodes can work simultaneously with minimal coordination. They do not even need to be identified, as the path of messages does not depend on specific endpoints; messages only need to be disseminated on a best-effort basis. Nodes can join and leave freely, and upon rejoining, they only need to accept the proof-of-work chain as proof of everything that occurred while they were offline. They vote with their CPU power, continuously adding new valid blocks to the chain and rejecting invalid blocks, indicating their acceptance or rejection of valid transactions. Any necessary rules and rewards can be enforced through this consensus mechanism.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
