The Bitcoin whitepaper

Shop Now <      Blockchain Overview <<     BLOGS >>      [RAVE-ON.DE]

Bitcoin: A peer-to-peer electronic money system

From the original BITCOIN WHITEPAPER in English, translated into German.

Brief description. A pure peer-to-peer version of an electronic money system would make it possible to send online payments from one party directly to another without going through a financial institution. Digital signatures are part of the solution, but the main benefits are lost if a trusted third party is still required to prevent duplication. We propose a solution to the double-spending problem by using a peer-to-peer network. The network gives transactions a timestamp by hashing them into a continuous chain of hash-based proof of work. In this way, it creates a recording that cannot be changed without regenerating the proof-of-work. The longest chain serves not only as evidence of the sequence of witnessed events, but also as evidence that it comes from the largest pool of CPU power. As long as most of the CPU power is controlled by nodes that do not cooperate to attack the network, they will generate the longest chain and be faster than the attacker. The network itself only requires a minimal structure. Messages are transmitted on a best effort basis and the nodes can leave and re-enter the network at will as they accept the longest proof-of-work chain as evidence of what happened while they were gone.

1. introduction

It has emerged that commerce on the Internet now relies almost entirely on financial institutions acting as trusted third parties to process electronic payments. While this system works well enough for most transactions, it still suffers from the weaknesses of a model based on trust. Completely irreversible transactions are not really possible as financial institutions cannot avoid mediating in disputes. The cost of brokering increases the cost of the transaction, which increases the minimum size for feasible transactions and eliminates the possibility of small, casual transactions. In addition, greater damage arises from the elimination of the possibility of making irreversible payments for irreversible services. The option to reverse transactions increases the level of trust required. Retailers need to be suspicious of their customers and ask them to provide more information than would otherwise be necessary. A certain amount of fraud is accepted as inevitable. These costs and payment uncertainties can be avoided through face-to-face contact and the use of physical currency, but there is no mechanism for making payments over a communication channel without a trusted party.

What is needed is an electronic payment system that is based on cryptographic evidence rather than trust and allows two willing parties to transact directly with one another without the need for a trustworthy third party. Transactions that are computationally impossible to reverse would protect sellers from fraud and standardized escrow mechanisms could easily be implemented to protect buyers. In this paper, we propose a solution to the double-spending problem that generates computational evidence of the chronological order of the transactions using a distributed peer-to-peer time stamp server. The system is safe as long as the honest nodes control more CPU power than any cooperating group of attacking nodes.

2. 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 appending this to the end of the coin. The recipient of the payment can verify the signatures to verify the chain of owners.

The problem, of course, is that the payee cannot verify that one of the owners has not issued the coin twice. A common solution is to have a central, trusted authority, or mint, that checks every transaction for double spending. After each transaction, the coin must be returned to the mint so that it can issue a new coin and only coins that have been issued directly by the mint can be trusted that they have not been issued twice. The problem with this solution is that the fate of the entire monetary system depends on the company that runs the mint and that every transaction must go through it, like a bank.

We need a way to provide reassurance to the payee that the previous owners have not signed any previous transactions. For our purposes, the first transaction is the one that counts, so we don't have to worry about later attempts at multiple spending. The only way to confirm the absence of a transaction is to know all the transactions. In the mint-based model, the mint knew all the transactions and could decide which came first. To do this without a trustworthy party, transactions must be made public [1] and we need a system by which participants agree on a single flow of the order in which they arrived. The payee needs proof that at the time of any transaction, the majority of the nodes on the network agree that they received it first.

3. Timestamp server

The solution we propose starts with a timestamp server. A timestamp server works by taking the hash of a block of data records to be timestamped and publishing the hash widely, for example in a newspaper or in a Usenet post [2-5]. The timestamp proves that the data existed at that point in time, obviously, otherwise there would be no hash of it. Each time stamp contains the previous time stamp in its hash and forms a chain in which each additional time stamp reinforces the previous one.

4. Proof of work

In order to implement a distributed timestamp server on a peer-to-peer basis, we have to use a proof-of-work system, similar to Adam Back's Hashcash system [6], instead of the newspapers or Usenet posts. The proof-of-work includes the search for a value for which, if it is hashed, for example using SHA-256, the hash begins with a number of zero bits. The average work required is exponential to the number of zero bits required and can be verified by running a single hash.

For our timestamp network, we implement the proof-of-work in which a nonce in the block increases until a value is found that gives the hash of the block the required zero bits. After the CPU has done enough work to meet the proof-of-work, the block cannot be changed without doing the work again. Since later blocks are chained to it, the work to change the block would involve recreating all subsequent blocks.

