White Paper Bitcoin translated in French

White Paper Bitcoin translated in French by thefinancespa.com

The bitcoin : a system of electronic currency in peer-to-peer

Satoshi Nakamoto

[email protected]


Translated in french from bitcoin.org/bitcoin.pdf by @bycoin24

Summary. A version exclusively peer-to-peer electronic cash would allow online payments to be sent from one person to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a third party is still required to prevent double spending.

We propose a solution to the problem of double spending by using a peer-to-peer. The network timestamps transactions by cutting in a string based on frames with “proof of work” (proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest string not only serves as a proof of sequence of events witnesses, but also proves that it comes from the grouping CPU the most powerful. As long as the majority of CPU power is controlled by nodes that do not cooperate to hack the network, they will generate the longest chain and outpace attackers. The network itself requires a structure that is minimalist. Messages are broadcast on a basis of ” best effort “, and nodes can leave and join the network at their will, accepting the longest chain of proof of work as evidence of what has happened during their absence.


  • Introduction
  • Commerce on the internet has come to rely almost exclusively on financial institutions serving as trusted third parties in the process of electronic payment. Although the system works sufficiently well for most transactions, it still suffers the weaknesses inherent in his model is based on trust. The transaction is a totally non-reversible, are not really possible since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum size of transaction is useful, preventing the possibility of small transactions are common, with more significant cost in the loss of the ability to make payments, non-reversible for non-reversible. The possibility of reversibility brings a need to trust. Merchants must be suspicious vis-à-vis their clients, asking a lot of information they would need otherwise. A certain percentage of fraud is accepted as unavoidable. These uncertainties of costs and payments can be avoided in person by using currencies with the physical, but there is no mechanism to create payments over a communications channel without a trusted third party.

    What is needed is an electronic payment system based on cryptographic proof instead of a model based on trust, allowing both parties to transact directly between themselves without having recourse to a trusted third party. Transactions that are computationally unable to be reversible would protect sellers from fraud, and routine mechanism to deposit in escrow could easily be implemented to protect buyers. In this article, we propose a solution to the problem of double spending by using a server time-stamped and distributed in peer-to-peer to generate a computer evidence of the chronological order of transactions. The system is secure as long as knots are honest together control more CPU power than nodes of groups pirates cooperative.


  • The transaction
  • We define a piece of electronics as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a digest of the previous transaction and the public key of the next owner and then adds it all to the end of the piece. A recipient may review the signatures to verify the chain of ownership.

    Of course, the problem is that the recipient cannot verify that one of the owners has not spent twice the room. A common solution is to integrate a central authority of trust, or ” hotel des monnaies “, which checks each transaction to avoid double spending. After each transaction, the coin must be returned to the mint to distribute a new coin, and only coins directly from the mint are trusted as not being from a double expense. The problem with this solution is that the fate of the monetary system whole depends on the company that runs the hotel of currencies, all transactions are transmitted just as in a bank.

    We need a way for the recipient to know that the previous owner does not sign transactions ago. For this purpose, the first transaction is the one that counts, so we don’t care about later attempts to double-spending. The only way to confirm the absence of a transaction is to be aware of all transactions. In the model based on the mint, he was aware of all transactions and decided which arrived first. To achieve this without a trusted third party, transactions must be publicly announced [1], and we need a system in which participants agree on a single history of the order in which they were received. The recipient needs proof that at the time of each transaction, the majority of the nodes agree that the first transaction is received.


  • The servers time-stamp
  • The solution we propose begins with a timestamp server. A timestamp server works by taking a piece of block product, which must be time-stamped, and then sharing on a large scale, such as on a log or a Usenet article [2-5]. The timestamp proves that the data had to exist in the time, of course, in order to be integrated in the footprint. Each timestamp includes the time-stamp preceding it in its footprint, forming a chain in which each time stamp additional reinforces the previous one.


  • Proof of work
  • To implement a time-stamp server distributed over a network peer-to-peer, we’re going to need to use a system of “proof of work” similar to the system Hashcash by Adam Back, rather than a newspaper or a Usenet article. The proof of work requires to find a value such that its footprint, calculated for example using the algorithm SHA-256, begins with a certain number of bits to 0. The work required is exponential with the number of bits to zero is necessary and can be verified by running a single footprint.

    For our network, time-stamp, we implement the proof-of-work by incrementing a variable in the block until a value giving a footprint having enough bits to 0 is found. When the effort CPU has been used to satisfy the proof-of-work, the block cannot be changed without having to redo this work. And while the following blocks happen after it, work to change the block would require to rework all the following blocks.

    The proof-of-work also solves the problem of determining representation in majority decision-making. If the majority was based on the mode, one IP address equals one vote, this could be hacked by someone able to allocate many IPs. The proof-of-work is essentially based on a CPU equals a vote. The majority decision is represented by the string the longest, which has the greatest proof-of-work. If a majority of the computing power of CPU is controlled by the nodes are honest, then chain honest is going to grow quickly and exceed any chain competitor. To modify an old block, the attacker would need to redo all the proof-of-work of the block and all other blocks following, and then catch up with and surpass the work of the nodes are honest. We will show later that the probability that an attacker with little CPU power can catch up diminishes exponentially as more blocks are added.

    To compensate for the increase in the speed of calculation and the interest in changing the operation of nodes in the network, the difficulty of proof of work is determined by a moving average targeting an average number of blocks per hour. If the blocks are being generated too quickly, the difficulty increases.

  • Network
  • The steps in the operation of the network are the following :

    • 1 – new transactions are broadcast to all nodes.
    • 2 – Each node collects new transactions into a block.
    • 3 – Each node works on finding a proof of hard work for its block.
    • 4 – When the node finds a proof-of-work, it broadcasts the block to all nodes.
    • 5. nodes accept the block only if all transactions inside are valid and have not already been spent.
    • 6. nodes express their acceptance of the block by working on creating a new block in the chain, with as footprint previous that of the block accepted.

    Nodes always consider the longest string as a correct string, and go to work on his extension. If two nodes broadcast different versions of the next block simultaneously, some nodes will potentially receive one or the other first. In this case, they are working on the first received, but save the other branch in case it becomes longer. The pear will be cut in two when the next proof-of-work is found and one branch becomes longer ; the nodes that were working on the other branch will then switch to the longer.

    The dissemination of the new transactions does not necessarily need to reach all nodes. As long as they reach many nodes, they will integrate a block in a short time. The distribution of the blocks is also tolerant to lost messages. If a node does not receive a block, it will request it when it receives the next block and will realize that he misses one of them.


  • 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 is an incentive for nodes to participate in the network, and provides a means of initial distribution of coins in circulation, because there is no central authority to distribute them. Adding a regular constant amount of new coins is analogous to a gold miner who extends its resources to add gold to circulation. In our case, it is the time of the calculation power of the CPU and power which is extended.

    The incentive can also be funded with transaction fees. If the output value of a transaction is less than the input value, the difference is the transaction fee that is added to the value incentive of the block containing the transaction. Once a predetermined number of coins have entered circulation, the incentive will be on a funding based entirely on transaction fees, without any inflation.

    The incentive can encourage nodes to stay honest. If a hacker covetous man is able to assemble more CPU power that the nodes are honest, it would have to choose between scamming people by stealing payments or generate new parts. He must find it more profitable to follow the rules, they favor it with more new parts than anyone else combined, rather than to undermine the system and the value of his own fortune.


  • Save disk space
  • Once the latest transaction in a coin is buried under enough blocks, the transaction spent previously can be abandoned to save disk space. To facilitate this without breaking the imprint of the block, the transactions are cut in a tree of Merkle [7][2][5], of which only the root is integrated in the footprint of the block. The old blocks can be compressed by cutting of the branches of the tree. Fingerprints internal do not need to be recorded.

    A header block without transaction weighs about 80 bytes. Assuming that blocks are generated every 10 minutes, 80octets * 6 * 24 * 365 = 4.2 Mb per year. With computer systems have typically 2gb of RAM in 2008, and thanks to Moore’s law predicting the current evolution of 1.2 Gb per year, storage should not be a problem even if the header block must be kept in memory.

  • The payment verification simplified
  • It is possible to verify payments without the use of a node in entire network. A user only needs to keep a copy of all headers block of the chain of evidence is longer, which can be obtained by the requesting nodes in the network until it is certain of having the longest chain, and obtain the branch of Merkle linking the transaction to the block on which it is time-stamped. It can not verify the transaction itself, but by linking it to a position in the string, it can be seen that a node in the network has accepted it, and blocks added in the following will confirm that the network has accepted it.

    So made, the verification is reliable as long as the nodes are honest control the network, but becomes more vulnerable if the network is taken by pirates with more computing power. While network nodes can verify transactions for themselves the simplified method can be fooled by a transaction created by a hacker as the latter is able to control the computing power of the network. A strategy to protect against this is to accept alerts from network nodes when they detect a block to be invalid, prompting the software to the user to download the entire block, and the transactions alerted to confirm the inconsistency. The businesses that receive payments frequent will probably still want to run their own nodes for more independent security and audits faster.

  • Combine and split the values
  • Although it is possible to handle coins individually, it would be impractical to conduct a transaction split for every cent in a transfer. In order to allow the values to be combined and split, the transactions have multiple inputs and outputs. Usually, there will be either a single input from a previous transaction more large, or multiple inputs combining smaller amounts, and at most two outputs : one for the payment and the other to make the money, if need be, to the issuer.


    It should be noted that the dispersion, when a transaction depends on several transactions, and these transactions, which themselves depend on a lot more transactions, is not a problem here. There is never the need to extract the full history of a transaction.

  • Privacy
  • The model of traditional banking gets a level of privacy by limiting access to information to the parties involved and to the trusted third party. The need to announce the transaction publicly ruled out this method, however, confidentiality may be maintained by breaking the flow of information to a specific level : by keeping public keys anonymous. Everyone 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 of the stock transactions, in which the time and size of each exchange, the ” market price “, is made public, but without revealing the information of the parties involved.

    As additional protection, a new key pair should be used for every transaction in order to avoid that they are linked to a common owner. Relationships are always inevitable with the transactions multi-entries, which reveal necessarily that the inputs belong to the same owner. The risk is that the owner of the key is revealed, the link could reveal other transactions that belong to the same owner.

  • Calculations
  • We consider the scenario of an attacker trying to generate an alternative channel more quickly than the chain honest. Even if this is true, it does not lead the system to an arbitrary change, such as creating value out of nowhere or taking money that does not belong to the attacker. Nodes will not accept invalid ones as payment, and the nodes are honest will never accept a block containing them. An attacker can only try to change one of its own transactions in order to recover the money that he recently spend.

    The race between the chains honest, and channels, hackers can be characterized as a Random Walk Binomial. The event of success is when the chain honest extends from one block, increasing its lead by +1, the failure event is when the chain pirate extends from one block, reducing the spread was -1.

    The probability that an attacker catches up with a delay given is analogous to the problem of the bankruptcy of a bettor. Imagine that a bettor credit unlimited starts with a deficit and plays potentially an infinite number of trial to reach a profitability threshold. It is possible to calculate the probability that it reaches this threshold, or in our case a hacker catches up with the chain honest, as follows :

    p = the probability a node is honest finds the next block

    q = the probability that an attacker finds the next block

    qz = the probability that an attacker manages to catch up from z blocks behind.



    Under the assumption that p > q, the probability drops exponentially when the number of blocks that the attacker needs to catch up with increases. If the odds are not on his side, if he does not get a boost of luck, his chances disappear as he sinks in the chain.

    We now consider the length of time for the recipient that a transaction needs to wait before being sufficiently certain the sender can’t change the transaction. We assume that the issuer is a pirate who wants to make believe to the recipient that he has paid for it for a while, and then eventually pay him-even after that time. The recipient will be alerted when it happens but the sender hopes that this will be too late.

    The recipient generates a new key pair and makes the public key to the issuer promptly after the signature. This prevents the sender from preparing a chain of block in advance of phase by working continuously until he is lucky enough to be far ahead, and then executes the transaction at that time. Once the transaction is sent, the transmitter dishonest begins to work secretly on a chain parallel containing an alternate version of his transaction.

    The recipient waits until the transaction is added to a block and z blocks have been linked after that. He does not know the status of the pirate, but it assumes that the blocks honest have taken the average time waited per block, the potential progress of the attacker will behave like a Poisson distribution with the expected value as follows :

    To get the probability that the attacker can catch up on its delay, we multiply the density of Fish for each amount of improvement he might have made by the probability he could catch up to this point :

    Rearranging the equation to avoid sommer the infinity of the distribution…

    Conversion in C language…

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


    After some calculations, we observe that the probability falls exponentially with z.


    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


    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


    Results 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



  • Conclusion
  • We just propose a system for electronic transactions that are not based 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 means of avoidance of double spending. To resolve this, we propose a peer-to-peer network using proof of work to record a public historical record of transactions that quickly becomes computationally impossible to change it to a pirate in the case where the nodes are honest are controlled by the majority of the computing power of CPU. The network is robust due to its simplicity, non-structured. The nodes work in concert with little coordination. They do not need to be identified, since messages are not routed to a particular place and simply need to be issued on a best-effort. The nodes can leave and join the network at their convenience, accepting the chain of proof of work as evidence of what just happened in their absence. They vote with their computing power, and express the acceptance of the blocks that are valid by working on their extension, and rejection of blocks invalid by refusing to work on them. No matter what the necessary rules and incentives can be enforced by a mechanism of consensus.



    References :

    [1] W. Dai, “b-money,” http://www.weidai.com/bmoney.txt, 1998.

    [2] H. Massias, X. S. 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, W. S. Stornetta, “How to time-stamp a digital document,” In Journal of Cryptology, vol 3, no2, pages 99-111, 1991.

    [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.

    [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.

    [6] A. Back, “Hashcash – a denial of service counter-measure,”http://www.hashcash.org/papers/hashcash.pdf, 2002.

    [7] R. C. 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.