Author: Satoshi Nakamoto Translator: Jin Xiao Abstract: A purely peer-to-peer version of electronic cash (cash) allows online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution to this scenario, but if a trusted third party is still needed to prevent double spending (double spend), then existing solutions still lack major benefits (are not good enough). This network timestamps transactions by hashing them into an ongoing chain of proof-of-work (PoW) based on random numbers. The longest chain not only provides proof of the sequence of events observed but also proves that this chain comes from the largest pool of CPU computing power. As long as the majority of CPU power is not controlled by nodes with malicious network properties, they will grow to become the longest chain and surpass those attackers.
The network itself requires very little structure. Information is broadcast in the most efficient way, and nodes can leave or join the network at any time. These nodes accept the longest PoW chain as proof of what happened while they were away from the network. The abstract points out that existing technologies make sending a transaction via P2P reliable, and the method is through digital signatures, which implicitly indicates that Bitcoin also uses digital signatures to ensure transaction delivery. However, it then points out that digital signatures cannot solve double spending because a digital signature can only guarantee that the item belongs to the sender, but there is no way to ensure that the item will not be sent to someone else after being sent to one person, as data can be copied. The existing solution is that both the sender and receiver trust a third party as an intermediary. This third party records that A has an item and gives it to B to complete a transaction. In other words, this third party has absolute authority, and A and B can only transact because they "trust" this third party. It then gives a broad introduction to the blockchain system, highlighting several key points: timestamps, hashes as identifiers, the use of hash-based proof of work, and the chain together. Providing the order of events indicates that blocks are "recording history," and the chain comes from the largest CPU power, indicating that it is unique and cannot be overturned under the rules of CPU power proof. Finally, it states that the structure of the blockchain is streamlined, and nodes are flexible, implying that this is a smart system of multi-node intelligent cooperation (even though each node is limited in intelligence, all nodes follow a simple set of rules, allowing the entire system to exhibit tremendous power).
- Introduction Most of the trade on the internet currently relies on a financial institution to provide third-party trust to process electronic payments. Although this system works well for most transactions, it still faces inherent flaws based on the trust model. Complete irreversible transactions are not truly possible because financial institutions cannot avoid dispute resolution. The cost of coordinating mediation increases the cost of transactions, limits the minimum practical transaction size, and cuts off the possibility of small, ad-hoc transactions. Moreover, there are greater costs in the weak aspects of irreversible payments for irreversible services. Because of the possibility of revocation, the need for trust is dispersed.
Merchants need to be vigilant about their customers, so they collect more information than necessary. A certain percentage of fraud is seen as possible. This cost and uncertainty in transactions can be avoided when a person conducts transactions in cash, but there is no existing mechanism to ensure that transactions are conducted through a communication channel without a trusted party.
This section reflects that blockchain is designed to solve the trust issue because the existence of third-party institutions creates a naturally existing problem of trust. Existing mechanisms incur significant costs in maintaining this trust. On the other hand, blockchain embodies irreversibility and immutability, indicating that these two characteristics are inherently possessed by blockchain. More accurately, this reflects the disruptive reason for the emergence of blockchain. Looking back at the current technological developments, the computer has led the third information revolution, enabling information to flow rapidly across networks. However, while the internet allows information to flow quickly, it cannot achieve material transfer similar to that in the real world. This is because information is virtual, while material in reality is a tangible entity. It is precisely because the internet is virtual that if an object is simulated in a virtual world, it can be copied without limits, but at the same time, it cannot simulate the transfer of material in reality. For example, if A wants to give B an item, in the real world, it is a tangible transfer of an item, while in the virtual world, it is a record of a message, and this message can be recorded by A, B, or a third party. Clearly, whether recorded by A or B, it is impossible for both A and B to simultaneously agree because they can both privately alter this record and breach the contract, so they would seek a third party to act as a guarantor (such as a notary, intermediary, etc.). A and B both entrust their trust to this third-party institution as a guarantee, allowing the entire system to operate together.
Thus, the current simulation introduces a trusted third-party institution, where people entrust their trust to this third party and believe that this third party guarantees the uniqueness and transfer of simulated items (cannot be copied). Whether this third party is truly trustworthy is the cost incurred by the operation of this system. This is the "natural defect" of the current system. Therefore, if we want to use the internet to simulate material transfer in reality, linking real-world items with virtual items without needing a third party as a guarantee for this transfer, then we need to introduce the blockchain mechanism. Blockchain can make material transfer as quick and convenient as information flow, while also being guaranteed by the collective of all participants (the collective guarantee of all participants is equivalent to a naturally existing non-falsifiable guarantee, unless 51% of the people collude to breach the contract), ensuring the reliability of material transfer in the virtual world. I believe this is the core reason why "blockchain" technology is expected to lead the "fourth technological revolution."
What is now needed is an electronic payment system based on cryptographic proof to replace trust, allowing any two parties to transact directly without needing a trusted third party. Computationally guaranteed irreversible transactions will protect sellers from fraud, and conventional escrow mechanisms can be easily implemented to protect buyers. In this paper, we propose a solution to the double spending problem using a P2P distributed timestamp service to generate computational proof of the transaction's chronological order. The entire system is secure as long as honest nodes control more CPU computing power than colluding attack nodes. It points out that the trust issue is actually transferred from the original coercive force of the state (banks), the size of enterprises (WeChat, Alipay), or other trust to the "cryptographic encryption" mathematical system, becoming a question of whether to believe that mathematics is reliable.
However, the last sentence implies that the blockchain system actually has a slight advantage for the payer over the payee, indicating that the payee needs to worry about the payer's attack (double spending). Finally, it states that blockchain solves double spending, with the basic topology being P2P, and timestamps being the method to confirm transaction order.
- Transaction We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next person by digitally signing (private key signing) the hash of the previous transaction and the public key of the next person, and appending this signed result to the end of the coin. A recipient can verify this signature to ensure the chain of ownership. This statement in the original text is somewhat counterintuitive. The first sentence originally states, "We define an electronic coin as a chain of digital signatures," which means "define coin as chain." This is a strange thing because intuitively, a coin should be one by one, while a chain is a series, making it difficult to connect coin and chain.
However, Bitcoin is essentially a chain, and this chain is formed by transactions in the order they occur, while the coin does not exist in itself; the coin is inferred from the transactions on the chain, and there is no direct appearance of a coin. At the same time, based on the previous description, giving a coin to the next person is done through digital signatures, meaning proving the source and destination of the coin through public and private keys. Suppose A wants to give B a coin, then this process becomes a transaction (as shown in the middle Tx in the figure), this transaction records how much coin B receives and B's public key (indicating the destination), while also providing A the ability to operate on the previous transaction (such as the first Tx in the figure. For example, this Tx records that X gave A some money, which means A can operate on the output of the transaction from X to A), and after hashing these two together, the payer A uses their private key to sign this hash and then adds it to the transaction. After that, this transaction is widely broadcast to other places. At this point, as an observer (miner), they have all the transactions prior to the first transaction locally, so when they see this transaction (the middle Tx), they can use the public key of payer A (referring to the first transaction, A's public key obtained from the first transaction) to verify the signature of this transaction (the middle transaction) to confirm whether this transaction was initiated by payer A (because only A holds the private key, and only a signature signed with A's private key can be verified against the previous transaction (the first transaction), proving that A can operate on the first transaction and possesses the money transferred from X to A). This thus proves that this transaction was initiated by payer A.
Let's take the middle Tx (transaction) as a reference. This Tx is initiated by Owner 1, as can be seen in the figure, the hash input is the previous Tx (prev Tx) and the public key of the next recipient (next owner's pub key), and this hash result is signed by Owner 1's private key and appended to the current transaction. Do not connect this with the next Tx yet; when Owner 1 finishes signing this Tx, they broadcast this transaction, and once a miner packages this transaction into a block and chains it onto the honest chain (the longest chain), it indicates that this Tx is established. Therefore, at this point, Owner 2 will not know immediately whether it was successful like a normal transaction; instead, they need to wait for a while to "check" (this is a very simple statement, it can also mean there is something to poll, as long as the transaction is packaged, it will notify Owner 2) whether this transaction has been packaged, and if so, it means the transaction was successful. The problem with this process is that the recipient cannot verify that the payer (one of the owners) has not double spent the currency.
A common solution is to introduce a trusted central authority or mint to check each transaction for double spending. After each transaction, the currency must be returned to the mint to issue a new coin, and only currency issued directly from a trusted mint can ensure it is not double spent. The problem with this solution is that the fate of all currency relies on the operation of this mint, and every transaction must go through them, just like a bank. The term mint here is initially difficult to understand; in fact, it is a very simple phenomenon, but this process is so straightforward that no one notices that the current system operates this way. For example, in today's online banking (or Alipay), when A transfers 100 yuan to B, it is actually the bank that initiates a transaction, deducting 100 yuan from A's account and adding 100 yuan to B's account. This -100 and +100 are essentially the bank's "mint," destroying A's 100 yuan and then producing 100 yuan for B (but the entire process is only reflected in the flow of information).
Because of this, it is necessary to ensure that this "currency" can only be issued from this "mint" (bank), and that this "mint" is mutually trusted by both parties, and every transaction must "go through" this "mint" without any other means. The existing system is also guaranteed by the bank's "mint" (the only trusted party) that while A's account is -100, only B's account is +100 and C's account will not also be +100 (double spending). (Of course, if the bank colludes with A secretly, when A transfers 100 yuan to B, C's account will also be increased by 100 yuan, resulting in double spending. Of course, it seems that this will not happen now because of the bank's own "supervision" system, such as daily reconciliations, internal bank supervision, etc. The cost of this supervision is the cost of maintaining this system. The reason the bank can know whether a sum of money has been double spent is that the bank has all the "historical transactions" prior to the current transaction. Its method of verifying whether a transaction is legitimate is to check whether the results of all previous transactions meet the requirements of the current transaction. We need to give the recipient (payee) a way to know that previous owners (owners) have not signed an earlier transaction.
For this purpose, the earliest transaction is important, so we do not need to worry about whether subsequent transactions attempt to double spend. The only way to ensure the existence of a transaction is to have the ability to query all transactions. In the mint model, this mint has all transactions and decides which transaction arrived first.
To accomplish this without a trusted party, transactions must be publicly announced, and we need a system that allows all participants to reach a consensus only on a single chain of historical order (which they were received).
The recipient needs to prove that during each transaction period, the majority of nodes agree that this was the first received. It points out that first, the payer is the one who would commit double spending, while the recipient is concerned about whether the payer will do this (obviously, because the interest is transferred from the payer to the payee). "The earliest transaction is important" means that the basis for double spending is that there must have already been a transaction, and then the payer wants to ignore this transaction and use the currency that has already been used in this transaction to initiate another transaction. Therefore, this earliest transaction refers to "the transaction that has already occurred." The mint does not care which of the two (or more) transactions the payer believes occurred first; it only cares whether the transaction initiated by the payer at this moment is "legitimate" (that is, whether this person has already used this money). Therefore, the mint confirms which transaction is first, rather than the payer deciding which is first. Now, if this mint does not belong to any third party, then this transaction must be "widely announced," allowing everyone involved to know that this event has occurred, and everyone knows all previous "historical events" to verify whether the transaction being broadcast is legitimate. However, we know that getting all participants to maintain consistency is a very difficult task, which is the problem that blockchain solves. The last sentence states that the recipient needs a majority (over 51%) to consider that transaction legitimate for it to be deemed legitimate.
- Timestamp Server We propose a solution starting from a timestamp server. The job of a timestamp server is to timestamp the hash result of a block formed by a set of data (items) and widely broadcast this hash, just like posting in a newspaper or a global news group (Usenet). This timestamp proves that at that time, this data must have existed; obviously, to get this hash (it can only be at that time). Each timestamp includes the previous timestamp in its hash, forming a chain, with each new timestamp reinforcing all previous timestamps before it. This part explains the work done by miners. This set of data refers to many transactions, and then this set of data is packaged into a block, timestamped, and hashed to ensure the chronological order, which is to complete the "ensure historical order" introduced in section 2. Because obtaining this hash is linked to the timestamp at that time, this hash marks the time.
Since these blocks form a chain, and the growth of blocks is proof of CPU power (described later), the hash-> reflects the timestamp-> hash is chained together-> a new block on the chain requires CPU-> thus the previous hash must be correct (constantly reinforcing credibility).
This diagram illustrates the connection between time and blocks, blocks and hashes, and how these hashes are linked together due to the nature of the blockchain, so the previously linked timestamps are immutable.
4. Proof of Work#
A P2P-based distributed timestamp server will require a proof-of-work system similar to Adam Back's Hashcash, rather than using newspapers or global news groups. The proof-of-work mechanism introduces scanning for a value when hashing, for example, starting from a string of 0 bits under SHA-256. The average work required is the exponent of the number of required 0 bits and can be verified by executing a single hash. This section is another core part of the Bitcoin blockchain, widely known as PoW. In the previous chapters, it was mentioned that first A and B had a transaction, then this transaction was broadcast, and since there is no third party, the participants are all nodes on the network. These nodes, upon receiving this transaction and many others, package them into a block and timestamp it with a hash. Now the question arises: if these observing miners receive many transaction messages and each package their own block, how can consensus be reached across the network?
Assuming miners C, D, and E all received transaction messages, and because the transaction messages they received are not completely consistent and the times are not entirely the same, the resulting block hashes will certainly differ greatly. Anyone with P2P experience knows that at this point, it is necessary to ensure that C, D, and E ultimately reach a consensus, so that the entire network can agree on the "historical order of events" that occurred in the blockchain; otherwise, the entire system would be useless. Satoshi Nakamoto's method here is to introduce PoW to allow C, D, and E to use "CPU power" as a probabilistic method to compete for the right to record the block (commonly known as "accounting rights"). The original text's scan refers to brute-force enumeration. For SHA-256, given current cryptography, to meet a certain condition, brute-force enumeration is the only way to achieve it. Clearly, the speed of "brute-force" is determined by the CPU's computing power, and the scale of brute-force is the "difficulty" of this PoW mechanism.
Enumerating this value is a "probabilistic" event (imagine how one would brute-force crack an unknown password of a compressed file), but because it requires a considerable number of enumerations, the final average result is indeed measurable (this is the expected value of probability; in some mining pools, this is approximately referred to as the lucky value? Not too sure). For our timestamp network, we implement this proof of work by adding a nonce to the block until a value that meets the required number of 0-bits (bit count) for the block's hash is found.
Once CPU efficiency is spent as proof of work, this block cannot be changed to redo the corresponding work. Afterward, the block is chained to the one following it, and changing this block would require the work needed for all blocks following this block. The way to "guess" the value that meets the requirements for this block is to change the nonce here. (Because for hash functions, any small change will result in a completely different outcome. The way to obtain a satisfactory value is to continuously change the nonce so that the hash of the entire block meets the difficulty requirement.) Thus, this nonce represents the labor (CPU power, electricity costs) "proof" expended by this miner to seize the "accounting rights" for this round of blocks. Therefore, the nonce can be directly viewed as "proof of labor (work amount)." The latter part explains that if there is a change in the block, then this hash will change, and it will require recalculating this block's nonce, meaning that to change the previous block, all blocks needed for this round must be recalculated (expending all necessary labor) to achieve this.
This diagram is similar to the previous one, but here it emphasizes the content of each block, indicating that a block contains the hash of the previous block (Prev Hash), and the Nonce is a part of the block. Once the Nonce, Prev Hash, or any Tx is changed, the hash of this block will also change, and all subsequent blocks will need to be changed. Proof of work also solves the issue of representation in majority decisions. If the majority of people vote based on one person one IP (one-IP-one-vote), this can be undermined by anyone who can allocate many IPs. Proof of work is essentially one CPU one vote (one-CPU-one-vote). The main (majority) decisions are represented by the longest chain, which has the most work invested in it. If a majority of CPU power is controlled by honest nodes, then the most honest chain will grow the fastest and surpass any other computational chain.
To change a past block, an attacker must redo the proof of work for that block and all blocks following it, and then catch up and exceed the work of all currently honest nodes. We will later show that the likelihood of a slow attacker catching up will decrease exponentially as subsequent blocks are added. This section adds that PoW is essentially a collective decision-making representation issue, equivalent to the problem of seizing accounting rights, because seizing accounting rights means selecting a representative.
This section also mentions why Satoshi Nakamoto did not consider using IP as a decision-making factor, as he believed that using IP as voting rights is much easier than using CPU as voting rights (whether this is the best choice is unknown, but it seems to be the best choice at present; however, the current CPU voting rights are controlled by "mining pools," which has caused instability to some extent (but still much better than controlling IP). Of course, some mining pools publicly announce that their computing power does not exceed a certain value to maintain the stability of the entire system (I will add the link once I find this news)).
The article then emphasizes again that to change a block, an attacker will have to expend a tremendous cost, and the honest chain, due to the rules it advocates, will naturally become the longest chain in the game (this will be described later). To compensate for the continuously increasing speed of hardware and the changing interests of operating nodes over time, the difficulty of work is determined by a moving average target, which is the average number of blocks per hour (this average target). If the increase in computing power is too rapid, this difficulty will increase.
This section points out that the difficulty of PoW increases with the overall system's difficulty because the computing power of computers is constantly improving. Think about the evolution from CPU mining to GPU mining to ASIC mining; this is the brilliance of PoW. However, this also brings a reason for skepticism about Bitcoin: the current computing power is too high due to the large number of participants, and the difficulty has increased significantly, with overall computing power rising sharply in recent years. So, if several years later, the incentives generated by Bitcoin (mentioned later) cannot bear the cost of such high computing power, will it cause a cliff-like drop in computing power? This could lead to a collapse of Bitcoin's credibility (where those who can control computing power attack) and result in a sudden crash of Bitcoin.
5. Network#
The steps to run this network are as follows:#
-
New transactions are broadcast to all nodes.
-
Each node collects the new transactions into a block.
-
Each node works on its block to find the proof of work for that block.
-
When a node finds the proof of work for this block, it broadcasts this block to all nodes.
-
Nodes will only accept this block if all transactions in this block are valid and have not been spent.
-
Nodes move to the proof of work for the next block and use the hash of this block as the previous hash for the next block to indicate acceptance of this block. Nodes always consider the longest chain to be correct and continuously work to extend it. If two nodes simultaneously broadcast different versions of the next block, some nodes will receive one of the blocks first; in this case, they will work on the first block they received, but keep the other block in case it becomes longer. This tie will be broken when the next proof of work is discovered, at which point one branch will become longer. Nodes working on other branches will switch to this longest branch. This section implicitly indicates Bitcoin's "maximal rule," which is that everyone defaults to the longest chain being correct. If this cannot be guaranteed, it is easy to imagine that the entire system cannot function. The correctness of this longest chain is guaranteed by the subsequent "incentive mechanism," creating a game scenario: if one wants to create a blockchain application now, either everyone must agree on a rule (coercive force), or some method must be used to allow people to voluntarily agree on a rule (incentives). However, because competing for blocks incurs costs, how to engage in a game of "coercive force/incentives" regarding this cost is key to whether a blockchain can grow healthily.
The latter part explains the key to a block being recognized: if miners (the majority) take this block as the previous block and incorporate it into a new block's hash and work for the new block, then this block is recognized. Thus, it indicates that only when the next block is produced is the current block "legitimate." This is quite critical because all attacks will target this issue, and the imbalance between the recipient and the payer is also caused by this. This section also embodies the essence of game theory in blockchain applications.
The latter part describes a special situation, stating that due to the characteristics of distributed networks, information communication is not real-time, so some nodes may recognize one block while others recognize another block, causing the blockchain to fork. However, it explains that since all nodes believe that only the longest chain is the only chain, this situation will be broken after several blocks in multiple chains, resulting in block reorganization.
Broadcasting new transactions to all nodes is unnecessary. As long as the transaction reaches many nodes, they will enter a block (in the longest block before long). Block broadcasting has the ability to tolerate information loss. If a node does not receive a block, it will discover its absence when it receives the next block and request the missing block.
This section is a supplement to the previous one, explaining the importance of 51% (the majority). This majority does not manifest as an intuitive number but is slowly iterated out as everyone recognizes the longest chain over time. At the same time, it mentions a key point: "Broadcasting new transactions to all nodes is unnecessary," which clearly indicates that transactions do not need to be flooded. Because to spread the information of the transaction itself, in the blockchain system, not only can transactions be spread, but blocks can also be spread. The spreading of blocks is the "rule" in the system (to reach the longest chain). I believe this can bring some new thoughts in distributed systems.
6. Incentive Mechanism#
By convention (agreement), the first transaction in a block is a special transaction, where the creator of this block owns a new currency. This provides an incentive mechanism for nodes to support this network and offers a way to initialize the distribution of currency into the entire system. Since there is no central authority to issue them (currency), steadily increasing a certain amount of new currency is similar to gold miners spending resources to mine gold and introduce it into the circulation system. In our context, CPU time and electricity are the resources being spent. This section finally addresses a question that has been avoided earlier: where does the currency come from? In the Bitcoin system, Satoshi Nakamoto has set a total limit of 21 million bitcoins. The production of these bitcoins is halved every 21,000 blocks (currently, it is approximately every 10 minutes to produce a block, which will reach 0 around the year 2140). The method of producing bitcoins is to give a certain amount of currency to the person who seizes the accounting rights, thus simultaneously solving the issues of currency issuance and miner rewards (just like gold miners in reality).
This method of granting currency out of thin air is the first transaction in each block, which is a special transaction that only has input and has an empty output for the input of this input (the output of the previous transaction) (this will be mentioned later). As stated in the annotation of Chapter 2, coins do not exist; coins are inferred from transactions. Just like A giving B 100 yuan, when recording this information, it can record A's "account -100, B's account +100" or record "A gave B 100 yuan" as a transaction information.
The blockchain chooses the latter. This currency that appears out of thin air is a special transaction information. This incentive mechanism can also reward miners through transaction fees. If the output value of a transaction is less than its input value, then this difference is the transaction fee, and the fee is added to the reward of the block containing this transaction. Once a fixed number of currencies (all currencies) enter this circulation, this incentive mechanism can completely transform into transaction fees, and this system can completely avoid inflation (the total amount of currency is fixed, and no new currency is issued). This part explains another aspect of the incentive mechanism, which is that besides the out-of-thin-air reward, transaction fees are also a source of income for miners. The incentive mechanism may help encourage nodes to remain honest.
If a greedy attacker can gather more CPU power than all honest nodes, they face a choice: either use this power to double spend and deceive others or use the power to generate more currency. They should find that following the rules can yield more benefits, as these rules support them to have more currency than others who join in, rather than destroying the system and harming their own wealth. This reflects the game relationship discussed earlier.
7. Reclaiming Disk Space#
Once a currency's latest transaction is buried into enough blocks, the transactions that were consumed before this transaction can be discarded to save disk resources. To ensure that the hash of the block is not compromised, transactions are hashed into a Merkle Tree, where only the root node is included in the hash of this block. Old blocks can be compressed by stubbing off branches of this tree. The internal hashes do not need to be saved.
This section addresses a solution to the problem of continuously generated blocks in the blockchain system. As of now (January 28, 2017), the total number of blocks has exceeded 90GB. Although storage is becoming less expensive, it is impossible for the general public to use it because information is continuously expanding. This reflects the brilliance of the blockchain system; it does not store transactions but uses the Merkle Hash Tree to store the Root Hash, achieving "zero-knowledge proof." Individuals do not necessarily need this block, but having the "hash" (index) of this block is sufficient, with IPFS, public nodes, and highly trusted nodes helping to store these blocks. "Zero-knowledge proof" guarantees that the block is absolutely correct and not forged.
A block that excludes transactions is approximately 80 bytes in size. If we assume that a block is generated every 10 minutes, then 80 bytes * 6 * 25 * 365 = 4.2MB per year. In 2008, the typical memory capacity of PC systems was 2GB, and according to Moore's Law, it is predicted to increase by 1.2GB each year. Even storing all block headers in memory is not a problem. The original text has already discussed this quite clearly.
8. Simplified Payment Verification#
Verifying payments does not require running all network nodes.
A user only needs to keep a copy of the block headers of the longest proof-of-work chain; this chain only needs to query network nodes until they are convinced they have the longest chain and can connect to it through the Merkle branches to the block that timestamps their transaction. They cannot check this transaction themselves (because it is only a hash), but by connecting to the position in the chain, they can see that a network node has previously accepted it (the transaction), and the blocks added afterward further prove that the network has received it. The issue brought by reclaiming disk space is the problem of simplified payment verification, as some nodes may no longer hold all block information, which is essentially a game, trading space for verification convenience. However, it will not compromise the security of the information. As long as they hold the hash as an identifier, any node can always request the original information from other nodes.
This diagram indicates that as long as there is a hash chain, it is sufficient.
In this scenario, if honest nodes control the network, then this verification is reliable. However, when a power-dominant attacker controls the network, it becomes more susceptible to attack. Because when nodes in the network can verify themselves, this simplified method can be deceived by fabricated transactions when the attacker can continuously guarantee more than the total network's computing power.
One protective strategy is to accept warnings from network nodes when these nodes detect an illegal block, alerting user software to download the entire block with issues and warning transactions to check for consistency. Commercial institutions that frequently receive payment information may still run their full nodes to maintain greater independent security and faster verification. This mechanism feels somewhat like a patching method. However, it seems to be a solution to reduce disk storage, resulting from a trade-off between storage and security convenience. There may be opportunities to write articles here, perhaps an obstacle to the promotion of blockchain applications. Because if too few nodes retain the blocks, it could cause problems. Although it cannot steal or tamper with the network, it could lead to a collapse. (Of course, this does not refer to the Bitcoin network but to some smaller blockchain networks.)
9. Combining and Splitting Value#
While it is possible to handle currency independently, it is unwise for every penny in a single transfer to become a separate transaction (meaning coins are not combined from unit amounts). To allow value to be split and combined, transactions include multiple inputs and outputs. Normally, there will be a single input from a large transaction or many smaller total inputs, and then there will be two outputs, one for payment and the other for change, returning all to the purchaser regardless of how many there are.
This section finally discusses the composition of a transaction (Tx). The previous discussions have already said a lot; just grasping one key point is new: a transaction is verified by previous transactions, plus the amount transferred and the destination. Inputs are the outputs of previous transactions. By verifying all inputs, one can determine whether the payer's balance is greater than the amount to be transferred.
All Tx associated with inputs are the previous "historical information," and nodes can retrieve results from their blocks. The first transaction in each block (the incentive transaction) is equivalent to having only input and no output. An additional point to note here is that each transaction must be fully spent; it is just the total of all inputs, part of which goes to the payee, while the change is returned entirely to the purchaser (recalling the workflow of the mint mentioned earlier).
This mechanism has a natural advantage in the division of numbers. Existing currencies always have a minimum unit as a "base" unit (for example, in RMB: 1 cent), but Bitcoin does not have such restrictions; it only cares about the difference and does not care about the smallest unit. Thus, this is the combination and division of value.
It should be noted that the entire distribution (fan-out) relies on several transactions, and these transactions rely on even more. This is not a problem. There is no need to extract a complete independent copy of the transaction history. This is slightly difficult to translate; I am not very clear about what "fan-out" refers to here.
10. Privacy#
The traditional banking model achieves levels of privacy by restricting access to information for relevant participants and third parties. When all transactions need to be publicly broadcast, this method cannot be used. However, privacy can still be maintained by breaking the information flow elsewhere: by anonymizing public keys. The public can see that one person has sent a certain amount to another person, but no information can link the transaction to the person. This is similar to the level of information released in stock trading; in stock trading, the time and individual transactions released publicly are recorded on the "tape," but it does not disclose who participated.
This section points out that using the public-private key mechanism is a form of pseudo-anonymization.
As an additional firewall (preventive mechanism), using a new key pair for each transaction can ensure that these keys are not linked to one person. Some multi-input transactions' connections are still unavoidable because at this point (multiple inputs) reveal that these inputs belong to the same person. The risk is that if one key's owner is discovered, then other transactions associated with that person will also be revealed.
The original text recommends doing this for a good reason. Because elliptic curve encryption can be broken by quantum brute force, if the public keys generated in the entire system are exposed.
Although cryptographically, one should not derive a private key from a public key, there are still exceptions. Therefore, Satoshi Nakamoto strongly recommends using a new pair of keys for each transaction (because once a transaction is used as inputs, the transaction as inputs is no longer useful (note the change mechanism mentioned in 9, every transaction must be fully spent)), ensuring that every transaction uses a new public-private key. The latter part discusses the issue of the correspondence between public-private keys and real people (loss of anonymity). Changing keys can also prevent this from happening, but it should be noted that because all records are publicly traceable, if one public-private key corresponds to a person, then all associated public-private keys can also correspond to that person.
11. Computation#
We consider a scenario where an attacker attempts to generate a replacement chain longer than the current honest chain. Even if this is feasible, it does not imply that the system is under arbitrary control, such as creating value out of thin air or taking money that does not belong to the attacker. Nodes will not accept invalid transactions as payments, and the most honest chain will never accept a block containing invalid information. An attacker can only attempt to change their own transaction to reclaim money they recently spent. The competition between the most honest chain and the attacker's chain can be viewed as a Binomial Random Walk. Successful events occur when the most honest chain expands a block, leading to a +1 lead, while failure events occur when the attacker's chain expands a block, resulting in a -1 gap. The probability of an attacker catching up with a given loss can be viewed as a Gambler's Ruin problem. Assume an unlimited credit gambler starts from a loss and potentially attempts to catch up to break even an unlimited number of times. We can calculate the probability of them reaching break even, which is the probability of an attacker catching up to the most honest chain, as follows:
P = Probability that the honest chain discovers the next block
q = Probability that the attacker discovers the next block
qz = The attacker has spent z blocks catching up
Assuming p > q, the probability of the attacker catching up will decrease exponentially with the increase in blocks. Because the odds are against them, if they are not lucky enough to catch up early, their chances of success will diminish as they fall further behind. Now we consider how long it takes for a new transaction to be sufficiently confirmed so that the sender cannot change the transaction. We assume the payer is an attacker who wants the payee to believe they have already paid and then reclaim the money after payment; the payee will be notified with a warning when this occurs, but the payer hopes this happens much later.
The recipient generates a new key pair and gives this public key to the payer shortly before the payer makes the payment. This prevents the payer from preparing a blockchain version before the time, working continuously until they are lucky enough to get far ahead, and then executing the transaction at that time. Once this transaction is sent, this dishonest sender begins secretly working on a parallel chain that includes a version of the transaction that replaces their transaction. The recipient waits until this transaction is added to a block and then z blocks are added afterward. They do not know the exact number of processes the attacker has completed (how many blocks have been made), but assuming the honest chain takes an expected average time to produce a block, the attacker's potential progress is a Poisson distribution, with the expected value of the distribution being
Convert 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);
// Running to get results, we can see 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
// Solve for the z value that makes P < 0.1%
for (i = 1; i <= k; i++) {
poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
}
return sum;
}
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. This indicates that waiting for 6 blocks is an absolutely secure method.
- Conclusion We propose a non-trust-based electronic transaction system.
We start from the conventional currency framework composed of digital signatures, which provides strong control over ownership relationships but cannot solve the double spending problem. To address this issue, we propose a P2P network using a proof-of-work mechanism to record a public transaction history. This mechanism becomes computationally impossible for attackers to change when the majority of nodes control the main CPU power. The network is robust in its unstructured simplicity.
Nodes only need minimal collaboration to work together. They do not need to be authenticated because information does not need to be routed to a specific place but only needs to be sent out as widely as possible. Nodes can leave or rejoin the network at will, accepting the proof-of-work chain as proof of what happened after this node left the network.
They vote based on CPU power, indicating acceptance of legitimate blocks by extending this block and rejecting illegal blocks by refusing to work after this block. Any necessary rules and incentives can be enforced through this consensus mechanism.