Contents

Overview . A full peer-to-peer version of electronic money allows online payments to send directly from one party to another, without the payment going past a financial institution. Digital signatures ensure part of the solution, but the biggest benefits are lost if a trusted third party is still required to prevent double editions. We propose a solution to the problem of double expenses through the use of a peer-to-peer network. This network places time stamps on transactions by "having" them in a constantly growing chain of Hashes -based Proof of Work. The longest chain does not merely serve as proof of the order of observed events, but proves that it was supplied by the largest collection of CPU force. As long as the majority of that CPU force is checked by nodes (nodes) in the network that do not work together to attack the network, they will make the longest chain and the attackers are too fast. The network itself requires a minimal structure. Messages are sent on a best-effort basis, and nodes can join the network at any time and leave at any time they want. As long as they accept the longest proof-of-work chain as proof of what happened during their absence.

Click here for the link to the original Bitcoin Whitepaper (in English) including accompanying images.

1. Introduction

Online Trade almost exclusively relies on financial institutions that serve as trusted third parties for processing electronic payments. While this system works well enough for most transactions, it still suffers from the inherent weak spots of the trust -based model. Completely irreversible transactions are not really possible, because financial institutions cannot avoid mediating in disputes. The cost price of these any interventions increases transaction costs, and this limits the minimum practical transaction size and the possibility of committing small individual transactions.

In addition, there are more costs in making irreversible payments and irreversible services. But the possibility of return booking increases the need for the trust factor. Sellers must be wary of their customers, and harass them for more information than they need otherwise. A certain percentage of fraud is accepted as inevitable. These costs and uncertainties in payments can be avoided if someone uses physical currency in person, but there is no mechanism for making payments through a communication channel without a trusted party.

There is a need for an electronic payment system based on cryptographic evidence instead of trust that two parties prepared for this means that it will act directly with each other without the need for a trusted third party. Transactions that are calculatively impractical for booking would protect sellers from fraud, and routine escrows or third -party accounts could easily be implemented to protect buyers. In this paper, we offer a solution on the double edition problem through a peer-to-peer divided time stamp server to provide arithmetic evidence of the chronological order of transactions. This system is safe as long as fair junctions collectively deliver more CPU force than that of a cooperating group of attacking nodes.

2. Transactions

We define an electronic currency as a chain of digital signatures. Each owner sends the currency by placing a digital signature on a hash of the previous transaction and adding the public key to the next owner at the end of the coin. A person to be paid can verify these signatures to verify the chain of ownership.

The problem is of course that the person to be paid cannot check whether one of the owners has not spent the coin twice. A common solution is the introduction of a trusted central authority, or Mint , which checks every transaction for double editions. After each transaction, the coin must return to the publisher, to publish a new coin, and only coins that have been directly in circulation can be trusted in order not to be spent twice. The problem with this solution is that the fate of the entire monetary system depends on the company behind this currency, because every transaction has to go past them, just like with a bank.

We need a way so that the person to be paid knows that the previous owners did not sign earlier transactions. For our purpose; The earliest transaction is the one who counts, so we no longer have to worry about later attempts to a double edition. The only way to confirm the absence of transactions is aware of all transactions. In the model -based model, the publisher was aware of each transactions to decide which arrived the first. To achieve this without the use of a trusted party, transactions must take place in the order of receipt. The recipient needs evidence that at the time of each transaction, the majority of the nodes agreed that it was the first transaction received.

3. Timetal Server

The solution that we propose starts with a time stamp server. A time stamp server works by taking a hash from a block of items that need a time stamp and publishing that hash, such as in a newspaper or a usenet message [2-5]. The time stamp proves that the data must have existed at that time, of course, to be able to get in the hash. Each time stamp contains the previous time stamp in its hash, and forms a chain, in which every previous time stamp strengthens the stamp for it.

4. Proof-of-work

To implement a distributed time stamp server on a peer-to-peer base, we will have to use a proof-of-work system similar to Adam Blacks Hashcash, instead of newspaper articles or usenet messages. This proof-of-work includes scanning to a value that, when has been having like with SHA-256, the hash starts with a number of zero bits. The average work required for this is exponentially required in the number of zero bits and can be verified by performing a single hash.

For our time stamp network we implement the proof-of-work system by increasing a nonce (occasional data) in the block until a value is found that gives the hash in the block the required zero bits. Once the CPU effort is spent to meet the proof-of-work system, the block can no longer be changed without doing all the work again. When blocks are chained later, the work that is needed to change the current block includes re -performing the work of all the blocks that come afterwards.

