leaf

Bitcoin: A Peer-to-Peer Electronic Cash System 8btc.com | Focus on Virtual Economy

Exclusive Sponsor: Bitcoinblogger.com Author Email: [email protected] www.bitcoin.org Abstract: This article presents an electronic cash system fully realized with P2P technology, enabling online payments to be initiated directly by one party and paid to another without the need for any financial institution. Satoshi Nakamoto created the Bitcoin blockchain through the integration of technologies such as timestamps, proof-of-work mechanisms, asymmetric encryption, and UTXO.

We also learned that there are three main technical issues with Bitcoin:

1. The scripting language is too complex, making development difficult;
2. The ecosystem is poorly established, lacking sufficient participants;
3. The scripting language does not meet the "Turing complete" standard, limiting further use.

Finally, we studied the emergence of new virtual currencies. Due to the efficiency issues of the Bitcoin algorithm, Litecoin's blockchain was born. Additionally, to specifically address the scalability issues present in the Bitcoin blockchain, Ethereum blockchain technology emerged in the market.

Although digital signatures partially solve this problem, if you still need third-party support to prevent double spending, such a system will lose its value. We propose a solution that allows the cash system to operate in a peer-to-peer environment and prevents double spending issues. (Hash) adds timestamps to all transactions and merges them into an extended proof-of-work based on random hashes. The proof-of-work chain serves as a transaction record, and the longest chain cannot be altered unless all proof-of-work is redone. The longest chain serves not only as a sequence of observed events but is also seen as coming from the largest pool of CPU computing power. As long as the majority of CPU computing power does not intend to cooperate in an attack on the entire network, honest nodes will produce a longest chain that exceeds that of the attacker. The system itself requires minimal infrastructure. Information spreads throughout the network as much as possible, and when rejoining the network, the longest proof-of-work chain is adopted as proof of transactions that occurred while that node was offline.

1. Almost all online transactions rely on financial institutions as trusted third parties to process electronic payment information. While these systems work well in most cases, they are still inherently constrained by credit-based models (trust-based models). It is impossible to achieve completely irreversible transactions because financial institutions inevitably intervene to coordinate disputes. The existence of financial intermediaries also increases transaction costs, limits the practical minimum transaction size, and daily small payment transactions, and the potential losses are that many goods and services cannot be returned. Without irreversible payment methods, internet commerce is significantly restricted due to the possibility of refunds.

It requires trust between the two parties in the transaction. Additionally, since merchants must also be cautious with their customers, they will ask customers for completely unnecessary personal information. In practical business practice, a certain proportion of fraudulent customers is also considered unavoidable, and the related losses are treated as sales expenses. In the case of physical cash, since there are currently no third-party credit intermediaries, there is a strong need for an electronic payment system based on cryptography rather than credit, allowing any two parties to agree to make direct payments without the involvement of third-party intermediaries. For those who wish to protect buyers, establishing a usual third-party guarantee mechanism in such an environment is easy and pleasant. This article proposes a peer-to-peer distributed timestamp server for generating and recording electronic transaction receipts in chronological order to solve the double spending problem. As long as the total computing power controlled by honest nodes exceeds that of cooperating attackers, the system's security is maintained.

2. We define electronic coins as follows: a string of digital signatures where each owner signs a random hash digital signature on the previous transaction and the public key of the next owner, appending this signature to the end of the electronic currency before sending it to the next owner. The recipient can verify the chain's ownership by validating the signature.

The problem with this process is that the recipient will find it difficult to verify whether the previous owner double spent the electronic currency. The usual solution is to introduce a trusted third-party institution or a mint-like institution to verify each transaction to prevent double spending. At the end of each transaction, the electronic currency is reclaimed by the mint, which issues a new electronic currency. However, the problem with this solution is that the fate of the entire currency system completely depends on the company operating the mint, as every transaction must be confirmed by the mint. We need some method for the recipient to ensure that the previous owner did not sign previous transactions. To do this, we need to focus on the transactions that occurred before this transaction, rather than whether there will be attempts at double spending after this transaction. To ensure a transaction does not exist, the only way is to know all previous transactions. In the Mint model, the mint knows all transactions and decides the order in which transactions are completed. If you want to exclude third-party intermediaries from the electronic system, then transaction information should be publicly announced. We need all participants in the entire system. There exists a uniquely identifiable historical transaction sequence. The recipient needs to ensure that the vast majority of nodes agree that the transaction is the first occurrence during the transaction.

