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. This concept allows you to create applications with incredible potential, since there is still much to discover, even outside of the financial sector, for which it was initially 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 means of payment without intermediaries between users. An ecosystem made up of combined pieces never seen to date. The document, with an academic-style presentation, is called the "Bitcoin Paper", and you can check it here.
Next, we leave you the version translated into Spanish of the Bitcoin whitepaper.
Bitcoin: A User-to-User Electronic Cash System
Satoshi Nakamoto
satoshin@gmx.com
bitcoin.org
Summary
A purely electronic version of cash would allow online payments to be sent directly, from one entity to another. All this, 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 a trusted third party has to exist to prevent the double-spending. We propose a solution to the problem of double spending using a user-to-user network.
The network timestamps the transactions it enters into a continuous chain of proof-of-work based on hash calculations. Thus, a record is being formed that cannot be changed without recreating the full proof of work. The longest chain not only serves as a token and proof of the sequence of events, but also ensures that it came from the pool with the largest CPU processing.
As long as most of the CPU processing power is under the control of nodes. that do not cooperate to attack the network. In this way, they will generate the longest chain and have an advantage over the attackers. The network itself requires a minimal structure. Messages are sent on the basis of least effort, and nodes can leave and rejoin the network whenever they see fit. Always accepting the longest chain of proof of work, as proof of what happened during your 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 minimum practical size per transaction and eliminates the possibility of carrying out 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 possibility of reversal, the need for trust expands. Merchants should take care of their customers, pestering them for more information than would otherwise be needed.
A certain percentage of fraud is accepted as inevitable. These costs and uncertainties in payments can be avoided if the person uses physical money. But there is no mechanism to make payments through a communication channel without a trusted third party. What is needed is an electronic payment system that is based on cryptographic proofs rather than trust. This is intended to allow the two interested parties to carry out transactions directly without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud. And similarly, routine escrow mechanisms could easily be put in place to protect buyers.
In this work, we propose a solution to the double spending problem using a timestamp server distributed user-to-user to generate a computational proof of the chronological order of transactions. The system is secure as long as the 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 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.
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 latest or earliest transaction is the one that counts. So we won't care about further double spending attempts. The only way to confirm the absence of a transaction is by being aware of all existing transactions. In the mint model, it was the mint that was aware of all transactions and would decide which ones came first. To achieve this without a trusted third party, transactions must be publicly announced [1], and we will need a system of participants agreeing on a single story, of the order in which these transactions were received. The beneficiary needs to know that at the time of each transaction, the majority of the nodes agreed on which one was received first.
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 do in a newspaper or Usenet post [2-5]. The timestamp proves that the data obviously must have existed at that time to be included in the data. hash. Each timestamp includes the previous timestamp in its hash, forming a chain, so that each additional timestamp reinforces the previous ones.
Work test
To implement a user-to-user timestamp server, we will need to use a proof-of-work system similar to Hashcash by Adam Back [6], rather than using a newspaper or Usenet posting. Proof of work involves scanning for a value, such that, when calculating a hash, such as SHA-256, it starts with a certain number of bits with value zero. The average work required will be exponential to the number of bits required with zero value but which can be verified by running 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.
La work test it also solves the problem of determining how to represent the majority decision. If this majority were based on one vote per IP address, it could be tampered with by someone capable of assigning many IPs. Proof of Work is essentially “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:
- New transactions are issued to all nodes.
- Each node collects new transactions in a block.
- Each node works on finding a difficult proof of work for its block.
- When a node finds a proof of work, it issues the block to all nodes.
- The block is accepted by the nodes if all the transactions in the block have been validated and not spent.
- 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 string is always considered the correct one. and they begin to work 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 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 are later switched to the one that is now longer.
Emissions of new transactions do not 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 one and realizes that it has 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 into 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.
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 shipping with 2GB of RAM in 2008, and Moore's Law predicting current growth of 1.2GB per year, storage shouldn't be an issue even if 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 searching the network nodes until convinced that they have the longest chain, and getting the branch of the Merkle tree that links the transaction to the block in which it was dated. Although you cannot verify the transaction yourself, by linking to it somewhere in the chain, you can see that it has been accepted by some node on the network, so blocks added afterwards would further confirm this acceptance by the network.
As such, verification is reliable as long as honest nodes control the network, but it becomes more vulnerable if the network is taken over 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 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 .
It must be taken into account that this system is fanned out, so that a transaction can depend on several transactions, and these in turn can depend on many more, which is not a problem. There is never a need to extract a single complete copy of transaction history.
Privacy
The traditional banking model achieves its level of privacy by limiting access to information to the parties involved and the trusted third party. The need to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information elsewhere: keeping public keys anonymous. Publicly it can be seen that someone is sending a certain amount to another person, but without information that relates the transaction to a particular person. 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.
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 multi-ticket transactions are unavoidable, which can reveal that their tickets 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 it.
Calculations
We consider the scenario where an attacker tries to generate an alternate string faster than the honest string. Even if this were accomplished, it would not open the system up to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker. Nodes would not accept an invalid transaction as payment, and honest nodes will never accept a block containing them. An attacker can try to change only his own transactions to get back money 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 drops exponentially, while the number of blocks the attacker must reach increases. With the odds stacked against him, if he doesn't make a lucky play early on, his chances become extremely slim as he falls behind.
Now, let's consider how long the recipient of a new transaction needs to wait before being sufficiently certain that the issuer cannot change it. We assume the issuer is an attacker who wants to make the payee believe they were paid for a while, then switch the transaction to pay themselves back, after some time has passed. The beneficiary will be alerted when this happens, but the sender hopes that 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 recipient waits for the transaction to be added to a block and for z blocks to have been linked after the transaction. He won't need to know the exact amount of progress the attacker has made, but assuming the 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 does not depend on trust. We start with the usual framework of coins made based on the use of digital signatures, which provides strong control of ownership, but which is incomplete if there is no way to prevent double spending. To fix this, 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 place and only need to be delivered on a best effort basis. Nodes can come and go 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.
Author