The proof-of-work also solves the problem of determining the representatives in majority decisions. If the majority were based on one vote per IP address, it could be infiltrated by anyone who is able to reserve many IPs. Proof-of-work is basically one vote per CPU. The majority decision is represented by the longest chain in which the greatest proof-of-work effort has been invested. When a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and all competing chains will fall out. To change a previous block, an attacker would have to recreate the proof-of-work for the block as well as that of all subsequent blocks and then catch up with and overtake the honest nodes. We will demonstrate later that the chance that a slower attacker will catch up decreases exponentially as more subsequent blocks are added.

In order to compensate for increasing hardware performance and the fluctuating interest in operating a working node, the proof-of-work difficulty is determined by a moving average that targets an average number of blocks per hour. If they are generated too quickly, the difficulty increases.

5. Network

The steps to operate the network are as follows:

  1. New transactions are broadcast to all nodes.
  2. Each node collects the new transactions in a block.
  3. Each node is working to find 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. The nodes only accept the block if all transactions in it are valid and not already issued.
  6. The nodes express their acceptance of the block by working to generate the next block in the chain using the hash of the accepted block as the previous hash.

Knots always assume that the longest chain is the correct one and work to lengthen it. If two nodes are transmitting different versions of the next block at the same time, some nodes might receive one or the other version first. In this case, they work on the first one they received, but save the other branch in case it gets longer. The tie is broken when the next proof-of-work is found and a branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.

The broadcast of new transactions does not necessarily have to reach every node. As long as they reach many nodes, sooner or later they will be included in a block. Block broadcasts are also tolerant of lost messages. If a node does not receive a block, it will request it as soon as it receives the next block and realizes that it is missing one.

6. Incentives

By convention, the first transaction in a block is a special transaction that creates a new coin owned by the creator of the block. This gives new nodes an incentive to support the network and offers a way to put coins into circulation for the first time, as there is no central authority to issue them. Adding a constant number of new coins all the time is analogous to gold miners who expend resources to get more gold into circulation. In our case, it's CPU time and electricity that are consumed.

The incentives can also be promoted through transaction fees. If the initial value of the transaction is less than its initial value, the difference is a transaction fee added to the value of the incentive of the block containing the transaction. Once a predetermined number of coins have been put into circulation, the incentives can completely switch to transaction fees and thus be completely inflation-free.

The incentives can help motivate nodes to stay honest. If a greedy attacker is able to muster more CPU power than all honest nodes, he would have to choose whether to use this power to cheat people by stealing his payments back, or whether to use it to buy new coins to create. He should find it more profitable to stick to the rules - rules that can provide him with more new coins than anybody else put together - than undermining the system and thus the validity of his own prosperity.

7. Reclaim storage space

As soon as the last transaction of a coin is buried under sufficient blocks, the transactions that were used up can be deleted beforehand in order to save storage space. To make this possible without breaking the hash of the block, the transactions are stored in a Merkle tree [7][2][5] is hashed and only the root is added to the hash of the block. Old blocks can then be compressed by pruning branches from the tree. The internal hashes do not need to be saved.

A block header with no transactions takes about 80 bytes. Assuming blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4,2MB per year. With computer systems that are typically sold with 2008 GB of RAM in 2 (as of 1,2) and Moore's Law, which is currently forecasting growth of XNUMX GB, storage space should not be a problem, even if the block headers have to be kept in memory.

8. Simplified payment verification

It is possible to verify payments without operating a complete network node. All a user has to do is keep a copy of the block header of the longest proof-of-work chain, which he can obtain by querying other network nodes until he is convinced that he has the longest chain and is getting the Merkle branch that links the transaction to the block that gave it a timestamp. He cannot check the transaction himself, but by linking it to a point in the chain, he can see that it was accepted by a network node and blocks added afterwards further confirm that it was accepted by the network .

As such, the verification is reliable as long as the network is controlled by honest nodes. However, it becomes more vulnerable when the network is overwhelmed by an attacker. While network nodes can verify transactions themselves, the simplified method can be fooled by an attacker with bogus transactions as long as the attacker can dominate the network. One strategy to protect against this would be to accept alarm signals from network nodes when they detect an invalid block, which would cause the user's software to download the full block and the transactions affected by the alarm in order to confirm the inconsistency . Companies that receive regular payments will still want to run their own nodes for more independent security and faster verification.

9. Merging and sharing of values