3. Timestamp Server Solution Starting from the "timestamp server." The timestamp server timestamps a set of data in block form by executing random hashes and broadcasts that random hash, just like posting on news or Usenet. Clearly, timestamps can prove that specific data must have appeared at a specific time, as the corresponding random hash value can only be obtained if it existed at that time. Each timestamp should include the previous timestamp in its random hash value, with each subsequent timestamp reinforcing the previous one, forming a chain.

1 W Dai, "B-Money," http://www.weidai.com/bmoney.txt 2 H. Massias, X. S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal trust requirements," in the 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, pp. 99-111, April 1991. 4 D. Bayer, S. Haber, W. S. Stornetta, "Improving the Efficiency and Reliability of Digital Time-Stamping," in Methods in Communication, Security, and Computer Science, Vol. II, pp. 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, pp. 28-35, April 1997.

4. Proof of Work The proof of work must be built on a decentralized timestamp server set up on a peer-to-peer basis; it is not enough to simply work like a newspaper or the World Wide Web. (Adam Back) proposed Hashcash. The proof-of-work mechanism involves scanning specific values while executing random hash operations. For example, in SHA-256, the random hash value starts with one or more zeros. As the number of zeros increases, the work required to find a solution increases exponentially, but only one random hash operation is needed to verify the result. We add a random number (Nonce) to the block, which should make the random hash value of the given block appear with the required number of zeros. We find that random number by repeated attempts until we find it. In this way, we construct a proof-of-work mechanism, and as long as the work consumed by the CPU meets the proof-of-work mechanism, the information in that block cannot be changed unless equivalent work is redone. Since subsequent blocks are linked to that block, changing the information in that block requires redoing all subsequent blocks.

At the same time, the proof-of-work mechanism also solves the problem of who is the majority in collective voting. If the method of determining the majority is based on IP addresses, one IP address equals one vote. Therefore, if someone has the authority to allocate a large number of IP addresses, then the machine's proof-of-work mechanism effectively becomes one CPU one vote. The "majority" decision is represented as the longest chain, as the longest chain contains the most work. If the majority of CPUs are controlled by honest nodes, the honest chain will expand as quickly as possible and surpass other competing chains. If an attacker wants to modify an existing block, the workload of that block plus the workload of all blocks after it must be redone, ultimately catching up and surpassing the honest nodes. We will later show that if a slower attacker tries to catch up to a subsequent block, the probability of success will decrease exponentially. Another issue is that the computational speed of hardware is rapidly increasing, and the degree of node participation in the network is also fluctuating. To address this issue, the difficulty of proof-of-work will be determined using a moving average target. That is, the difficulty point is set to generate blocks at a predetermined average rate per hour. If blocks are generated too quickly, the difficulty increases.

5. Network Operation:

6. New transactions are broadcast to the entire network;

7. Each node chunks the received transaction information;

8. Each node attempts to find a proof of work with sufficient difficulty in its own block;

9. When a node discovers proof of work, it broadcasts it to the entire network.

10. Other nodes only agree if all transactions contained in the block are valid and do not exist before the block is valid;

11. The other nodes indicate that they accept the block, and the method that indicates acceptance follows the end of the block, making a new block added to extend the chain, and the random hash value of the accepted block is considered to precede the random hash value of the new block. The nodes always regard the longest chain as the correct chain and continue to work and lengthen it. If two nodes simultaneously broadcast a different version of the new block, other nodes will receive the block at different times. In this case, they will work on the first block received but will also keep another chain in case it becomes the longest. The tie is broken until the next proof-of-work is found, and one of the chains turns out to be the longer one. Then the node working on the other branch of the chain will switch sides and start working on the longer chain. The new transaction does not need to reach all nodes, as long as it reaches enough nodes. The broadcast of a block is fault-tolerant to discarded messages. If a node does not receive a particular block, it will find that it is missing a block and can make its own request to download the block.

