Reprinted from: http://www.8btc.com/wiki/bitcoin-a-peer-to-peer-electronic-cash-system
[Abstract]: This paper proposes an electronic cash system fully realized through peer-to-peer technology, which enables online payment to be directly initiated by one party and paid to another party without going through any financial institution in the middle. Although digital signatures partially solve this problem, if third-party support is still required to prevent double-spending, then the system loses its value. We (we) here propose a solution that enables cash systems to operate in a peer-to-peer environment and prevent double-spending problems. The network adds timestamps to all transactions by random hashing, merging them into a continuously extending chain of proof-of-work based on random hashing as transaction records, unless Re-complete the entire proof of work, and the resulting transaction record will not be changed. The longest chain will not only serve as a proof of the observed sequence of events, but also be seen as coming from the pool with the most CPU computing power. As long as the majority of CPU computing power is not intended to cooperate to attack the entire network, then honest nodes will generate the longest chain that outpaces the attacker. The system itself requires very little infrastructure. Information spreads across the network as best it can, and nodes can leave and rejoin the network at any time, using the longest proof-of-work chain as proof of transactions that occurred while the node was offline.
1. Introduction Almost all trade on theInternet requires financial institutions as trusted third parties to process electronic payment information. While such systems work well in the vast majority of cases, they are still endogenously subject to the weaknesses of the "trust based model". We cannot achieve completely irreversible transactions because financial institutions will inevitably come forward to mediate disputes. The existence of financial intermediaries will also increase transaction costs, limit the practical minimum transaction size, and limit daily micropayment transactions. And the potential loss is that many goods and services themselves cannot be returned. If there is no irreversible means of payment, Internet trade will be greatly limited. Because of the possibility of potential refunds, both parties to the transaction need to have trust. Merchants also have to be wary of their own customers, so they ask customers for completely unnecessary personal information. In actual business behavior, a certain percentage of fraudulent customers are also considered unavoidable, and related losses are treated as sales expenses. In the case of physical cash, these uncertainties in sales fees and payment issues can be avoided because there is no third-party credit intermediary at this time.
Therefore, we are in great need of such an electronic payment system, which is based on cryptographic principles rather than credit, so that any two parties who reach an agreement can make payments directly without the participation of third-party intermediaries. Eliminates the possibility of reversing payment transactions, which protects certain sellers from fraud; and for those who want to protect buyers, setting up the usual third-party guarantee mechanisms in this environment is also a breeze and a pleasure . In this paper, we (we) will solve the double-spending problem by proposing a peer-to-peer distributed timestamp server to generate electronic transaction proofs that are chronologically arranged and recorded. The system is secure as long as the sum of the computing power controlled by the honest nodes is greater than the sum of the computing power of the cooperating attackers.
2. Transactions
We define an electronic coin as a string of digital signatures: each owner signs a random hash of the previous transaction and the public key of the next owner signature, and this signature is appended to the end of the electronic currency, and the electronic currency is sent to the next owner. The payee can verify the owner of the chain by verifying the signature.
1
The problem with this process is that it will be difficult for the recipient to verify that a previous owner double-spends the coin. The usual solution is to bring in a trusted third-party authority, or something like a mint, to check every transaction to prevent double-spending. After each transaction, the electronic currency will be recovered by the mint, and the mint will issue a new electronic currency; and only the electronic currency issued directly by the mint is considered valid, so that This prevents double spending. The problem with this solution, however, is that the fate of the entire monetary system depends entirely on the company that operates the mint, since every transaction is confirmed by the mint, which is like a bank.
We need some way for the payee to ensure that the previous owner did not sign the transaction that happened earlier. From a logical point of view, in order to achieve the goal, we actually need to pay attention to the transactions that occurred before this transaction, and do not need to pay attention to whether there will be a double-spending attempt after this transaction occurs. The only way to ensure that a certain transaction does not exist is to learn about all previous transactions. In the Mint model, the Mint is informed of all transactions and determines the order in which transactions are completed. If we want to exclude third-party intermediaries in the electronic system, then the transaction information should be publicly announced (publicly announced) [1], we need all participants in the entire system, there is a unique recognized historical transaction sequence. The payee needs to ensure that the vast majority of nodes during the transaction agree that the transaction is the first occurrence.
3. Timestamp server
This solution first proposes a "timestamp server". Timestamp servers add timestamps by randomly hashing a set of data in blocks, and broadcast the random hash, as in news or the worldwide usenet network. Post like [2][3][4][5] . Obviously, the timestamp can confirm that the specific data must exist at a specific time, because the corresponding random hash value can be obtained only when it exists at that time. Each timestamp should incorporate the previous timestamp into its random hash value, and each subsequent timestamp should reinforcing the previous timestamp, thus forming a chain.
2
4. Proof-of-Work
In order to build a set of decentralized timestamp servers on a peer-to-peer basis, it is not enough to just work like a newspaper or a worldwide news network group, we also need a Hashcash proposed by Adam Back [6]. When performing random hashing, the proof-of-work mechanism introduces a scan for a specific value. For example, under SHA-256, the random hash value starts with one or more 0s. Then as the number of 0s goes up, the amount of work required to find this solution grows exponentially, while checking the result requires only one random hash operation.
We add a random number (Nonce) to the block so that the random hash value of the given block has as many 0s as needed. We find this random number by trial and error until we do, so we build a proof-of-work mechanism. As long as the workload consumed by the CPU can satisfy the workload proof mechanism, the information of the block cannot be changed unless the equivalent workload is re-completed. Since the subsequent blocks are linked after the block, if you want to change the information in the block, you need to re-complete the entire workload of all subsequent blocks.
3
At the same time, the proof-of-work mechanism also solves the problem of who is the majority in collective voting. If the way the majority is decided is based on IP addresses, one IP address one vote, then the mechanism is broken if someone has the power to allocate a large number of IP addresses. The essence of the proof-of-work mechanism is one CPU, one vote. The "majority" decision is expressed as the longest chain, because the longest chain contains the largest amount of work. If the majority of CPUs are controlled by honest nodes, then the honest chain will extend the fastest and outperform the competing chains. To modify a block that has already appeared, the attacker must redo the work of the block plus the work of all blocks after it, and eventually catch up with and surpass the work of the honest nodes. We will show later that imagine a slower attacker trying to catch up with subsequent blocks, then the probability of success will decrease exponentially.
Another problem is that the computing speed of hardware is increasing rapidly, and the degree of node participation in the network will fluctuate. In order to solve this problem, the proof-of-work difficulty will be determined using a moving average target, that is, the difficulty is directed to make blocks per hour at a predetermined average rate. If blocks are generated too quickly, the difficulty increases.
5. Network The steps for
running the network are as follows: 1) New transactions are broadcast to
the entire network;
2) Each node incorporates the received transaction information into a block;
Find a proof of work with sufficient difficulty in the block;
4) When a node finds a proof of work, it broadcasts it to the whole network;
5) If and only if all transactions contained in the block are valid other nodes agree with the validity of the block if it has not existed before;
6) Other nodes indicate that they accept the block, and the method of expressing acceptance is to create a new block at the end of the block. blocks to extend the chain, and the random hash of the accepted block is treated as a random hash prior to the new block.
Nodes always consider the longest chain to be the correct chain and keep working and extending it. If two nodes broadcast new blocks of different versions at the same time, there will be differences in the time when other nodes receive the block. When this is the case, they will work on the block that was received first, but also keep the other chain in case the latter becomes the longest chain. The tie is broken until the next proof of work is discovered, and one of the chains is confirmed to be the longer one, then the nodes working on the other branch chain will switch camps and start on the longer chain. work on the chain.
The so-called "new transaction to be broadcast" does not actually need to reach all nodes. As long as the transaction information can reach enough nodes, they will soon be integrated into a block. The broadcast of blocks is fault-tolerant for discarded information. If a node does not receive a particular block, then the node will find that it is missing a certain block and can request to download the block by itself.
6. Incentives
We agree that the first transaction of each block is specialized, which generates a new electronic currency owned by the creator of the block. This increases the incentive for nodes to support the network and provides a way to distribute electronic money into circulation without a central authority to issue the currency. This method of continuously adding a certain amount of new currency to the currency system is very similar to expending resources to mine gold and inject gold into circulation. At this point, CPU time and power consumption are consumed resources.
Another source of incentives is transaction fees. If the output value of a transaction is less than the input value, the difference is the transaction fee, which will be added to the block's incentive. As long as a given amount of electronic money has entered circulation, the incentive mechanism can be gradually switched to relying entirely on transaction fees, and the monetary system can be free from inflation.
Incentive systems also help encourage nodes to remain honest. If a greedy attacker can mobilize more CPU power than all honest nodes combined, he faces a choice: either use it for honest work to generate new electronic money, or use it for binary payout attack. Then he will find that it is more profitable to play by the rules and work honestly. Because these rules allow him to own more electronic money, rather than destroying the system and compromising the validity of his own wealth.
7. Reclaim hard disk space
If the most recent transaction has been included in enough blocks, the data before the transaction can be discarded to reclaim hard disk space. In order to ensure that the random hash value of the block is not damaged at the same time, when the transaction information is randomly hashed, it is constructed in the form of a Merkle tree (Merkle tree) [7], so that only the root (root) is included in the random hash of the block. hash value. Old blocks can be compacted by stubbing the branches of the tree. The internal random hash value does not have to be saved.
4
The block header without transaction information is only 80 bytes in size. If we set the block generation rate to be one every 10 minutes, then the data bits generated per year are 4.2MB. (80 bytes * 6 * 24 * 365 = 4.2MB). In 2008, the usual memory capacity of PC systems was 2GB. According to Moore's Law, it would not be a problem to store all block headers in memory.
8. Simplified Payment Verification
Payments can also be verified without running a full network node. A user needs to keep a copy of the block header of the longest proof-of-work chain, it can keep asking the network until it is convinced that it has the longest chain, and can lead to it via the merkle branch to be timestamped and The transaction included in the block. It is impossible for a node to verify the validity of the transaction by itself, but by tracing back to a certain point in the chain, it can see that a node has accepted it, and the blocks appended after it are further proof The whole network once accepted it.
5
In this case, the verification mechanism is reliable as long as honest nodes control the network. However, when the entire network is attacked by an attacker with superior computing power, it will become more vulnerable. Because network nodes are able to confirm the validity of transactions themselves, as long as the attacker can continue to maintain a computational power advantage, the simplified mechanism can be deceived by the attacker's fabricated transactions. Then a feasible strategy is to send an alert as soon as they find an invalid block, and the user who receives the alert will immediately start downloading the full information of the block or transaction that was warned of the problem, so that the information inconsistency can be corrected. determination. For businesses that have a lot of receipts and payments on a daily basis, they may still want to run their own full nodes in order to maintain a greater degree of independent integrity and speed of verification.
7
9. Combining and Splitting Value
Although it is possible to deal with electronic money individually, it would be a clumsy way to initiate a transaction for each electronic money individually. To make value easy to combine and split, transactions are designed to incorporate multiple inputs and outputs. Generally speaking, it is a single input composed of a previous transaction with a larger value, or a parallel input composed of several previous transactions with a smaller value, but there are at most two outputs: one for payment and the other for payment. Used for change (if any).
It should be pointed out that when a transaction depends on multiple previous transactions, these transactions each depend on multiple transactions, but there is no problem. Because this working mechanism does not need to unfold all the transaction history that happened before.
10. Privacy
6
The traditional mint model provides a degree of privacy protection for transaction participants, as attempts to request transaction information from trusted third parties are strictly limited. However, if the transaction information is broadcast to the whole network, it means that this method is invalid. But privacy can still be preserved: keep the public key anonymous. The only information that the public knows is that one person sent a certain amount of currency to another person, but it is difficult to associate the transaction with a specific person, that is, the public cannot be sure who these people are. This is similar to the information released by the stock exchange. The time and volume of the stock transaction are recorded and available for inquiry, but the identities of both parties to the transaction are not disclosed.
As an extra precaution, users can have each transaction generate a new address to ensure that these transactions are not traced back to a common owner. But some degree of backtracking is unavoidable due to the existence of parallel inputs, which show that the coins all belong to the same owner. The risk at this point is that if one of a person's public keys is confirmed to belong to him, many other transactions of that person can be traced back.
11. Computation
Consider following scenario: an attacker tries to create an alternative blockchain faster than honest nodes can produce the chain. Even if it achieves this goal, the entire system is not completely subject to the arbitrary will of the attacker, such as creating value out of thin air, or looting currency that does not belong to the attacker. This is because nodes will not accept invalid transactions, and honest nodes will never accept a block that contains invalid information. The most an attacker can do is change his own transaction information and try to get back the money he just paid someone else.
The competition between the honest chain and the attacker chain can be described by a Binomial Random Walk. A success event is defined as the honest chain being extended by one block, making its lead +1, while a failure event is the attacker's chain being extended by one block, making the gap -1.
The probability of an attacker successfully filling a given gap can be approximated as the Gambler's Ruin problem. Suppose a gambler has unlimited overdraft credit and begins to gamble a potentially infinite number of times in an attempt to cover his shortfall. Then we can calculate the probability that he fills the gap, that is, the attacker catches up with the honest chain, as follows [8]:
pq
Assuming p>q, then the probability of successful attack is exponential due to the increase of the number of blocks decline. Since probability is the attacker's enemy, if he is not lucky and quick to succeed, his chances of succeeding become slimmer over time. Then we consider how long a payee needs to wait before being sufficiently confident that the payer has had difficulty changing the transaction. We assume that the payer is a payment attacker who wants to convince the payee for a period of time that he has paid, and then immediately repay the payment to himself. While the recipient will find out by then, it will be too late.
The payee generates a new pair of keys, and then only sets aside a short period of time to send the public key to the payer. This will prevent a situation where the payer prepares a blockchain in advance and continues to operate on this block until luck makes his blockchain overtake the honest chain, and the payment is executed immediately. In this case, as soon as a transaction is sent, the attacker secretly prepares a parachain containing an alternate version of the transaction.
The payee will then wait for the transaction to appear in the first block, and then wait for z blocks to link it. At this point, he still doesn't know exactly how many blocks the attacker has progressed, but assuming that honest blocks will take the average expected time to produce a block, the attacker's potential progress is a Poisson distribution with an expected value of :
image022
In this case, in order to calculate the probability of the attacker catching up, we multiply the probability density of the Poisson distribution of the number of blocks the attacker has made progress by the probability that the attacker can still catch up with this number.
pq2 is transformed
into the following form to avoid summing an infinite sequence:
pq3
Write the following C code:
#include 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;
}
Operating on it, we can get the following probability result, finding that the probability decreases exponentially with the value of z.
When 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
When 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 solve the z value for
P<0.1%:
Let P<0.001, then
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
Here we propose an electronic payment system that does not require a credit intermediary. We first discussed the principle of electronic signatures for electronic money in general, although such a system provides strong control over ownership, but is not sufficient to prevent double-spending. To solve this problem, we propose a peer-to-peer network that uses a proof-of-work mechanism to record the public information of transactions. As long as honest nodes can control the vast majority of CPU computing power, it can actually make it difficult for attackers to change transaction records. . The strength of this network lies in the simplicity of its structure. The work between nodes is mostly independent of each other and requires little coordination. Each node does not need to clarify its own identity. Since there are no requirements for the flow path of transaction information, it only needs to do its best to spread. Nodes can leave the network at any time, and it is very easy to rejoin the network, as only the proof-of-work chain needs to be supplemented during the time of receiving the leave. Nodes vote with their CPU computing power for their confirmation of valid blocks, they continuously extend valid blockchains to express their confirmations, and refuse to extend blocks after invalid blocks to express rejection. This framework contains all the rules and incentives required for a P2P electronic money system.
Note (↵ returns to text)
W Dai (大伟), a scheme for a group of untraceable digital pseudonyms to pay each other with money and to enforce contracts amongst themselves without outside help (a scheme for a group of untraceable digital pseudonyms to pay each other with money and to enforce contracts amongst themselves without outside help An electronic cash mechanism that forces individuals to abide by the rules and does not require outside assistance), “B-money”, http://www.weidai.com/bmoney.txt, 1998↵
H. Massias, XS 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. ↵
S. Haber, WS Stornetta, “How to time-stamp a digital document,” In Journal of Cryptology, vol 3, No.2, pages 99-111 , 1991. ↵
D. Bayer, S. Haber, WS Stornetta, “Improving the efficiency and reliability of digital time-stamping,” In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993.↵
S. Haber, WS Stornetta, “Secure names for bit-strings,” In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997. on Computer and Communications Security , pages 28-35, April 1997. ↵
A. Back, “Hashcash – a denial of service counter-measure,” http://www.hashcash.org/ papers/hashcash.pdf, 2002. ↵
RC Merkle, “Protocols for public key cryptosystems,” In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, April 1980.
S. Haber, WS Stornetta, “Secure names for bit-strings,” In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997. on Computer and Communications Security, pages 28-35, April 1997.
H. Massias, XS 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. ↵
W. Feller, “An introduction to probability theory and its applications,” 1957 ↵