BlockChain: [Satoshi Nakamoto] Historical work Bitcoin: A Peer-to-peer Electronic Cash System Bitcoin: A Peer-to-peer Electronic Cash System
Bitcoin: A Peer-to-peer Electronic Cash System (BITCOiin: A Peer-to-peer Electronic Cash System) 2017-12-30 Last modified
Warning: Do not paste copy, please respect the blogger knowledge sharing! Thank you!
directory
background
The Genesis block of Bitcoin
Hundreds of ideas
The paper
Abstract
1. Introduction – the Introduction
2. Trade – the Transactions
3. Timestamp Server -Timestamp Server
4. Proof-of-work
5. Network – Network
6. Motivation – Incentive
-Reclaiming Disk Space
8. Simplified Payment Verification
9. Combination and Splitting of Value
10. Privacy – Privacy
11. Computing – Calculations
12. Conclusion – the Conclusion
References
background
On Nov. 1, 2008, a man calling himself Satoshi Nakamoto posted a research paper on a hidden cryptography discussion group that described his design for a new digital currency called Bitcoin. Bitcoin uses an open distribution ledger to do away with third-party management, which Mr Nakamoto calls the “block chain”. Users are willing to donate their computer’s CPU power, run a special piece of software to “mine” and form a network to jointly sustain the blockchain. In 2009, he released the first bitcoin software and officially launched the Bitcoin financial system. In 2010, he gradually stepped aside and handed over the project to other members of the Bitcoin community. Mr. Nakamoto is believed to hold about a million bitcoins. Those bitcoins were worth more than $1 billion at the end of 2013.
He left so little of his online profile that few people had ever heard of him. Though Satoshi Nakamoto himself may be a mystery, his design solved one of the biggest puzzles in cryptography for decades. The idea of a digital currency that is easy and untraceable, out of the hands of governments and banks, has been the talk of the Internet ever since. (Excerpt from Network Collection)
Mochizuki Shinichi? Nick Szabo? Dorian Nakamoto? Craig Stephen White? Whoever it is, the world owes him a Nobel Prize ！！！！！ As a blockchain researcher, I am looking forward to this day,????
The Genesis block of Bitcoin
The headline of a front-page Article in The Times that day was written in English by Satoshi Nakamoto at Genesis Coinbase:
The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.
On January 3rd 2009 the chancellor of the exchequer was on the verge of implementing a second bank bail-out.
Hundreds of ideas
Mr. Nakamoto’s true identity has long been unknown since his publication, with wikileaks founder Julian Assange calling him a Cypherpunk. Another person claimed that “Satoshi Nakamoto is an anarchist. His original intention is not to control cryptocurrency by a government or central bank, but to make it a currency that flows freely around the world and is not subject to government supervision and control.”
On November 1, 2008, Satoshi Nakamoto published a paper on the cryptography mailing list of metzdowd.com entitled bitcoin: A Peer-to-peer Electronic Cash System. The paper describes in detail how to create a decentralized electronic trading system that does not need to be based on mutual trust. Soon, on January 3, 2009, he developed the first client program implementing the Bitcoin algorithm and made the first “mining”, obtaining the first 50 bitcoins. It also marks the official birth of the bitcoin financial system. On December 5, 2010, during the wikileaks leak of U.S. diplomatic cables, the bitcoin community called on wikileaks to accept bitcoin donations to break the financial blockade. China and Japan expressed firm opposition, believing that Bitcoin is still in its infancy and can not afford conflicts and disputes. Seven days later, on Dec. 12, he posted his last post on the Bitcoin forum, noting minor problems with the latest version of the software, then disappeared and the email correspondence gradually ceased. (From Baidu)
V God comment: V God tweeted that if CSW is really Satoshi Nakamoto, then question Satoshi Himself. “If there is conclusive evidence that CSW is Satoshi, THEN I will not change my mind about CSW, but about Satoshi,” he said. Zeng Ming: I think Satoshi nakamoto is amazing. He’s a genius. He really started an era. Continue to…
The paper
Bitcoin: A Peer-to-peer Electronic Cash System bitcoin.org/bitcoin.pdf
Abstract
| Abstract. A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they’ll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone. | Abstract: This paper proposes an electronic cash system completely realized by point-to-point technology, which enables online payment to be directly initiated by one party and paid to another party without going through any financial institutions. While digital signatures provide part of the solution, the main benefits will be lost if trusted third parties are still needed to prevent double-spending. We propose a solution here that enables the cash system to operate in a point-to-point environment and prevents the double-spending problem. The network uses random hashing to add timestamps to all transactions, merging them into an extended chain of random hashing proof-of-work that is immutable until all proof-work is redone. The longest chain is considered not only a proof of the observed sequence of events, but also from the pool with the largest CPU computing power. As long as most OF the CPU power is controlled by nodes that do not cooperate in attacking the network, then the honest nodes will generate the longest chain that overtakes the attacker. The system itself requires very little infrastructure. Information is transmitted throughout the network as best as possible. Nodes can leave and rejoin the network at any time, and the longest proof of work chain is used as proof of transactions that take place while the node is offline. |
|---|
1. * * * * * * – * * * * * * the Introduction
| Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model. Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible services. With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need. A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party. | Commerce over the Internet already relies almost entirely on financial institutions as trusted third parties to process electronic payments. Although the system works well for most transactions, it still suffers from the inherent weaknesses of trust-based models. Completely irreversible transactions are impossible because financial institutions cannot avoid settling disputes. Mediation costs increase transaction costs, limit the minimum actual transaction size and cut off the possibility of small temporary transactions, and the loss of irreversible capacity to pay for irreversible services has broader costs. With the possibility of reversal, the need for trust spreads. Businesses must be vigilant about their customers, harrying them for more information than they need. A certain percentage of fraud is considered inevitable. These costs and payment uncertainties can be avoided in person by using physical currency, but there is no mechanism to make payments over communication channels without a trusted party. |
|---|---|
| What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers. In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes. | What is needed is an electronic payment system based on cryptographic proof rather than trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Computationally impractical counter-transactions would protect the seller from fraud, and regular escrow mechanisms could be easily implemented to protect the buyer. In this paper, we propose a method to solve the double-flower problem by using a point-to-point distributed timestamp server to generate a computational proof of transaction time order. As long as the honest nodes collectively control more CPU power than the attacker nodes in any cooperative group, the system is safe. |
Almost all transactions on the Internet require 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 inherently subject to the weaknesses of the trust based model. We cannot achieve a completely irreversible transaction because financial institutions will inevitably come to mediate disputes. The existence of financial intermediaries will also increase the cost of transactions and limit the practical minimum transaction scale, as well as daily micro-payment transactions. Moreover, the potential loss is that many goods and services themselves are not returnable, and without irreversible means of payment, the Internet trade will be greatly restricted. The potential for a refund requires trust on both sides of the transaction. And businesses have to be wary of their customers, so they ask for completely unnecessary personal information. In actual business practices, a certain proportion of fraudulent customers are also considered inevitable, and the related losses are treated as sales expenses. In the case of physical cash, the uncertainty of sales expenses and payments can be avoided because there is no third party credit intermediary.
So there is a great need for an electronic payment system that is based on cryptography rather than credit, so that any agreed parties can pay directly without the involvement of a third party intermediary. Eliminate the possibility of rolling back payment transactions, which would protect specific sellers from fraud; And for those who want to protect buyers, setting up the usual third-party guarantees in this environment is a breeze and a joy. In this paper, we propose a point-to-point distributed timestamp server to generate time-sequential and recorded electronic transaction proofs to solve the double payment problem. The system is safe if the bim is honest and contributes more computing power than the cooperative attacker.
2. * * * * * * – * * * * * * the Transactions
| We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership | We define electronic money as a series of digital signatures. Each owner digitally signs the hash of the previous transaction and the public key of the next owner and adds them to the end of the coin to transfer the coin to the next owner. The payee can verify the signature to verify the owner of the chain. |
|---|---|
| The problem of course is the payee can’t verify that one of the owners did not double-spend the coin. A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending. After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank. | The problem, of course, is that the payee can’t verify that one of the owners (has) not reused e-money. A common solution is to bring in a trusted central authority, or something akin to a mint, to check the double expense of each transaction. After each transaction, e-currency must be returned to the mint to issue new e-currency, and only e-currency issued directly from the mint can be trusted not to be reused. The problem with this solution is that the fate of the entire monetary system depends on the company that runs the mint, and every transaction must go through them, just like a bank. |
| We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don’t care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions. In the mint based model, the mint was aware of all transactions and decided which arrived first. To accomplish this without a trusted party, transactions must be publicly announced [1], and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received. | We needed a way to let the payee know that the previous owner had not signed off on any earlier transactions. For our purposes, the earliest transaction is the most important, so we don’t care about respending later. The only way to be sure a trade doesn’t exist is to know all of them. In a minte-based model, the mint knows all the transactions and decides which one arrives first. In order to do this without a fiduciary party, transactions must be publicly announced [1], and we need a system for participants to agree on a single history of the order in which transactions were received. The payee needs to prove that at the time of each transaction, most nodes agree that it was received for the first time. |
We define an electronic coin as a string of digital signatures: Electronic money is sent to the next owner by each owner attaching a randomly hashed digital signature to the Public key of the previous transaction and the next owner. The payee can verify the owner of the chain by checking the signature.
The problem with this process is that it would be difficult for the recipient to verify whether a previous owner had made a double payment for the electronic currency. The usual solution is to bring in trusted third-party authorities, or mints, to check every transaction to prevent double payments. At the end of each transaction, the coin is recalled by the Mint, which issues a new one; Only digital money issued directly by the mint counts as valid, thus preventing double payments. The problem with this solution, however, is that the fate of the entire monetary system depends entirely on the company that runs the mint, because every transaction is confirmed by the Mint, which acts like a bank. We need recipients to have some way of ensuring that previous owners did not sign transactions that occurred earlier. Logically, in order to achieve this goal, we actually need to focus only on the transactions that occurred before the transaction, and not on whether there were attempts to double pay after the transaction occurred. The only way to be sure a trade doesn’t exist is to know all the previous trades. In the Mint model, the Mint knows all transactions and determines the order in which they are completed. If we want to exclude third-party intermediary institutions in the electronic system, then the transaction information should be publicly announced (Publicly announced) [1]. We need all the participants in the whole system to have a unique recognized historical transaction sequence. The payee needs to ensure that a majority of the nodes during the transaction agree that the transaction is the first to occur.
******3. Timestamp Server -******Timestamp Server
| The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post [2-5]. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it. | Our proposed solution starts with a timestamp server. The timestamp server works by taking the hash of the item block to be timestamped and publishing the hash widely, for example in a newspaper or Usenet post [2-5]. The timestamp proves that the data must exist at the time, obviously, in order to enter the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing its previous timestamp. |
|---|
This solution first proposes a “timestamp server”. The timestamp server timestamps a random hash of a set of data in the form of blocks and broadcasts that random hash as a post on a news or Usenet network [2][3][4][5]. Obviously, this timestamp confirms that a particular piece of data must exist at a particular time, because the corresponding random hash value can only be obtained if it exists at that time. Each timestamp should incorporate the previous timestamp into its random hash value, and each subsequent timestamp would reinforce the previous one, thus forming a Chain.
******4. Proof of Work -****** proof-of-work
| To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proofof-work system similar to Adam Back’s Hashcash [6], rather than newspaper or Usenet posts. The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash. | To implement a distributed timestamp server on a point-to-point basis, we need to use a validation system similar to Adam Back’s Hashc.[6] rather than newspapers or Usenet posts. Proof of work involves scanning a value, and when hashing, such as with SHA-256, the hash begins with zero bits. The average work required is exponential in the number of zeros required and can be verified by performing a single hash. |
|---|---|
| For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block’s hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it. | For our timestamp network, we implement proof of work by adding a Nonce to the block until we find the zero bits needed to make the block hash. Once CPU work is exhausted to satisfy the proof of work, the block cannot be changed without redoing the work. When subsequent blocks are linked, the work of changing blocks will include redoing all subsequent blocks. |
| The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added. | Proof of work also solves the problem of determining representation in most decisions. If the majority vote once based on one IP address, it can be subverted by anyone able to assign many IPS. Proof of work is basically one CPU per vote. Most decisions are represented by the longest chain, which has the greatest proof of work commitment. If most OF the CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chain. To modify a past block, an attacker must redo the proof of work for the block and all subsequent blocks, then chase and overtake the honest node’s work. We will show later that the probability of a slower attacker catching up decreases exponentially with subsequent blocks. |
| To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they’re generated too fast, the difficulty increases. | To compensate for increased hardware speed and interest in running nodes over time, the difficulty of the proof of work is determined by a moving average targeting the average number of blocks per hour. If they are generated too quickly, the difficulty increases. |
In order to build a decentralized set of timestamp servers on a peer-to-peer basis, it is not enough to work like a newspaper or a world news network, we also need a Hashcash similar to that proposed by Adam Back [6]. The proof-of-work mechanism introduces a scan of a particular value when performing a random hash, such as sha-256, where a random hash value starts with one or more zeros. So as the number of zeros increases, the amount of work required to find the solution increases exponentially, and checking the result requires only a random hash operation.
We add a random number (Nonce) to the block that causes the random hash value of the given block to have as many zeros as needed. We find this random number by trial and error until we find it, so we build a proof of work mechanism. As long as the amount of work consumed by the CPU satisfies the proof-of-work mechanism, the block’s information cannot be changed unless a comparable amount of work is redone. Since subsequent blocks are linked after that block, changing the information in that block also requires redoing the entire amount of work for all subsequent blocks.
At the same time, the proof of work mechanism resolves the question of who is the majority in a group vote. If most decisions are based on IP addresses, one IP address, one vote, then the mechanism is broken if someone has the power to assign a large number of IP addresses. The nature of proof of work mechanism is one CPU, one vote. The “most” decision is expressed as the longest chain, because the longest chain contains the most work. If most oF the cpus are controlled by honest nodes, the honest chain will extend the fastest and outpace the other competing chains. To modify an existing block, an attacker must redo that block plus all subsequent blocks, eventually catching up and surpassing the honest node’s workload. As we will prove later, if a slower attacker tries to catch up with a subsequent block, the probability of success decreases exponentially. Another problem is that the computing speed of hardware increases rapidly, while the degree to which nodes participate in the network fluctuates. To solve this problem, the proof-of-work difficulty will be determined using a moving average goal, where the difficulty points to a predetermined average rate of block generation per hour. If blocks are generated too quickly, the difficulty increases.
5. Network – Network
| The steps to run the network are as follows: 1) New transactions are broadcast to all nodes. 2) Each node collects new transactions into a block. 3) Each node works on finding a difficult proof-of-work for its block. 4) When a node finds a proof-of-work, it broadcasts the block to all nodes. 5) Nodes accept the block only if all transactions in it are valid and not already spent. 6) Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash. | The steps to run the network are as follows: 1) The new transaction is broadcast to all nodes. 2) Each node collects new transactions into a block. 3) Each node is finding a hard working proof for its block. 4) When the node finds proof of work, it broadcasts the block to all nodes. 5) Nodes accept blocks only if all transactions are valid and not already in use. 6) Nodes express their acceptance of a block by creating the next block in the chain, using the hash of the received block as the previous hash. |
|---|---|
| Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proofof-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one. | The node always regards the longest chain as the correct chain and keeps expanding. If two nodes simultaneously broadcast different versions of the next block, some nodes can receive one or the other first. In this case, they work on the first one they receive, but save another branch to make it longer. The binding is broken when the next checksum work is found and a branch becomes longer; Nodes working on another branch will then switch to a longer one. |
| New transaction broadcasts do not necessarily need to reach all nodes. As long as they reach many nodes, they will get into a block before long. Block broadcasts are also tolerant of dropped messages. If a node does not receive a block, it will request it when it receives the next block and realizes it missed one. | New transaction broadcasts do not necessarily need to reach all nodes. As long as they reach many nodes, they will soon enter a block. Block broadcasts also tolerate discarded messages. If a node does not receive a block, it will request it when it receives the next block and realize that it has lost a block. |
The steps to run the network are as follows:
- 1) New transactions are broadcast to the whole network;
- 2) Each node incorporates the received transaction information into a block;
- 3) Each node tries to find a proof of work in its own block with sufficient difficulty;
- 4) When a node finds a proof of work, it broadcasts it to the whole network;
- 5) Other nodes recognize the validity of the block only if and only if all transactions contained in the block are valid and have not existed before;
- 6) The other nodes indicate that they accept the block by following the end of the block and making new blocks to extend the chain, and treating the random hash value of the accepted block as the random hash value faster than the new block.
The node always treats the longest chain as the correct chain and keeps working and extending it. If two nodes broadcast different versions of the new block at the same time, the other nodes will receive the block at different times. In this case, they will work on the first block they receive, but will also keep another chain in case it becomes the longest. The tie will not be broken until the next proof of work is found and one of the chains is confirmed to be longer, so nodes working on the other branch chain will switch parties and start working on the longer chain. The so-called “new transaction to broadcast” does not actually need to reach all nodes. As long as the transaction information reaches enough nodes, it will soon be consolidated into a block. The block broadcast is fault-tolerant of discarded information. If a node does not receive a particular block, the node will discover that it is missing a block and can make its own request to download the block.
* * * * * * 6. Incentives – * * * * * * Incentive
| By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them. The steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation. In our case, it is CPU time and electricity that is expended. | By convention, the first transaction in a block is a special transaction that starts a new coin owned by the block creator. This increases the incentive for nodes to support the network and provides a way to initially distribute coins into circulation, since there is no central authority to issue coins. A steady increase in the number of new coins is similar to a gold miner expending resources to increase the circulation of gold. In our case, CPU time and power consumption. |
|---|---|
| The incentive can also be funded with transaction fees. If the output value of a transaction is less than its input value, the difference is a transaction fee that is added to the incentive value of the block containing the transaction. Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free. | Incentives can also be funded with transaction fees. If the output value of the transaction is less than its input value, then the difference is the transaction cost, which is added to the incentive value of the block containing the transaction. Once a predetermined number of coins are in circulation, the incentive can be converted into transaction fees entirely, without inflation. |
| The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth. | Incentives may help to encourage nodes to be honest. If a greedy attacker is able to assemble more CPU power than all honest nodes, then he must choose to use CPU power to trick people by stealing back his payout, or use it to generate new coins. He should find it more profitable to abide by these rules than to undermine the legitimacy of the system and his own wealth, which are more conducive to his possession of more new coins than anyone put together. |
We agree that the first transaction in each block is specialized, and that transaction creates a new digital currency owned by the block’s creator. This increases the incentive for nodes to support the network and provides a way to distribute electronic money into circulation without a centralized authority issuing it. This method of continuously adding a certain amount of new money to the monetary system is much like expending resources to mine gold and pump it into circulation. At this point, CPU time and power consumption are the consumed resources. Another source of incentive is transaction fees. If the output value of a transaction is less than the input value, the difference is the transaction fee, which is added to the incentive for the block. Once a given amount of electronic money is in circulation, the incentive mechanism can gradually be switched to relying solely on transaction fees, and the monetary system can be inflation-free. The incentive system also helps to encourage nodes to be honest. If a greedy attacker can muster more CPU power than all the honest nodes combined, he has a choice: either use it for honest work to generate new electronic currency, or use it for a secondary payment attack. Then he will find it more profitable to play by the rules and work honestly. Because such rules allow him to own more digital money, rather than undermining the system and undermining the validity of his own wealth.
******7. Reclaim Disk Space -******Reclaiming Disk Space
| Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. To facilitate this without breaking the block’s hash, transactions are hashed in a Merkle Tree [7][2][5], with only the root included in the block’s hash. Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored. | Once the latest transactions in the coin are buried in enough blocks, used transactions before they can be discarded will save disk space. To achieve this without breaking the block hash, transactions are hashed in the Merkle Tree[7][2][5], with only the root contained in the block hash. Old blocks can be compacted by cutting away branches. Internal hashes do not need to be stored. |
|---|---|
| A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4 MB per year. With computer systems typically selling With 2GB of RAM as of 2008, And Moore’s Law predicting Current Growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory. | The size of the non-transaction is about 80 bytes. If we assume that a block is generated every 10 minutes, then 80 bytes ×6×24×365 = 4.2MB per year. Since computer systems typically sell 2GB of RAM by 2008, and Moore’s Law predicts current growth of 1.2GB per year, storage should not be an issue even if the bulk must be kept in memory. |
If the most recent transaction has been included in enough blocks, data prior to that transaction can be discarded to reclaim disk space. To ensure that the random hash value of the block is not damaged at the same time, the transaction information is randomly hashed into a Merkle tree [7], so that only the root is included in the random hash value of the block. Old blocks can be compressed by stubbing the branches of the tree. The internal random hash value does not need to be saved.
Block headers, which do not contain transaction information, are only 80 bytes in size. If we set the rate of block generation at one every 10 minutes, then 4.2MB of data bits are generated per year. (80 bytes * 6 * 24 * 365 = 4.2MB). In 2008, PC systems typically had 2GB of memory, and Moore’s Law predicted that it would not be a problem to store all the block headers in memory.
******8. Simplified Payment confirmation -******Simplified Payment Verification
| It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he’s convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it’s timestamped in. He can’t check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it. | Payments can be verified without running a full network node. The user only needs to keep a copy of the bulk of the longest proof of work chain, query the network node until he is sure he has the longest chain, and get that copy and the Merkle branch that links the transaction to the block with its timestamp. He cannot examine the transaction himself, but by linking it to a location in the chain, he can see that the network node has accepted it and add blocks after further verifying that the network has accepted it. |
|---|---|
| As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker’s fabricated transactions for as long as the attacker can continue to overpower the network. One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user’s software to download the full block and alerted transactions to confirm the inconsistency. Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification. | Thus, validation is reliable as long as honest nodes control the network, but is more fragile if the network is overwhelmed by an attacker. Although network nodes can verify transactions themselves, the simplified approach can be fooled by an attacker’s forged transactions as long as the attacker can continue to overwrite the network. One strategy to prevent this is to receive alerts from network nodes when they detect invalid blocks, prompting the user’s software to download the full block and alert transactions to confirm inconsistencies. Businesses that accept frequent payments may still want to run their own nodes for more independent security and faster validation. |
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, and it can keep asking the network until it is convinced that it has the longest chain and is able to go through Merkle’s branch to the transaction it was time-stamped and included in the block. It would have been impossible for a node to verify the validity of the transaction itself, but by tracing back to a point in the chain, it could see that a node had accepted it, and the block appended afterwards further proved that the whole 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 a computationally superior attacker, it will become more vulnerable. Because network nodes can verify the validity of the transaction themselves, the simplified mechanism can be fooled by the attacker’s welded transaction as long as the attacker continues to maintain computational power. A possible strategy would be to send an alert as soon as they find an invalid block, and the alerted user would immediately start downloading the full information of the block or transaction that was warned of the problem in order to determine the inconsistencies. Commercial organizations with large amounts of receipts and payments on a daily basis may still want to run their own full nodes to maintain greater independence of completeness and speed of verification.
******9. Value combination and Splitting -******Combining and Splitting Value
| Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer. To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender. | While it’s possible to process coins individually, it’s cumbersome to deal with each penny in a transfer individually. To allow values to be split and merged, a transaction contains multiple inputs and outputs. Typically, there will be a single input from a larger prior transaction or multiple inputs combining smaller amounts, and up to two outputs: one for payment and one to return changes (if any) to the sender. |
|---|---|
| It should be noted that fan-out, where a transaction depends on several transactions, and those transactions depend on many more, is not a problem here. There is never the need to extract a complete standalone copy of a transaction’s history. | It should be noted that fan-outs are not an issue here, as one trade depends on several trades, and those trades depend on more trades. You never need to extract a separate copy of the complete transaction history. |
Although electronic money could be processed individually, it would be an unwieldy approach to initiate a separate transaction for each electronic currency. To make value easy to combine and split, transactions are designed to incorporate multiple inputs and outputs. It is generally a single input made up of a previous transaction of greater value, or a parallel input made up of several previous transactions of lesser value, but there are at most two outputs: one for payment and one for change (if any).
It is important to point out that when one trade depends on several previous trades, each of them depends on several trades, but there is no problem with that. This mechanism does not require checking all previous transactions.
10. * * * * * * – * * * * * * Privacy Privacy
| The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party. The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone. This is similar to the level of information released by stock exchanges, where the time and size of individual trades, the “tape”, is made public, but without telling who the parties were. | Traditional banking models achieve a degree of privacy by limiting access to information to interested parties and trusted third parties. The need to publicly declare all transactions precludes this approach, but privacy can still be maintained by interrupting the flow of information elsewhere: by keeping the public key anonymous. The public can see someone sending the amount to others, but there is no information linking the transaction to anyone. This is similar to the level of information published by stock exchanges, where “tapes” of the timing and size of individual trades are made public without being told who the parties are. |
|---|---|
| As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner. | As an additional firewall, a new key pair should be used for each transaction to prevent them from linking to the common owner. For multi-input transactions, some links are still unavoidable, which necessarily indicates that their inputs belong to the same owner. The risk is that if the owner of a key is disclosed, links can reveal other transactions belonging to the same owner. |
The traditional mint model provides participants in a transaction with a degree of privacy, since attempts to request transaction information from trusted third parties are strictly limited. But broadcasting trade information to the entire web means that this approach is ineffective. But privacy can still be protected by keeping the public key anonymous. The only information the public gets is that someone sent a certain amount of money to someone else, but it’s hard to link that transaction to a particular person, that is, it’s hard to be sure who those people are. This is similar to the information published by stock exchanges, in that the timing and volume of stock transactions are recorded and available, but the identities of the parties involved are not disclosed. As an additional precaution, consumers can generate a new address for each transaction to ensure that these transactions are not traced back to a common owner. But some degree of traceability is inevitable because of parallel inputs, which indicate that the currencies all belong to the same owner. The risk is that if one of a person’s public keys is confirmed to belong to him, many other transactions can be traced.
The traditional mint model provides participants in a transaction with a degree of privacy, since attempts to request transaction information from trusted third parties are strictly limited. But broadcasting trade information to the entire web means that this approach is ineffective. But privacy can still be protected by keeping the public key anonymous. The only information the public gets is that someone sent a certain amount of money to someone else, but it’s hard to link that transaction to a particular person, that is, it’s hard to be sure who those people are. This is similar to the information published by stock exchanges, in that the timing and volume of stock transactions are recorded and available, but the identities of the parties involved are not disclosed. As an additional precaution, consumers can generate a new address for each transaction to ensure that these transactions are not traced back to a common owner. But some degree of traceability is inevitable because of parallel inputs, which indicate that the currencies all belong to the same owner. The risk is that if one of a person’s public keys is confirmed to belong to him, many other transactions can be traced.
* * * * * * 11. Computing – * * * * * * Calculations
| We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker. Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them. An attacker can only try to change one of his own transactions to take back money he recently spent. | We think the attacker is trying to generate a scenario where the alternative chain is faster than the honest chain. Even if it does, it does not expose the system to arbitrary changes, 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 honest nodes will never accept blocks containing them. The attacker can only try to change his own transaction to recover the money he recently spent. |
|---|---|
| The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk. The success event is the honest chain being extended by one block, increasing its lead by +1, and the failure event is the attacker’s chain being extended by one block, reducing the gap by -1. | The competition between the honest chain and the attacker chain can be described as a binomial random walk. A success event is the honest chain being extended by a block, increasing its lead by +1, while a failure event is the attacker’s chain being extended by a block, reducing the gap by -1. |
The probability of an attacker catching up from a given deficit is analogous to a Gambler’s Ruin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven. We can calculate the probability he ever reaches breakeven, or that an attacker ever catches up with the honest chain, as follows [8]:  Given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases. With the odds against him, if he doesn’t make a lucky lunge forward early on, his chances become vanishingly small as he falls further behind. |
The probability of an attacker catching up from a given deficit is analogous to the gambler’s bankruptcy problem. Suppose a gambler with unlimited credit starts in the red and may have to make an infinite number of attempts to break even. We can calculate the probability that he reaches break-even, or that the attacker catches up with the honest chain, as shown below [8] : Assuming p>q, the probability decreases exponentially as the number of blocks the attacker must chase increases. Faced with such an opportunity, if he doesn’t get lucky and push forward early, his chances become small because he falls behind. |
| We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can’t change the transaction. We assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed. | Now let’s consider how long the recipient of a new transaction will have to wait before it is fully assured that the sender cannot change the transaction. Let’s say the sender is an attacker who wants the receiver to believe that he paid him for a period of time and then converted it into a reward for himself after a period of time has passed. |
| The receiver will be alerted when that happens, but the sender hopes it will be too late. The receiver generates a new key pair and gives the public key to the sender shortly before signing. This prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead, then executing the transaction at that moment. Once the transaction is sent, the dishonest sender starts working in secret on a parallel chain containing an alternate version of his transaction. | The receiver is alerted when this happens, but the sender hopes it is too late. The receiver generates a new key pair and provides the public key to the sender before signing. This prevents the sender from preparing a series of blocks ahead of time by processing it consecutively until he is lucky enough to get enough ahead of time and then executes the transaction at this point. Once a transaction is sent, the dishonest sender secretly begins working on a parallel chain containing alternate versions of his transaction. |
The recipient waits until the transaction has been added to a block and z blocks have been linked after it. He doesn’t know the exact amount of progress the attacker has made, but assuming the honest blocks took the average expected time per block, the attacker’s potential progress will be a Poisson distribution with expected value:  |
The receiver waits until the transaction is added to the block, Z block, before being linked. He does not know the exact amount of progress the attacker has made, but assuming that honest blocks occupy the average expected time per block, the attacker’s potential progress will be a Poisson distribution with expected value: To get the probability that the attacker can still catch up now, we multiply the Poisson density, for each amount of progress he may have made, by the probability that he can catch up from that point on: rearrange to avoid summation of infinite tails of the distribution… |
Consider the following scenario: an attacker tries to create an alternative blockchain faster than an honest node produces a chain. Even if it does, the system is not entirely at the mercy of the attacker’s arbitrary will to create value out of thin air or plunder currency that does not belong to the attacker. This is because a node will not accept an invalid transaction, and an honest node will never accept a block containing invalid information. The best an attacker can do is change his own transaction information and try to get back the money he just paid someone else. The race 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 it +1 in lead, while a failure event is defined as the attacker’s chain being extended by one block, making the gap -1. The likelihood of an attacker successfully filling a given gap can be approximated as a Gambler’s Ruin problem. Suppose a gambler has an unlimited amount of credit to draw on, and then starts making a potentially infinite number of bets in an attempt to fill his hole. Then we can calculate the probability that he fills the gap, that is, the attacker catches up with the honest chain, as shown below [8] :
Assuming p>q, the probability of a successful attack declines exponentially as the number of blocks increases. Since probability is the enemy of the attacker, if he is not lucky and quick to succeed, his chances of success become more remote with each passing day. So let’s consider how long a payee has to wait to be sufficiently confident that the payer has made it difficult to change the transaction. Let’s assume that the payer is a payment attacker who wants to make the payee believe for a period of time that the payment has been made and then immediately repay the payment to himself. The payee will find out by then, but it will be too late. The payee generates a new key pair and then allows only a short time to send the public key to the payer. This would prevent the payer from preparing a blockchain in advance and then continuously performing calculations on the blockchain until luck pushes his blockchain past the honest chain before the payment is immediately executed. In this case, as soon as a transaction is issued, the attacker secretly prepares a parallel chain 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 be linked. At this point, he still does not know exactly how many blocks the attacker has advanced, but assuming that honest blocks take an average expected time to produce a block, the attacker’s potential progress is a Poisson distribution with the expected value of the distribution:
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 gains by the probability of the attacker still catching up.
To avoid summing an infinite sequence, use the following form:
Write the following C code:
Converting to C code...
#include <math.h>
double AttackerSuccessProbability(double q, int z)
{
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k <= z; k++)
{
double poisson = exp(-lambda);
for (i = 1; i <= k; i++)
poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}
Copy the codeWe can get the probability result as follows, and find that the probability decreases exponentially with respect to z value.
Running some results, We can see the probability drop off graph with Z.q = 0.1z =0 P=1.0000000 z=1 P= 0.20458773 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.3z =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 Solving for P less than 0.002... P < 0.001 q= 0.10z =5 q= 0.15z =8 Q = 0.20z =11 q= 0.25z =15 q= 0.30z =24 q= 0.35z =41 q= 0.40z =89 q= 0.45z =340Copy the code* * * * * * 12. Conclusion – * * * * * * Conclusion
| We have proposed a system for electronic transactions without relying on trust. We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending. To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power. The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism. | We have come up with an electronic trading system that does not rely on trust. We started with the usual framework of digitally signed coins, which provided strong control over ownership, but with no way to prevent double consumption, it was incomplete. To solve this problem, we propose a peer-to-peer network that uses proof of work to record the public history of transactions, which quickly becomes computationally impractical for an attacker if honest nodes control most OF the CPU power. The web is robust in its unstructured simplicity. The nodes work simultaneously with little coordination. They do not need to be identified because messages are not routed to any particular location and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting proof of the work chain as evidence of what happened when they left. They vote with their CPU power, expressing their acceptance of valid blocks by extending valid blocks and rejecting invalid blocks by refusing to process invalid blocks. Any rules and incentives needed can be enforced through this consensus mechanism. |
|---|
Here we propose an electronic payment system that does not require credit intermediaries. We first discussed the principle of electronic signatures for electronic money in general, and although such a system provides strong control over ownership, it is not sufficient to prevent double payments. To solve this problem, we propose a peer-to-peer network that uses proof-of-work to record public information about transactions, making it virtually difficult for an attacker to change transaction records as long as honest nodes control most OF the CPU computing power. The network’s strength lies in its structural simplicity. The work between nodes is largely independent of each other and requires little coordination. Each node does not need to identify itself, and since there is no requirement for the flow path of transaction information, it simply disseminates it as best it can. Nodes can leave the network at any time, and it is easy to rejoin the network because they only need to replenish the proof-of-work chain that received them during their absence. Nodes vote on their confirmation of valid blocks by their CPU power, expressing their confirmation by continually extending valid blocks and refusing to extend blocks after invalid ones. This framework contains all the rules and incentives required for a P2P electronic money system.
References
[1] W. Dai, “b-money,” www.weidai.com/bmoney.txt, 1998. A scheme for a group of untraceable digital pseudonyms to pay each other with money and to Enforce contracts “Red-hat means means to enter into a red-hat culture” [2] H. Massias, X.S. Avila, “A red-hat means to enter into a red-hat culture” [2] H. Massias, X.S. Avila, means to enter into a red-hat culture” 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. Designing a Timestamp Server based on Minimal Trust [3] S. Haber, W.S. Stornetta, “How to time-stamp a digital document,” In Journal of Cryptology, vol 3, no 2, pages 99-111, 1991. “How to Timestamp Electronic Documents.” [4] D. Bayer, S. Haber, W.S. Stornetta, “Improving the efficiency and reliability of digital time-stamping,” In Sequences II: Methods in Communication, Security and Computer Science, Pages 329-334, 1993. “Improving the Efficiency and Reliability of Electronic Timestamp” [5] S. Haber, W.S. Stornetta, “Secure names for bit-strings,” In Proceedings of the 4th ACM Conference on Computer and Communications Security, Pages 28-35, April 1997. “Secure Naming of Bit Strings” [6] A. Back, “Hashcash – a” of the service counter – measure, “www.hashcash.org/papers/hash… , 2002. Hashed Cash: A Restrained Approach to Denial-of-service Attacks [7]. “Protocols for public key cryptosystems,” In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, Pages 122-133, April 1980. “Protocol for Public Key Cryptosystems” [8] W. Feller, “An Introduction to Probability Theory and Its Applications,” 1957. “Probability Theory and Its Applications”