12. Incentive The agreement is that the first transaction of each block is specialized, and that transaction generates a transaction that is generated by the block's creator. This increases the incentive for nodes to support the network and issue money without a central authority. The invention provides a method for distributing electronic money into the circulation field under the condition that a certain amount of new money is continuously added to the monetary system in much the same way that resources are expended to mine gold and inject it into circulation. CPU time and power consumption are the resources consumed. Another source of incentive is transaction fees, where the output of a transaction is less than the input. The difference is the transaction fee, which is added to the incentive for that block. Into circulation, then the incentive mechanism can be gradually converted to completely rely on transaction costs, then the monetary system can be free from inflation swelling. The incentive system also helps encourage nodes to remain honest. If there is a greedy attacker who can mobilize more than all honest nodes add up more CPU computing power, then he faces a choice: either use it for honest work to generate new electronics, or he will find it more profitable to play by that rule and work honestly because the rules allow him to have more electronic money, rather than breaking the system and making his own fortune compromised.

13. Reclaim Hard Disk Space If the most recent transaction has been included in enough blocks, the data before that transaction can be discarded to reclaim hard disk space. To also ensure that the random hash value of the block is not corrupted, when the transaction information is randomly hashed, it is constructed as a Merkle tree such that only the root is included in the random hash value of the block. The old block can be compressed by stubbing the branches of the tree. The internal random hash value is not necessary to be saved.

Block header without transaction information The size of the Block header is only 80 bytes. If we set the block generation rate to one every 10 minutes, then 4.2 MB of data bits are generated per year. (80 bytes * 6 * 24 * 365 = 4.2MB). In 2008, the typical memory capacity of PC systems was 2GB, and Moore's Law predicted that even storing all block headers in memory would not be a problem.

8. Simplified Payment Confirmation A user needs to keep a copy of the block header of the longest proof-of-work chain, and it can keep asking the network until it is convinced that it has the longest chain. It would have been impossible for a node to check the validity of the transaction itself, but by tracing back somewhere in the chain, it could see that a node had accepted it, and that the block appended to it was further proof that the network had accepted it.

In this case, as long as honest nodes control the network, the verification mechanism is reliable. However, when the entire network is attacked by an attacker with superior computing power, it becomes more vulnerable because network nodes can confirm the validity of transactions themselves. As long as the attacker can maintain a computing power advantage, the simplified mechanism can be exploited by the attacker to forge fraudulent transactions. One possible strategy is to send alerts once they discover invalid blocks, and users receiving the alert will immediately start downloading the complete information of the blocks or transactions that have been warned as problematic, allowing them to identify inconsistencies. For businesses that have large amounts of funds flowing daily, it may still be preferable to run their own complete nodes to maintain greater independent integrity and verification speed.

9. Value Combination and Splitting Although electronic currency can be handled individually, initiating transactions for each type of electronic currency is cumbersome. To make value easy to combine and split, transactions are designed to merge multiple inputs and outputs. Generally, an input consists of a previous transaction of a larger value, or a parallel input consists of several previous transactions of smaller values. However, there are at most two outputs: one for payment and one for change (if any). It should be noted that while one transaction depends on multiple previous transactions, each previous transaction depends on multiple transactions; this is not a problem because the mechanism does not require expanding the history of all previous transactions.

10. Privacy

