It all started with the Bitcoin whitepaper, an explanatory document on the concept of a technology that, today, has no doubts. Bitcoin and its underlying technology, blockchain, have become one of the greatest technological revolutions of recent times. Its concepts allow applications with incredible potential. Much remains to be discovered, even outside the financial sector for which it was originally created.

But how did it all start?

As we explain in the article on "Who created Bitcoin?", Satoshi Nakamoto published a document in a forum in 2008. In it, he theoretically defined a global payment method without intermediaries between users. An ecosystem made up of combined pieces never seen to date. The document, with an academic style presentation, is called “Bitcoin Paper”, that you can check here.

Prepare to immerse yourself in the original words of the creator of Bitcoin. It is the first official mention of the tool that has changed much more than finance. Discover how it sought to shape a whole universe of technological revolutions around you.

Here is the version translated into Spanish of the Bitcoin whitepaper.

Bitcoin: A User-to-User Electronic Cash System

Satoshi Nakamoto

satoshin@gmx.com

www.bitcoin.org

Your Order

A purely electronic version of cash would allow online payments to be sent directly, from one entity to another. All without having to go through a financial institution. Digital signatures provide part of the solution to the problem, but the main benefits are lost if there must be a trusted third party to prevent the double spending. We propose a solution to the problem of double spending using a user-to-user network.

The network timestamps transactions it enters into a continuous chain of proof of work based on hash calculation. This creates a record that cannot be changed without recreating the complete proof of work. The longest string not only serves as a token and proof of the sequence of events. But it also ensures that it is came from the pool with the largest CPU processing.

As long as most of the CPU processing power is under the control of nodes they do not cooperate to attack the network. In this way they will generate the longest chain and will give attackers an advantage. The network itself requires a minimal structure. Messages are sent on the premise of least effort, and nodes can leave and rejoin the network whenever they please. Always accepting the longest chain of proof of work, as proof of what happened during his absence.

Introduction

Internet commerce has come to rely exclusively on financial institutions, which serve as trusted third parties, for the processing of 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, because financial institutions cannot avoid mediation in disputes.

The cost of mediation increases transaction costs. This limits the practical minimum size per transaction and eliminates the possibility of making small casual transactions, there being a higher cost for this loss and the impossibility of making non-reversible payments for non-reversible services. With the ability to reverse, the need for trust expands. Merchants should take care of their customers, annoying them by asking for more information than would otherwise be needed.

A certain percentage of fraud is accepted as inevitable. These costs and payment uncertainties can be avoided if the person uses physical money. But there is no mechanism to make payments through a communication channel without a reliable third party. What is needed is an electronic payment system that is based on cryptographic evidence rather than trust. This seeks to allow the two interested parties to carry out transactions directly without the need for a reliable third party. Transactions that are computationally infeasible to reverse would protect sellers from fraud. And likewise, routine security deposit mechanisms could be easily implemented to protect buyers.

In this paper, we propose a solution to the double-spending problem using a distributed user-to-user timestamp server to generate a computational test of the chronological order of transactions. The system is secure while honest nodes collectively control more processing power (CPU) than any group of attacking nodes.

Transactions

We define an electronic currency as a chain of digital signatures. Each owner transfers the coin to the next one by digitally signing a hash of the previous transaction and the next owner's public key and adding both to the end of the coin. A beneficiary can verify the signatures to verify the chain of ownership.

trasaction whitepaper

The problem is that the beneficiary cannot verify if any of the previous owners did not double-spend the currency. The common solution is to introduce a trusted central authority. A kind of mint, which would review whether each transaction is double-spending or not. After each transaction, the coin must be returned to the mint to generate a new coin. In this way, only the coins generated directly by this mint, are the ones that are trusted not to have double-spending.

The problem with this solution is that the fate of the entire monetary system depends on the company that manages the mint. With all the transactions having to go through them, just as a bank would act. Therefore, we need to find a way for the beneficiary to know that the previous owners did not sign any previous transaction.

For our purposes, the last or earliest transaction is what counts. So we won't mind other subsequent double-spending attempts. The only way to confirm the absence of a transaction is to be aware of all existing transactions. In the model of the mint, it was this house that was aware of all the transactions and would decide which came first. To achieve this without a trusted third party, transactions must be publicly announced [1], and we will need a system of participants who agree on a unique story, of the order in which these transactions were received. The beneficiary needs to know that at the time of each transaction, most nodes agreed on which was the first one received.

Timestamp server

The solution we propose starts with a timestamp server. A timestamp server works by hashing a block of data to be dated and publishing it widely, just as you would in a newspaper or Usenet publication [2-5]. The timestamp proves that the data obviously must have existed at the time to be included in the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, so that each additional timestamp reinforces the previous ones to a given one.

server timestamps

Work test

