16th Anniversary Classic Reread: The Full Text of the Chinese Version of Bitcoin White Paper

Note: On October 31, 2008, Satoshi Nakamoto released the Bitcoin white paper “Bitcoin: A peer-to-peer electronic cash system” on the P2P foundation website.On the occasion of the 16th anniversary of the white paper’s release, in order to reread this classic that has forever changed the financial world, Bitcoin Vision once again published a Chinese version of the Bitcoin White Paper.

Author: Satoshi Nakamoto; Translator: Li Xiaolai

Summary: A purely peer-to-peer version of the electronic cash system that will allow online payments to be sent directly from one party to the other without the need to go through a financial institution.Although digital signatures provide some solutions, the main advantage of electronic payments is offset if trusted third parties are still required to prevent double spending.We propose a solution to use a peer-to-peer network to solve the dual expenditure problem.The peer-to-peer network will mark the timestamp for each transaction by entering the hash data of the transaction into a continuously extended hash-based proof of work chain to form a record that cannot be changed without complete redoing..The longest chain is used to prove the witnessed events and their order, and at the same time, it is also used to prove that it comes from the largest CPU computing power pool.As long as the vast majority of CPU computing power is controlled by benign nodes—that is, they do not cooperate with those nodes that attempt to attack the network—then the benign nodes will generate the longest chain and exceed the attacker in speed.This network itself requires a minimized structure.Information will be spread based on the best efforts, and nodes come and go freely; however, when joining, you always need to accept the longest proof of work chain as proof of everything that happened during their uninvolved period.

1. Introduction

Internet commerce relies almost entirely on financial institutions as trusted third parties to process electronic payments.While this system is pretty good for most transactions, it is still dragged down by the flaws inherent in trust-based models.A completely irreversible transaction is actually impossible, because financial institutions cannot avoid arbitration disputes.The cost of arbitration increases transaction costs, thereby limiting the size of the minimum possible transaction and simply preventing many small payment transactions.In addition, there is a greater cost: the system cannot provide irreversible payments for those irreversible services.The possibility of reversal has created an omnipresent demand for trust.Merchants must beware of their customers and ask customers to provide more information that is not necessary if this is not the case (if trusted).A certain percentage of fraud is considered inevitable.Although these costs and payment uncertainties can be avoided when paying directly with physical currency between people, no mechanism can be used to make payments through communication channels when one of them is not trusted..

What we really need is an electronic payment system based on cryptographic proof rather than trust-based, allowing any party to trade directly without trusting a third party.Irreversible transactions guaranteed by computing power can help sellers avoid fraud, and the daily guarantee mechanism to protect buyers is also easy to implement.In this paper, we will propose a solution for double expenditure, using a point-to-point, distributed timestamp server to generate computing power-based proofs, and record each transaction in chronological order.This system is secure, as long as honest nodes generally have more CPU computing power than mutually cooperative attackers.

2. Transactions

We define an electronic coin as a digital signature chain.When an owner handed a coin to another person, he or she had to attach the following digital signature at the end of the digital signature chain: the hash of the previous transaction (transliteration, also translated as “hash value””), and the public key of the new owner.The payee can verify the ownership of the digital signature chain by verifying the signature.

The problem with this path is that the payee cannot verify that no one of the former owners has paid twice.A common solution is to introduce a trusted centralized authority, or “mint”, to check whether there is a double payment for each transaction.After each transaction, the coin must be returned to the mint, and the mint issues another new coin.Furthermore, only coins issued directly by the mint are credible and not double paid.The problem with this solution is that the fate of the entire currency system is tied to the company that runs the mint (like a bank) and every transaction must pass through it.

We need a way to have the payee confirm that the previous owner has not signed any previous transactions.For our purposes, only the earliest transactions are arithmetic, so we do not care about the subsequent double payment attempts.The only way to confirm that a transaction does not exist is to learn about all transactions.In the mint model, the mint is aware of all transactions and is able to confirm the order of these transactions.In order to complete the above tasks without the participation of the “trusted party”, the transaction record must be publicly announced1, and we need a system that allows participants to identify with the same unique transaction history they receive.The payee needs to prove that at the time of each transaction, most nodes can agree that it is the first to be received.