The traditional mint model provides a certain degree of privacy for transaction participants, as attempts to obtain transaction information from trusted third parties are strictly limited. However, broadcasting transaction information to the entire network means this approach is ineffective. But privacy can still be protected: by keeping public keys anonymous, the public only knows that someone issued a certain amount of money to another person, but it is difficult to link transactions to specific individuals. That is, the public finds it hard to determine who these people are, just like the information published by stock exchanges, where the time and amount of each stock sale are recorded and available for inquiry. However, the identities of the transaction parties are not disclosed. As an additional precaution, users can generate a new address for each transaction to ensure that transactions cannot be traced back to a common owner. However, due to parallel inputs, some degree of traceability is unavoidable, as parallel inputs mean that the currency belongs to the same owner. The risk is that if one person's public key is identified as belonging to them, many other transactions can be traced back to that person.

11. Computational Assumptions Consider the following situation: an attacker attempts to create an alternative blockchain faster than honest nodes create their chain. Even so, the system does not completely succumb to the attacker, creating value out of thin air or plundering money that does not belong to the attacker. This is because nodes will not accept invalid transactions, and honest nodes will never accept blocks containing invalid information. What an attacker can do at most is change their transaction information and attempt to reclaim the money they just paid to someone else. The race between the honest chain and the attacker's chain can be described as a binary random walk. A successful event is defined as the honest chain extending one block, leading it ahead by +1, while a failure event is the attacker's chain filling the gap.

The probability of the attacker successfully filling the gap can be approximated as the gambler's ruin problem. Suppose a gambler has infinite overdraft credit and starts making infinite bets to try to fill the gap; we can calculate the probability of them filling the gap, that is, the probability of the attacker catching up to the honest chain, as follows: =𝑝 the probability that an honest node generates the next node 𝑞= the probability that the attacker generates the next node 𝑞𝑧= the probability that the attacker ultimately closes the gap of z blocks.

If the payer does not have enough luck to succeed quickly, their chances of success will diminish over time. Let us consider how long the recipient must wait to be sufficiently convinced that the payer has made the transaction difficult to alter. Let us assume the payer is a payment attacker who wants to make the recipient believe they have paid for a while. Then, they immediately repay the payment to themselves. Although the recipient will discover this at that time, it will be too late. The recipient generates a new key pair and has a short time to send the public key to the payer. This prevents the following situation: the payer prepares a blockchain in advance, continues to run that block until luck allows their blockchain to surpass the honest chain. In this case, once the transaction is issued, the attacker secretly prepares a parallel chain containing an alternative version of the transaction. The recipient then waits for the transaction to appear in the first block and then waits for z blocks to follow, at which point they still do not know how many blocks the attacker has advanced, but assuming that honest blocks will take an average expected time to generate a block, the attacker's potential progress is Poisson distributed, with an expectation of

In this case, 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 progressed by the probability that the attacker will still catch up to that number.

By simplifying it to the following form, we avoid summing over infinite series:

Write the following C code:

#include <stdio.h>

double attacker_success_probability(double q, int z) {
    double p = 1 - q;
    double sum = 0;
    for (int k = 0; k <= z; k++) {
        sum += (poisson(k, z) * pow(q / p, z - k));
    }
    return sum;
}

Based on this, we can obtain the following probability results and find that the probability decreases exponentially with the value of z.

12. Conclusion

Here we propose an electronic payment system that does not require credit intermediaries. We first discuss the electronic signature principles of traditional electronic currency. While this system provides strong control over ownership, it is insufficient to prevent double spending. To address this issue, this article proposes a P2P network with a proof-of-work mechanism that records public information of transactions. As long as honest nodes can control the majority of CPU computing power, it is difficult for attackers to modify transaction records. The robustness of the network lies in its simple structure, where most of the work between nodes is independent of each other, requiring minimal cooperation. Each node does not need to identify itself, there are no requirements for the flow path of transaction information, and it only needs to spread as much as possible. Nodes can leave the network at any time, and since they only need to supplement the proof-of-work chain during their absence, rejoining the network is very easy. Nodes vote to confirm their valid blocks through their CPU computing power, and they continue to extend the valid blockchain to represent their confirmation, rejecting the extension of blocks after invalid blocks to indicate rejection.

This framework contains all the rules and incentives necessary for a P2P electronic currency system.