To implement a timestamp server following a user-to-user scheme, we will need to use a proof-of-work system similar to Adam Back's Hashcash [6], instead of using a publication in a newspaper or on Usenet. Proof of work involves exploring a value such that when computing a hash, such as SHA-256, it starts with a specified number of zero-valued bits. The average work required will be exponential to the number of bits required with zero value but that can be verified by executing a single hash.

For our network of timestamps we implement the proof of work increasing the value of a nonce field, belonging to the block, until a value is found that gives the required number of bits with zero value for the hash of the same. Once the CPU effort has been expended to satisfy the proof of work, the block cannot be changed without redoing all the work. As more blocks are chained after a given one, the work to change a block would include redoing all the blocks after this one.

work test

The proof of work also solves the problem of determining how to represent the decision by majority. If this majority were based on one vote per IP address, it could be altered by someone capable of assigning many IPs. Proof of work is essentially equivalent to “one-CPU-one-vote”. The majority decision is represented by the longest chain, which has the proof of work with the greatest effort invested.

If the majority of the CPU power is controlled by honest nodes, the honest chain will grow faster and will leave behind any other chain that is competing. To modify a block in the past, an attacker would have to retest the block and all subsequent blocks, and then catch up and pass the work of the honest nodes.

We will then demonstrate that the probability that a slower attacker can reach the longest chain decreases exponentially as more subsequent blocks are incorporated.

To compensate for the increased speed of the hardware and the variable interest of executing nodes over time, the difficulty of the proof of work is determined by a moving average directed by an average number of blocks per hour. If these are generated very quickly, the difficulty increases.

The net

The steps that the network executes are the following:

  1. New transactions are issued to all 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 node finds a proof of work, it issues the block to all nodes.
  5. The block is accepted by the nodes if all the transactions in the block have been validated and not spent.
  6. The 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 longest chain is always considered the correct one and they start 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 receive but save the other branch in case it becomes longer. The tie is broken when the next proof of work is found and a branch becomes longer; nodes that were working on the other branch are later changed to the one that is now longer.

New transaction emissions do not necessarily need to reach all nodes. By the time they reach many nodes, they will end up entering a block before long. The emission of the blocks is also tolerant to the loss of messages. If a node does not receive a block, it will ask for it when it receives the next block and realizes that it lost one.

Incentive

By convention, the first transaction in the block is a special transaction that generates a new currency owned by the creator of the block. This adds an incentive for nodes to support the network, and provides an initial way to distribute and circulate the coins, since there is no authority to create them. This stable addition of a constant amount of new coins is analogous to gold miners who spend resources to put it into circulation. In our case, the resources are the CPU time and electricity that are spent.

The incentive can also be established with transaction costs. If the output value of a transaction is less than the input, the difference will be a transaction fee that will be added to the incentive value of the block that contains it. Once a predetermined number of coins have entered circulation, the incentive can evolve entirely at transaction fees and be completely free of inflation.

The incentive can also help encourage nodes to stay honest. If a selfish attacker is able to muster more CPU power than all honest nodes, he would have to choose between using it to defraud people by stealing their payments, or using it to generate new coins. You should find it more profitable to play by the rules, as they will favor you with more coins than combining all other nodes, than undermining the system and the validity of your own wealth.

Claiming Disk Space

Once the last transaction is buried under enough blocks, the spent transactions prior to this one can be discarded to save disk space. To facilitate this without breaking the block hash, transactions are checked in a merkle tree [7] [2] [5], with only the root included in the block hash. Old blocks can be compacted by removing branches from the tree. Interior hashes do not need to be saved.

merkle tree

The header of a block without transactions will be about 80 bytes. If we assume that each block is generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computers generally being sold with 2GB of RAM in 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 remain in memory.

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 chain of the proof of work, which can be obtained by doing a search in the nodes of the network until he is convinced that he has the longest chain, and get the branch of the Merkle tree, which links the transaction to the block in which it has been dated. Although you cannot verify the transaction yourself, by linking it somewhere in the chain, you can see that some node on the network has accepted it, so that the blocks added afterwards would further confirm this acceptance by the network.

payment verification

As such, the verification is reliable as honest nodes control the network, but becomes more vulnerable if the network is dominated by an attacker. While network nodes can verify transactions themselves, the simplified method can be fooled by transactions fabricated by an attacker as long as the attacker can dominate the network. One strategy to protect yourself is to accept alerts from the network nodes when they detect an invalid block, asking the user to download the entire block and the alerted transactions to confirm the inconsistency. Businesses that frequently receive payments will want to run their own nodes for more independent security and faster verification.

Combining and Dividing Value

Although it would be possible to manipulate currencies individually, it would be difficult to handle making separate transactions for each cent of a transfer. To allow the value to be split and combined, the transactions contain multiple inputs and outputs. Typically there will be either a single entry, from a previous larger transaction, or multiple entries combining smaller amounts, and at least two exits: one for payment, and one to return the change, if any, back to the issuer .