While it would be possible to handle the coins individually, it would be impractical to make a separate transaction for every penny in a transfer. In order for values ​​to be split up and merged, transactions contain several inputs and outputs. Usually there is either a single input from a larger previous transaction or multiple inputs that summarize smaller amounts and at most two outputs: one for payment and one for returning change, if necessary, back to the sender.

It should be noted that fan-out, where one transaction depends on several transactions and those transactions in turn depend on many others, is not a problem in this case. There is never a need to get a full copy of a transaction history.

Privacy Policy

The traditional banking model achieves a certain level of data protection by limiting access to the information to the parties involved and the trustworthy third party. The need to publish all transactions precludes this method, but data protection can still be maintained by interrupting the flow of information elsewhere: by keeping the public keys anonymous. The public can see someone sending an amount to someone else, but with no information linking the transactions with anyone. This is similar to the level of information posted by stock exchanges, where the time and size of individual trades, the "tape," is posted without telling who the parties are.

As an additional firewall, a new key pair should be used for each transaction in order to avoid the keys being assigned to a common owner. Some links are still unavoidable in transactions with multiple inputs because these necessarily reveal that their inputs belong to the same owner. The risk is that if the owner of a key is revealed, the association could expose other transactions that belonged to the same owner.

11. Calculations

We consider a scenario where an attacker tries to create an alternate chain faster than the honest chain. Even if it succeeds, it does not subject the system to arbitrary changes, such as creating value out of nothing or taking money that does not belong to the attacker. The nodes will not accept an invalid transaction as payment, and the honest nodes will never accept a block that contains one. An attacker can only attempt to modify one of their own transactions in order to get money back that they recently spent.

The race between an honest chain and the chain of an attacker can be characterized as a binomial random walk. The success event is that the honest chain is extended by one block, which increases its lead by +1, and the failure is that the attacker's chain is extended by one block, which reduces the distance by -1.

The likelihood that an attacker will catch up from a given deficit is analogous to the "player ruin" problem. For example, suppose a player with unlimited credit starts out with a backlog and potentially plays an unlimited number of games in an attempt to break even. We can calculate the probability that it will ever break even, or that an attacker will ever catch up with an honest chain, as follows [8]:

p = Probability that an honest node will find the next block
q = Probability that the attacker will find the next block
qz = Probability that the attacker will ever catch up with the backlog of z blocks

Assuming that p> q, the probability falls exponentially as the number of blocks the attacker has to catch up with increases. If the odds are against him and he doesn't make a happy leap forward early on, his chances will become vanishingly small if he falls further back.

We now discuss how long the recipient of a new transaction has to wait until he is 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 for a while that they have been paid and then after some time alter the transaction so that it is repaid to themselves. The recipient will be alerted when this happens, but the sender hopes it will be too late by then.

The recipient 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 in advance by working on them until they are lucky enough to have a big enough head start and then execute the transaction at that moment. Once the transaction has been submitted, the dishonest sender secretly begins work on a parallel chain that contains a modified version of their transaction.

The recipient waits until the transaction has been added to a block and z blocks have been appended after it. He doesn't know exactly what progress the attacker has already made, but assuming that the honest blocks took the average time per block, the attacker's potential progress corresponds to a Poisson distribution with the expected value:

To calculate the likelihood that the attacker could still catch up now, we multiply the Poisson density for each sum of the progress they might have made by the likelihood they could catch up from that point:

We rearrange the formula to avoid adding up the infinite decimal places of the distribution ...

And translate this into C code ...

#include double AttackerSuccessProbability (double q, int z) {double p = 1.0 - q; double lambda = z * (q / p); double sum = 1.0; int i, k; for (k = 0; k <= z; k ++) {double poisson = exp (-lambda); for (i = 1; i <= k; i ++) poisson * = lambda / i; sum - = poisson * (1 - pow (q / p, z - k)); } return sum; }

If we run through some results, we can see how 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

Resolution for P less than 0,1% ...

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

12. Fazit

We proposed a system for electronic transactions without relying on trust. We assumed the usual system of coins created from digital signatures, which offers strong control over ownership, but is incomplete without a method to prevent double spending. To solve this problem, we proposed a peer-to-peer network that uses proof of work to record a public history of transactions that are impossible for an attacker to modify, as long as honest nodes control the majority of CPU power. The network is robust in its unstructured simplicity. The nodes all work at the same time with little coordination. They do not need to be identified as the messages are not directed to a specific location and only need to be delivered on a best effort basis. Nodes can join or leave the network at will and accept the proof-of-work as evidence of what happened in their absence. They agree with their CPU performance, express their acceptance of valid blocks by working on their expansion and reject invalid blocks by refusing to work on them. All necessary rules and incentives can be enforced using this consensus mechanism.