The concept of Bitcoin was proposed by Satoshi Nakamoto , a Japanese-American, physicist and train model collector. He is an anarchist and stateless, which may be one of the reasons why he proposed decentralized Bitcoin.
Bitcoin creation paper by Satoshi Nakamoto: "Bitcoin: A Peer-to-Peer Electronic Cash System", original download
Let's try to translate the original text to increase the learning and understanding of Bitcoin:
-------------------------------------------------------------------------------------------------------------------------------
Bitcoin: Peer-to-peer electronic cash system
Abstract : A pure peer-to-peer version of the electronic cash system will allow online payments directly from one party to the other without going through a financial institution. Digital signatures provide a partial solution, but if a trusted third party is still needed to prevent double spending, it will be meaningless. We propose a solution to the double-spending problem based on a peer-to-peer network. The method of adding timestamps to the peer-to-peer network is to add the hash value of the transaction to a growing chain-the chain adopts a hash-based proof-of-work method for growth, and changes to the record must be performed again. The longest chain not only serves as a proof of the observed sequence of events, but also as a proof that it comes from the largest pool of computing power. As long as most of the computing power of the peer-to-peer network is controlled by the cooperating nodes, they can surpass the attacker and generate the longest chain. The network itself requires a minimal structure, where messages are broadcast in a best-effort manner, nodes can leave or rejoin the network at will, and accept the longest proof-of-work chain to confirm what happened during their absence from the network.
1. Introduction
Business on the Internet almost entirely relies on financial institutions as trusted third parties to process electronic payments. Although the system works well under most transactions, this trust-based model still has its inherent weaknesses. Completely irreversible transactions are impossible, because financial institutions cannot avoid disputes. The cost of mediation increases transaction costs, limits the smallest actual transaction scale, cuts off the possibility of small temporary transactions, and incurs broader costs due to the loss of irreversible payment capabilities for irreversible services. Since transactions can be reversed, the requirements for trust increase. Businesses must be wary of their customers and get as much information as possible that they don’t need. A certain percentage of fraud is considered inevitable. These costs and payment uncertainty can be avoided by personally using physical currency, but there is no mechanism that makes it possible to make payments through communication channels without trusted parties.
What is needed is an electronic payment system based on cryptographic proof rather than trust, allowing any two willing parties to conduct direct transactions without the need for a trusted third party. Computationally irreversible transactions will protect sellers from fraud, and conventional escrow mechanisms can also be easily implemented to protect buyers. This paper proposes a solution to the double-spending problem, that is, a point-to-point distributed time-stamp server is used to generate the calculation proof of the time sequence of the transaction. As long as the total computing power controlled by honest nodes is more than that controlled by attacking nodes, the system is safe.
2. Transactions
We define electronic currency as a digital signature chain. The transfer of the coin is realized by the owner signing the previous transaction and the public key of the next owner, and placing these two signatures at the end of the coin. The payee can verify chain ownership by verifying the signature.
Of course, the problem is that the payee cannot verify that one of the owners did not double spend. A common solution is to introduce a trusted central authority (the mint) to check whether the transaction has been double spent. After each transaction, the coins must be returned to the mint to issue new coins. Only the coins issued from the mint can be sure that there is no double spend. The problem with this solution is that the fate of the entire monetary system depends on the company that runs the mint, and every transaction goes through them, just like a bank.
We need a way to let the payee know that the previous owner did not use the currency for earlier transactions. For this purpose, the earliest transaction is the most critical, so we don't care whether a double spend is made later. The only way to confirm the existence of a transaction is to understand all transactions. In the mint model, the mint understands all transactions and decides which transaction is the first. In order to achieve this goal without a trusted party, the transaction must be publicly announced [1], and we need a system for participants to reach a consensus on the single history of the sequence based on the facts they have received. The payee needs evidence to show that in each transaction, most nodes agree that this is the first time it is received.
3. Timestamp server
Our proposed solution is to start with a timestamp server. The timestamp server obtains the timestamp by hashing blocks composed of multiple items, and publishes the hash value widely, such as in newspapers or Usenet posts [2-5]. The timestamp is used to prove that the data exists at the point in time when the hash value is obtained. The hash value of each timestamp contains the previous timestamp to form a chain, and each newly added timestamp enhances the previous timestamp.
4. Proof of workload
To implement a distributed timestamp server on a peer-to-peer basis, we need to use a proof-of-work mechanism similar to Adam Back's Hashcash [6] instead of newspapers or Usenet posts. Proof of work involves retrieving a value after hashing, such as SHA-256, and the resulting hash value starts with a certain number of zero bits. The average amount of work required is exponentially related to the number of zero bits required, and the answer can be verified by one hash.
For our timestamp network, the proof-of-work mechanism is implemented as follows: increment a nonce value in the block, and calculate the hash value of the entire block for each nonce until a hash value is found that meets the requirements The number of zero bits. Once the CPU has spent the effort to meet the proof of work, the block cannot be changed without redoing the work. After the subsequent block is put into the chain, the amount of work required to change the block will include the work of all blocks after redoing.
The proof-of-work mechanism also solves the problem of determining which is the representative in most decision-making. If most definitions are based on one IP address, one vote, someone who can assign many IPs will be able to disrupt the system. Proof of work is essentially one CPU, one vote. Most decisions are represented by the longest chain because it contains the most proof-of-work work. If most of the CPU power is controlled by honest nodes, the honest chain will grow the fastest, surpassing any competing chain. To modify past blocks, the attacker will have to redo the engineering proofs of all subsequent blocks, and then catch up with and surpass the work of honest nodes. Later we will show that the probability of a slower attacker catching up exponentially decreases as subsequent blocks are added.
In order to compensate for the increase in hardware speed and changes in interest in running nodes over time, the difficulty of proof of work depends on an average number of changes-the number of blocks generated per hour. If blocks are generated too quickly, the difficulty will increase.
5. Network
The steps to run the network are as follows:
(1) The new transaction is broadcast to all nodes.
(2) Each node collects new transactions into a block.
(3) The job of each node is to find a difficult block proof of work.
(4) When a node discovers the proof of work, it broadcasts the block to all nodes.
(5) The node accepts the block only if all transactions in the block are valid and have not been spent.
(6) Nodes indicate that they have accepted the block by creating the next block on the chain, and use the hash of the accepted block as the leading hash of the newly created block.
The node always thinks that the longest chain is correct and will continue to expand it. If two nodes broadcast different versions of the next block at the same time, some nodes will receive this or that one first. In that case, they work on the first block they receive, but save other branches in case they become longer. When the next proof of work is found and one branch becomes longer, the balance of power will be broken; nodes working on another branch will switch to this longer branch.
The broadcast of new transactions does not necessarily reach all nodes. As long as they reach many nodes, they will soon enter a block. Block broadcasting also tolerates message loss. If a node does not receive a block, it will realize that it missed a block when it receives the next block and request it.
6. Incentive
By convention, the first transaction in a block is a special transaction in which the generated coins belong to the producer of the block. This incentivizes nodes to support the network and provides a way to issue coins and put them into circulation, because there is no central authority to issue them. The steady increase of a certain number of new coins is analogous to gold miners consuming resources to dig into gold and then put it into circulation. In our mechanism, this is CPU time and power consumption.
Transaction fees can also be used as incentives. If the output value of the transaction is less than its input value, the difference is the transaction fee-as an additional incentive for the block containing the transaction. Once a predetermined number of coins have entered circulation, the incentive can be completely transferred to transaction costs, and there will be no inflation at all.
Incentives may help encourage nodes to remain honest. If a greedy attacker can assemble more CPU computing power than all honest nodes, he will have to face a choice: use computing power to steal his payment to achieve fraud, or use it to generate new coins. He should find it more profitable to play cards according to the rules-this rule guarantees that he gets more new coins than others can get together, rather than breaking the rules and damaging the effectiveness of his wealth.
7. Reclaim disk space
When a new transaction is put into the chain, and after enough blocks have been expanded after the chain, it can be confirmed that the transaction will not be cancelled, and the transaction record before the transaction can be lost to save disk space. In order to achieve this without breaking the hash of the block, the transaction is hashed in the Merkle tree [7][2][5], and only the Merkle tree root is included in the block hash. The size of old blocks can be compressed through such pruning. Except for the Merkle tree root, there is no need to save other internal hashes.
The block header without transaction records is about 80 bytes. Assuming that a block is generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. Before 2008, computer systems generally had 2GB of memory, and Moore's Law predicted that memory would grow at a rate of 1.2GB per year, so even if all block headers must be loaded into memory, it is not a problem.
8. Simplify payment verification
The payment can be verified without running a full network node. The user only needs to keep a copy of the block header of the longest chain, and he can continuously initiate queries until he confirms that he has the longest chain, and a block on this chain can be connected to the Merkle branch of the user's exchange. The user could not originally confirm the validity of the transaction, but by linking the transaction to the chain, he can see that a node has accepted it and linked to a new block after it, which indicates that the transaction has been Confirmed by the whole network.
Therefore, as long as honest nodes control the network, the verification is reliable, but if the network is controlled by an attacker, the verification is relatively fragile. Because network nodes can verify transactions themselves, as long as the attacker can continue to control the network, the simplified method will be fooled by transactions fabricated by hackers. One strategy to prevent this situation is to issue an alarm when an invalid block is detected by a network node, prompting the user to download the complete information of the invalid block or transaction to confirm the inconsistency. Companies with frequent collections may still want to run their own nodes for more independent security and faster verification.
9. Consolidate and divide value
Although it is possible to deal with coins separately, it is not easy to trade each cent separately. In order to allow value to be divided and combined, transactions contain multiple inputs and outputs. There will usually be a single input from a larger predecessor transaction or multiple aggregate inputs from a smaller predecessor transaction, with a maximum of two outputs: one for payment and the other for returning the change (if any) to the initiator .
It needs to be pointed out that each transaction depends on multiple previous transactions, and these multiple transactions rely on more previous transactions. This is not a problem. In this mechanism, it is not necessary to carry out the inspection of all previous transaction history.
10. Privacy
The traditional banking business model achieves a certain degree of privacy protection by restricting parties and trusted third parties' access to information. Under this mechanism, because all transactions need to be announced, this method will not work, but privacy can still be protected, blocking the flow of information in the other direction, that is, keeping the public key anonymous. The public can see that someone has sent an amount to other people, but there is no information that can connect the transaction to anyone. This is similar to the information disclosure mechanism of the stock exchange. The transaction time and the scale of individual transactions are recorded and made public, but the parties are not informed.
As an additional precaution, a new pair of keys should be used for each transaction to ensure that they do not point to a common owner. In multi-point input transactions, some connections are still inevitable, and they must show that their input is the same owner. The risk is that if the owner of a key is revealed, it can be revealed that other transactions also belong to that owner.
11. Calculation method
Consider the following scenario where an attacker tries to generate another chain faster than the honest chain. Even if this is done, it will not open the system to arbitrary changes, such as creating value out of nothing or getting money that never belonged to the attacker. Nodes will not accept invalid transactions as payment, and honest nodes will never accept a block containing invalid transactions. The attacker can only try to change one of his own transactions to recover the money he recently spent.
The competition between the honest chain and the attacker chain can be characterized as a binary tree random walk. A success event is an honest chain extending one block, leading by +1, while a failure event is an attacker's chain extending one block with a gap of -1.
The probability of an attacker catching up from a given lag is similar to the gambler bankruptcy problem. Suppose a gambler with unlimited credit starts from a deficit and makes potentially unlimited attempts to make up for the loss. We can calculate the probability that he fills up the loss, that is, the probability that the attacker catches up with the honest chain, as follows [8]:
p = probability of honest nodes finding the next block
q = probability that the attacker finds the next block
qz = the probability that the attacker will catch up with the next z blocks
Assuming p> q, the probability of success decreases exponentially as the number of blocks that the attacker needs to catch up with increases. Because the odds of winning are not on the attacker's side, if he is not lucky enough to succeed quickly, his chances will only become smaller and smaller.
We now consider how long the recipient of a new transaction needs to wait to fully determine that the initiator cannot change the transaction. We assume that the initiator is an attacker, and he wants the recipient to believe that he has paid for a period of time, and then return the coins to himself. At that time, the recipient will receive a reminder, but it will be too late.
The receiver generates a new key pair and sends the public key to the sender shortly before signing the contract. This prevents the payer from preparing a block chain in advance and then continuously performing calculations on this block, until his block chain happens to exceed the honest chain before performing the payment immediately. At this point, as soon as the transaction is issued, the attacker secretly prepares a parachain containing an alternative version of the transaction.
The receiver waits until the transaction is added to a block, and Z blocks are connected behind it. He does not know the exact amount of progress made by the attacker, but assuming that the time for an honest block to generate a new block is the average expected time, the attacker's potential progress is a Poisson distribution, and its expectation is:
To get the probability that the attacker can still catch up now, we multiply the Poisson density of the amount of progress he may have made by the probability that he may catch up from this point:
Rearrange to avoid summing infinite series.
Converted to C code...
#include <math.h>
double AttackerSuccessProbability(double q, int z)
{
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k <= z; k++)
{
double poisson = exp(-lambda);
for (i = 1; i <= k; i++)
poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}Run and get some results, we can see that the probability decreases exponentially with z.
| q=0.1 z = 0 |
P=1.0000000 |
| z = 1 |
P=0.2045873 |
| z = 2 |
P=0.0509779 |
| z = 3 |
P=0.0131722 |
| z = 4 |
P=0.0034552 |
| z = 5 |
P=0.0009137 |
| z = 6 |
P=0.0002428 |
| z = 7 |
P=0.0000647 |
| z = 8 |
P=0.0000173 |
| z = 9 |
P=0.0000046 |
| z = 10 |
P=0.0000012 |
|
q=0.3 z = 0 |
P=1.0000000 |
| z = 5 |
P=0.1773523 |
| z = 10 |
P=0.0416605 |
| z = 15 |
P=0.0101008 |
| z = 20 |
P=0.0024804 |
| z = 25 |
P=0.0006132 |
| z = 30 |
P=0.0001522 |
| z = 35 |
P=0.0000379 |
| z = 40 |
P=0.0000095 |
| z = 45 |
P=0.0000024 |
| z = 50 |
P=0.0000006 |
To make P less than 0.1%...
P < 0.001
| q=0.10 |
z = 5 |
| q=0.15 |
z = 8 |
| q=0.20 |
z = 11 |
| q=0.25 |
z = 15 |
| q=0.30 |
z = 24 |
| q=0.35 |
z = 41 |
| q=0.40 |
z = 89 |
| q=0.45 |
z = 340 |
12. Conclusion
我们提出了一个不依靠信任的电子交易系统。我们从数字签名构成的通用币框架开始，数字签名提供了对所有权强有力的控制，但由于没有办法防止双花，仍然是不完整的。为了解决这个问题，我们提出了一个使用工作量证明记录交易的公共历史的对等网络，在诚实节点控制多数算力的情况下，攻击者要改变交易会迅速变得不切实际。该网络的强健之处在于它非结构化的简洁性。所有节点只需要少量沟通就可同时工作。他们不需要被识别，因为信息没有路由到任何特定的地方，只需要以尽力而为的方式交付。节点可以随意离开或重新加入网络，并接受最长的工作量证明链，以此确证他们不在网络期间发生的事。他们用算力进行投票，扩展接受的链，拒绝工作在包含无效区块的链上。任何需要的规则和激励都可以通过这个共识机制来实施。
参考资料
[1] W. Dai, “b-money,” http://www.weidai.com/bmoney.txt, 1998.
[2] H. Massias, X.S. Avila, and J.-J. Quisquater, “Design of a secure timestamping service with minimal
trust requirements,” In 20th Symposium on Information Theory in the Benelux, May 1999.
[3] S. Haber, W.S. Stornetta, “How to time-stamp a digital document,” In Journal of Cryptology, vol 3, no
2, pages 99-111, 1991.
[4] D. Bayer, S. Haber, W.S. Stornetta, “Improving the efficiency and reliability of digital time-stamping,”
In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993.
[5] S. Haber, W.S. Stornetta, “Secure names for bit-strings,” In Proceedings of the 4th ACM Conference
on Computer and Communications Security, pages 28-35, April 1997.
[6] A. Back, “Hashcash - a denial of service counter-measure,”
http://www.hashcash.org/papers/hashcash.pdf, 2002.
[7] R.C. Merkle, “Protocols for public key cryptosystems,” In Proc. 1980 Symposium on Security and
Privacy, IEEE Computer Society, pages 122-133, April 1980.
[8] W. Feller, “An introduction to probability theory and its applications,” 1957. 9
-----------------------------------------------------------------------------------------------------------------------------