The proof-of-work system also solves the problem of determining representation in decision-making. If the majority were based on one IP address per voice, that system could be circumvented by those who can assign multiple IPs. Proof-of-work is essentially one CPU = one voice. The majority decision is represented by the longest chain, which has invested the largest proof-of-work effort.

When a majority of the CPU force is under control of fair nodes ( nodes ), the honest chain will grow the fastest and all competing chains pass by. To adjust a previous block, an attacker should do all the work of the proof-of-work of the block and all blocks afterwards and then have to overtake and surpass the work of the fair nodes. We will later show that the probability that a slower attacker can catch up exponentially reduces the more blocks are added. To compensate for an increase in hardware speed and with time varied interest in running nodes, the difficulty level of the proof-of-work system is determined by a progressive average based on the number of blocks per hour. If the blocks are produced too quickly, the difficulty level is increased ( Difficulty Adjustment ).

5. Network

The steps to maintain the network are as follows:

1. New transactions are broadcast to all nodes ( nodes ).
2. Each node collects new transactions in a block.
3. Each node works on finding a difficult proof-of-work for its block.
4. When a junction finds a proof-of-work, it will send it to all nodes
5. Knooppoints only accept a block if all transactions are valid in it and are not already published.
6. Junctions express their acceptance of a block by working on the creation of the next block in the chain, by using the hash of the previous accepted block.

The longest chain always see nodes as the correct one and will continue to work on its extension. When two junctions broadcast different versions of the next block simultaneously, some nodes will receive one or the others first. In that case, they continue to work with the first they have received, but they keep the other branch in case it would be longer. This tire is broken when the next proof-of-work is found and one branch becomes longer. The nodes that were working on the other branch then switch to the longer branch.

New transactions do not necessarily have to reach all nodes. As long as they reach many nodes, it won't take too long before they are included in a block. Blok Transactions are also tolerant of lost messages. If a purchase points does not receive a block, he will request those requests upon receipt of the next block and realize that he had missed one.

6. incentives

According to agreement, the first transaction in a block is a special transaction that creates a coin that becomes the property of the maker of the block (the miner ). This provides a stimulus for junctions to support the network, and gives them a way to first put coins into circulation, since there is no central authority that she issues. This steady supply of a constant number of new coins is analogous to gold diggers that use raw materials to put gold into circulation.

In our case, CPU is used up time and electricity. This incentive can also be further fed by transaction costs. If the output value is less than its input value, transaction costs are the difference that is added to the incentive value of the block that contains the transaction (block reward) . As soon as a predetermined number of coins has been put into circulation, the stimulans can go completely to transaction costs and be fully inflation -free.

This incentive can help to keep nodes honest. If a greedy attacker has the opportunity to collect more CPU power than all fair nodes together, he will have to choose between fraud people by stealing their payments, or to use it to create new coins. He should find it more profitable to play according to the rules, if these rules give him more favor with more coins than everyone combined than by undermining the system together with the validity of his own riches.

7. Storage space Terugeisen

As soon as the last transaction is buried in a coin under enough blocks, the transactions spent can be removed to save disk space. To make this easier without breaking the hash of a block, transactions are assured into a Merkle Tree [7] [2] [5], with only the root (root) included in the hash of the block. Old blocks can then be made more compact by cutting down the branches of the tree. The inner hashes do not have to be stored. A block header without transactions would be around 80 bytes. If we assume that blocks are generated every ten minutes, then 80 bytes * 6 * 24 * 365 = 4.2 MB per year is. With computer systems that usually have 2 GB RAM since 2008 and the law of Moore that predicts a current growth of 1.2 GB per year, the storage should not be a problem even if the block of headers should be kept in the memory.

8. Simplified payment verification

It is possible to verify payments without running a full network node. A user should only keep a copy of the block headers of the longest proof-of-work chain, which he can get by requesting them at network nodes until he is convinced that he has the longest chain, and the Merkle branch can obtain that connects the transaction to the block in which it has a time stamp. He cannot control the transaction himself, but by linking it to a place in the chain (the blockchain), he can see that the node has accepted it, and then confirm the blocks that the network has accepted the transaction.