3. Timestamp Server

This solution started with a timestamp server.The timestamp server works like this: timestamp a hash of a block record item, and then broadcast the hash, just like a newspaper does, or like in a newsgroup (Usenet)like a post in )2345.Obviously, the timestamp can prove that the data existed before that point in time, otherwise the hash would not be generated.Each timestamp contains the previous timestamp in its hash, thus forming a chain; each new timestamp is added after the previous timestamp.

4. Proof-of-Work

To implement a peer-to-peer distributed timestamp server, we need to use a hash cash similar to Adam Burke6Such a proof of work system, not something like newspapers or news group posts.The so-called proof of work is to find a value; this value must meet the following conditions: after extracting the hash value for it – for example, using SHA-256 to calculate the hash value – this hash value must start with a certain number of 0s.Each additional requirement of 0 will increase the workload exponentially, and the verification of this workload only requires calculating a hash.

In our timestamp network, we implement proof of work in this way: constantly add a random number (Nonce) to the block until a value that meets the condition is found; this condition is that the hash of the block isSpecifies the number of 0 to start.Once the results obtained by the CPU’s power-consuming computing meet the proof of work, the block will no longer be changed unless all previous workloads are re-completed.As new blocks are constantly added, changing the current block means that all subsequent blocks are to be re-completed.

Proof of work also addresses the question of how to decide who can make the decision on behalf of the majority.If the so-called “most” is determined based on “one IP address, one vote”, then anyone who can handle many IP addresses can be considered the “most”.In essence, a proof of work is “one CPU, one vote”.The so-called “most decisions” are represented by the longest chain, because the chain that is put into the most work is it.If most CPU computing power is controlled by honest nodes, then honest chains grow the fastest and their speed will be far higher than other competitive chains.In order to change a block that has been generated, the attacker will have to re-complete the proof of work for that block and all subsequent blocks, and then catch up and surpass the work of the honest node.The following article shows why the possibility of a delayed attacker being able to catch up will decrease exponentially as the block continues to increase.

In order to cope with the increasing hardware computing power synthesis and the changes in the number of node participation that may occur over time, the difficulty of proof of work is determined by: based on an average of the number of blocks generated per hour.If the blocks are generated too quickly, the difficulty will increase.

5. Network

The steps to run the network are as follows:

1. All new transactions are broadcast to all nodes;

2. Each node packages new transactions into a block;

3. Each node starts to find a difficult work certificate for this block;

4. When a block finds its proof of work, it will broadcast the block to all nodes;

5. Many other nodes will accept this block if and only if the following conditions are met: all transactions are valid and not double paid;

6. The way many nodes express to the network that they accept this block is to use the hash of the accepted block as the hash before the new block when creating the next block.

The node always believes that the longest chain is the correct one and will constantly add new data to it.If two nodes broadcast two different versions of the “next block” to the network at the same time, some nodes will receive one first, while others will receive another first.In this case, the nodes will continue to work on the block they receive first, but will also save another branch in case the latter becomes the longest chain.When the next proof of work is found and one of the branches becomes a longer chain, this temporary disagreement will be eliminated, and the nodes working on the other branch will switch to a longer chain.

New transactions do not necessarily have to be broadcast to all nodes.As long as enough nodes are reached, these transactions will soon be packaged into a block.Block broadcasting also allows some messages to be discarded.If a node does not receive a block, then the node will realize that it has missed the previous block when it receives the next block, and therefore will issue a request to supplement the missing block.

6. Rewards (Incentive)

According to the agreement, the first transaction in each block is a special transaction, which will generate a new coin, and the ownership is the generator of this block.This allows the nodes to support the network to reward, and also provides a way to issue coins into circulation – in this system, there is no centralized authoritative party to issue those coins anyway.To increase a certain amount of new coins into circulation so steadily, it is like gold miners constantly spending their resources to increase gold into circulation.In our system, the resources consumed are CPU working hours and the power 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; and the transaction fee is used to reward nodes to package the transaction into this block.Once the established number of coins has entered circulation, the reward will be fully handed over to the transaction fee, and there will be no inflation.