Combining and Dividing Value

Keep in mind that this system is fan-shaped, so that a transaction can depend on several transactions, and those in turn depend on many more, which is not a problem. There is never a need to extract a single complete copy of the transaction history.

Privacy

The traditional banking model achieves its level of privacy by limiting access to information to the parties involved and to the trusted third party. The need to post all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information elsewhere: by keeping public keys anonymous. It can be publicly seen that someone is sending a certain amount to someone else, but without information linking the transaction to anyone in particular. This is similar to the level of information displayed on stock exchanges, where the time and size of individual transactions, the "tape," are public, but without saying who the parties are.

traditional privacy model

As an additional firewall, a new key pair must be used for each transaction so that they can be associated with a common owner. Some types of association with multiple entry transactions are unavoidable, which can reveal that your entries belong to the same owner. The risk would be that if the owner of a key is revealed, then the linker could reveal other transactions that belonged to the same owner.

Calculations

We consider the scenario where an attacker tries to generate an alternate chain faster than the honest chain. Even if this were achieved, it would not open the system to arbitrary changes, such as creating value out of the air or taking money that never belonged to the attacker. Nodes would not accept an invalid transaction as payment, and honest nodes would never accept a block containing them. An attacker can only try to change only his own transactions to take back money that he has recently spent.

The race between an honest chain and an attacker's chain is characterized as a Random Binomial Path. The success event is the honest chain extending in an additional block and increasing its advantage by +1, and the failure event being the attacking chain extending in one block reducing the distance by -1.

The probability that an attacker can hit us, from a given deficit, is analogous to the Player Ruin problem. Suppose a player with unlimited credit starts out in deficit and potentially plays an infinite number of attempts to try to break even. We can calculate the probability that it reached the equilibrium point, or that it reaches the 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 q

qz = probability that the attacker will reach from z blocks behind.

Given our hypothesis that p> q, the probability falls exponentially while the number of blocks the attacker must reach increases. With the odds against you, if you don't make a lucky play early on, your chances become extremely small the further you fall behind.

Now let's consider how long the beneficiary of a new transaction needs to wait before being sufficiently certain that the issuer cannot change it. We assume that the issuer is an attacker who wants to make the payee believe that he was paid for a while, then change the transaction to pay himself back after a while, the payee will be alerted when this happens, but the issuer hopes it is too late.

The beneficiary generates a new key pair and delivers the public key to the issuer shortly after signing. This prevents the issuer from preparing a blockchain ahead of time, and may be working on it continuously until it is lucky enough to get ahead of itself, and then execute the transaction at that point. Once the transaction is submitted, the rogue issuer secretly begins working on a parallel chain that contains an alternate version of their transaction.

The payee waits for the transaction to be added to a block and for z blocks to be linked after the transaction. You don't need to know the exact amount of progress the attacker has made, but assuming honest blocks took the expected average per block, the attacker's potential progress will be a Poisson distribution with an expected value of:

To get the probability that the attacker can still reach us now, we multiply the Poisson density by the amount of progress he could have made times the probability that he could reach that point:

We re-organize to avoid the sum of the infinite tail of the distribution ...

We convert to code in C…

#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;
}

We run some results, we can see that the probability falls 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

We solve 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

Conclusions

We have proposed a system of electronic transactions that do not depend on trust. We start with the usual framework of coins made based on the use of digital signatures, which provides strong ownership control, but which is incomplete if there is no way to prevent double spending. To fix it, we propose a user-to-user network that uses proof of work to record a public history of transactions and that quickly becomes computationally unsolvable for an attacker who wants to change it, if honest nodes control most of the CPU power.

A robust network for its unstructured simplicity. The nodes can all work at the same time with little coordination. They do not need to be identified, since the messages are not routed to any particular location and only need to be delivered on the best effort basis. Nodes can go to and from the network at will, accepting the proof of work chain as proof of what happened while they were away. They vote with their CPU power, expressing their acceptance of valid blocks by working by extending and rejecting invalid blocks by refusing to work on them. Any necessary rules or incentives can be enforced with this consensus mechanism.

References

  • [1] W. Dai, "b-money," https://www.weidai.com/bmoney.txt, 1998.
  • [2] H. Massias, XS Avila, 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.
  • [3] S. Haber, WS Stornetta, “How to time-stamp a digital document,” In Journal of Cryptology, vol 3, no 2, pages 99-111, 1991.
  • [4] D. Bayer, S. Haber, WS Stornetta, “Improving the efficiency and reliability of digital time-stamping,” In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993.
  • [5] S. Haber, WS Stornetta, “Secure names for bit-strings,” In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997.
  • [6] A. Back, “Hashcash - a denial of service counter-measure,” https://www.hashcash.org/papers/hashcash.pdf, 2002.
  • [7] RC Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, April 1980.
  • [8] W. Feller, "An introduction to probability theory and its applications," 1957.