In this way, the verification is reliable for as long as the fair nodes have control over the network, but it is more vulnerable if the network is overpowered by an attacker. While network nodes can confirm transactions in itself, the simplified method can be led to the garden by an attacker and its falsified transactions, as long as the attacker continues to overpower the network in the entire network. A strategy to protect the network could be to accept alarm signals of nodes if they detect an invalid block, and the user encourages his software to download the entire block and the signaled transactions to confirm the inconsistency. Companies that regularly receive payments want to run their own nodes for more independent safety and faster verification.

9. Combining and splitting value

Although it would be possible to treat the coins individually, it would become unmanageable to make a separate transaction for each cent in a transfer. To allow value to be divided and combined, transactions contain multiple inputs and outputs. Normally there is either a single input from a larger previous transaction, or several inputs that combine smaller amounts, and at most two outputs: one for payment, and one to give change, when applicable, back to the sender.

It must be mentioned that with a fan-out, where a transaction depends on multiple transactions, and these transactions depend on many others, there is no problem here. There is never an need to request a completely alone copy of a transaction history.

10. Privacy

The traditional bank model achieves a certain standard of privacy by limiting access to the information from the parties involved and the trusted third party. The need to publicly announce all transactions is excluded this method, but privacy can still be retained by breaking the information flow in a different place, namely by keeping public keys anonymous. The public can see when someone sends an amount to someone else, but without this information being linked to a person. This is the same as the level of information on stock exchanges, where the time and size of individual trades, the "tape", is made public, but without telling anyone who the acting parties are.

As an additional safety consideration, a new pair of keys should be used for every transaction that does not want to be linked to a common owner. Part of that linking is still inevitable with transactions with multiple inputs, because it is necessary to reveal that the inputs were the property of the same owner. There is a risk that when the owner of a key is unveiled, links could be revealed via links which other transactions belong to the same owner.

11. Calculations

We take into account a scenario in which an attacker tries to generate an alternative chain faster than an honest chain. Even if that succeeds, this does not expose the system to random changes, such as creating value from nothing or to receive money that was never the property of the attacker. Nodes will not accept invalid transactions such as payment and fair nodes will never accept a block that contains this invalid transaction. An attacker can only try to change one of his own transactions or to take back money that he has already spent.

The race between an honest chain and the chain (blockchain) of an attacker is characterized by a binomial random walk (random walk). In the case of success, the chain is extended by a block, which increases its lead by +1, and in the case of failure, the chain of the attacker is extended with a block, reducing the gap by -1. The probability that an attacker can catch up with a given shortage is the same as the 'Gambler's gelding problem' (downfall of the gambler). Suppose a gambler with infinite credit starts with a backlog and can play an infinite number of turns in an attempt to turn break. Under our assumption that P> Q, the probability reduces exponentially as the number of blocks that the attacker must catch up is increased. If the attacker fails to jump forward early in the process, his chances will become astronomically small as he gets behind.

We now take into account how long the recipient must wait for a new transaction before he can be sufficiently sure that the sender can no longer change the transaction. We assume that the sender is an attacker who wants the recipient to believe that he has paid him, and then to pay himself back after a while. The recipient will be informed when that happens, but the sender hopes that this will be too late. The recipient generates a new key pair and gives the public key to the sender just before drawing. This prevents the sender from adjusting a block chain that can adjust for it, by constantly working on it until he has enough happiness to get far enough first, and then carrying out the transaction at that time. Once the transaction has been sent, the unfair sender starts to work secretly on a parallel chain that contains an alternative version of its transaction. The recipient is waiting for the transaction to be added to a block and Z blocks are linked to it. He cannot know the exact lead of an attacker. But assuming that the fair blocks have taken the average number of time per block.

12. Conclusion

We have proposed a system for electronic transactions without having to appeal to trust. We started with the usual framework made of coins made of digital signatures, which gives strong control over ownership, but is incomplete without a way to prevent double editions.

To solve this, we propose a peer-to-peer network that uses proof-of-work to log a public history of transactions. It quickly becomes arithmetically impractical for an attacker to change this for a long time fair nodes check the majority of the CPU force. The network is robust in its unstructured simplicity. Junctions all work at the same time as little coordination. They must not be identified, since messages are not sent along a specific place and only have to be received on a best-effect base.

Knooppoints can leave and join the network when they want, if they accept the proof-of-work chain as proof of what happened during their absence. They vote through their CPU force, express their acceptance of valid blocks by working on its grant and reject invalid blocks by refusing to work. Some required rules and incentives can be maintained via this Mechanism.