The reward mechanism may also encourage nodes to remain honest.If a greedy attacker can hijack more CPU computing power than all honest nodes, he must make a choice: should he use this computing power to deceive others by stealing the money he spent?Or use this computing power to generate new coins?He should be able to find it more cost-effective to act by the rules, and the current rules allow him to obtain more coins than all the others add up, which is obviously more cost-effective than destroying the system in secret and turning his wealth into nothingness.

7. Reclaiming Disk Space

If a recent transaction of a coin occurs before enough blocks, the transaction history of the coin’s expenses can be discarded before the transaction – in order to save disk space.In order to implement this function without destroying the hash of the block, the hash of the transaction record will be included in a Merkle tree, and only the tree roots are included in the hash of the block.By cutting off branches, old blocks can be compressed.The internal hash does not need to be saved.

A block header without any transaction records is about 80 bytes.Suppose that a block is generated every ten minutes, 80 bytes multiplied by 6 by 24 by 365, equals 4.2M per year.As of 2008, most computers on sale were equipped with 2GB of memory, and according to Moore’s Law, it would add 1.2GB per year, even if the block headers had to be stored in memory, it would not be a problem.

8. Simplified version of payment confirmation

Even without running a full network node, it is possible to confirm payment.The user only needs to have a copy of the block header with the longest chain with the proof of work – he can confirm by querying the online node that he has indeed come from the longest chain – and then obtain the branch node of the Merkle tree, and then connect to the block.Transaction when timestamped.The user cannot check the transaction by himself, but by connecting to a place on the chain, he can see that a certain network node has accepted the transaction, and the block added thereafter further confirms that the network has accepted the transaction..

As long as the honest nodes are still in control of the network, verification is reliable.However, if the network is controlled by an attacker, verification is not so reliable.Although network nodes can verify transaction records themselves, as long as the attacker can continue to control the network, the simplified verification method may be deceived by the attacker’s forged transaction records.One of the coping strategies is that the client software must accept warnings from network nodes.When a network node finds an invalid block, an alarm will be issued, and a notification pops up on the user’s software to inform the user to download the complete block and warn the user to confirm transaction consistency.Merchants with high-frequency payments should still want to run their own full nodes to ensure more independent security and faster transaction confirmation.

9. Combination and segmentation of values

While it is possible to process coins one by one, setting up a separate record for each cent is clumsy.To allow for value division and merge, the transaction record contains multiple inputs and outputs.Generally speaking, it is either a separate input from a relatively large previous transaction, or many inputs come from a combination of smaller amounts; at the same time, there are at most two outputs: one is payment (pointing to collectionIf necessary, the other one is to make change (point to the issuing party).

It is worth noting that “fan out” is not a problem here – the so-called “fan out” means that a transaction depends on several transactions, and these transactions rely on more transactions.There was never a need to withdraw a complete and independent historical copy of any transaction.

10. Privacy

The traditional banking model achieves a certain level of privacy protection by restricting others from obtaining information from traders and trusted third parties.This approach was rejected out of the need to disclose all transaction records.However, maintaining privacy can be achieved by cutting off the information flow in another place – public key anonymity.The public can see that XX has transferred a certain amount to XX, but no information points to a certain person.This level of information release is a bit like stock market trading, only time and the amount of each transaction are announced, but no one knows who both parties are.

There is another firewall.Traders should enable a new pair of public and private keys for each transaction so that others cannot trace the transactions back to the same owner.Some multi-input transactions are still inevitably traced because those inputs will inevitably be identified from the same owner.The danger is that if the owner of a public key is exposed, all other transactions related to it will be exposed.

11. Calculations

Suppose a scenario where an attacker is trying to generate a faster alternative chain than an honest chain.Even if he succeeds, he cannot make arbitrary modifications to the system, that is, he cannot create value out of thin air, nor can he obtain money that never belongs to him.Network nodes will not treat an invalid transaction as a payment, and honest nodes will never accept a block containing such payment.At most, the attacker can modify his own transactions and then try to retrieve the money he has spent.

The competition between the honest chain and the attacker can be described as a binomial random walk.Successful events are the honest chain just added a new block, making it more advantageous$1$; and the failure event is that the attacker’s chain has just been added to a new block, which reduces the advantage of the honest chain$1$.

The probability that an attacker can tie from a backward situation is similar to the gambler’s bankruptcy problem.Suppose that a gambler with unlimited chips will start with the deficit and allow him to bet infinitely, with the goal of filling the existing deficit.We can calculate the probability that he can finally fill the deficit, that is, the probability that the attacker can catch up with the honest chain, as follows:

Since we have assumed$\mathrm{p>}$,q Since the number of blocks that attackers need to catch up with is increasing, the probability of success will decrease exponentially.When the winning side is unfavorable, if the attacker does not have the luck to take a step forward at the beginning, his winning rate will be eliminated while he falls further behind.

Now consider how long it will take for the payee of a new transaction to fully determine that the issuer cannot change the transaction.We assume that the payer is an attacker, trying to make the payee believe for a period of time that he has paid the payment, and then transfer the money back to himself.When this happens, the payee will certainly receive a warning, but the payee hopes that the dead are done by then.

The payee generates a new pair of public and private keys, and then informs the payee of the public key shortly before signing.This prevents a situation where the issuer prepares a block on a chain through continuous operations in advance, and as long as he has enough luck, he will be ahead until then the transaction is executed.Once the payment has been issued, the dishonest payer starts secretly working on another parachain, trying to add a reverse version of the transaction to it.

The payee waited until the transaction was packaged into the block and had z blocks subsequently joined.He does not know how the attacker’s work progresses, but it can be assumed that the average time spent on honest blocks in each block generation process; the attacker’s potential progress is in line with the Poisson distribution, and its expected value is:

In order to calculate the probability that an attacker can still catch up, we need to multiply the probability density of the Passon distribution of the number of blocks that an attacker needs to catch up by the probability that he can catch up when he falls behind the number of blocks:

Convert to C language program…

Getting some 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 have to rely on trust; the starting point is a common coin framework that starts with digital signatures, and although it provides robust ownership control, it cannot avoid double payments.To solve this problem, we propose a point-to-point network using the proof of work mechanism to record a public transaction record history. As long as the honest node can control most CPU computing power, it is impossible for an attacker to successfully tamper with the system in terms of computing power alone..The robustness of this network lies in its structureless simplicity.Nodes can work simultaneously instantly with little collaboration.They don’t even need to be identified because the path of the message does not depend on a specific endpoint; the message only needs to be propagated based on the best efforts.Nodes come and go freely, and when they rejoin, they only need to accept the proof of work chain as a proof of what happens when they are offline.They vote through their CPU computing power, and by constantly adding new valid blocks to the chain and rejecting invalid blocks, they indicate whether they accept valid transactions.Any necessary rules and rewards can be enforced through this consensus mechanism.

References

1. b-money Dai Wei (1998-11-01)http://www.weidai.com/bmoney.txt

2. Design of a secure timestamping service with minimal trust requirements Henri Massias, Xavier Serret-Avila, Jean-Jacques Quisquater20th Symposium on Information Theory in the Benelux(1999-05)http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.13.6228

3. How to time-stamp a digital document Stuart Haber, W.Scott StornettaJournal of Cryptology(1991)https://doi.org/cwwxd4DOI:10.1007/bf00196791

4. Improving the Efficiency and Reliability of Digital Time-Stamping Dave Bayer, Stuart Haber, W. Scott StornettaSequences II(1993)https://doi.org/bn4rpxDOI:10.1007/978-1-4613-9323-8_24

5. Secure names for bit-strings Stuart Haber, W. Scott StornettaProceedings of the 4th ACM conference on Computer and communications security – CCS ’97(1997)https://doi.org/dtnrf6DOI:10.1145/266420.266430

6. Hashcash – A Denial of Service Counter-Measure Adam Back (2002-08-01)http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.15.8

7. Protocols for Public Key Cryptosystems Ralph C. Merkle1980 IEEE Symposium on Security and Privacy(1980-04)https://doi.org/bmvbd6DOI:10.1109/sp.1980.10006

8. An Introduction to Probability Theory and its Applications William FellerJohn Wiley & Sons(1957)https://archive.org/details/AnIntroductionToProbabilityTheoryAndItsApplicationsVolume1