1
A CryptoCurrency is actually simply a ledger/audit of transactions, maintained by a decentralized peer to peer network. Amazingly, this ledger is protected by the computing power of the peer-to-peer network, and, unless an entity with malicious intentions gained control over more than 50% of the total network computing power, the ledger is safe and sound. The ledger simply contains transactions (here expressed in BTC/bitcoin): • Alice gave Bob 5 BTC • Bob gave Steve 1.5 BTC • Steve gave Frank 0.8 BTC All transactions are sent to the whole peer-to-peer network: in other words, all transactions are public, and therefore anyone who knows how to add can find out which accounts have received the most money. However, it is difficult to map any given account to a given entity, as any entity can have many accounts. It is actually difficult to express what a single coin of a cryptocurrency is, because coins exist only as parts of transactions and have no real being of their own. In cryptocurrencies, the only elements that have being are transactions and transaction blocks (more on this later). Coins themselves are not modeled as part of the protocol. This can lead to the question: how are coins created? There is a system in place (mining) that allows transactions to give coins to a recipient, without having any specific sender - thus coins are “created” from nothing through transactions. This will be explained as part of the block mining paragraph.
Une monnaie virtuelle [Ndt :cryptocurrency] est en fait tout simplement une comptabilité, une vérification des transactions, maintenue par un réseau pair à pair décentralisé. Étonnamment, ce livre de comptes est protégé par la puissance de calcul du réseau pair à pair et, à moins qu'une entité avec des intentions malveillantes prenne le contrôle de plus de 50 % de la puissance totale du réseau informatique, la comptabilité est saine et sauve.
Le livre de comptes contient simplement des transactions (ici exprimées en BTC/bitcoin) : • Alice a donné 5 BTC à Bob . • Bob a donné 1,5 BTC àSteve . • Steve a donné 0,8 BTC à Frank .
Toutes les transactions sont envoyées à l'ensemble du réseau pair à pair : en d'autres termes, toutes les transactions sont publiques et donc quiconque sachant faire des additions peut savoir quels comptes ont reçu le plus d'argent. Mais il est difficile de faire correspondre un compte donné à une entité donnée, puisqu'une entité peut avoir de nombreux comptes.
Il est en effet difficile d'exprimer ce qu'est une pièce de monnaie virtuelle, parce que les pièces n'existent qu'en tant que partie d'opérations et n'ont aucune existence réelle propre. En monnaie virtuelle, les seuls éléments qui existent sont les transactions et les blocs de transaction (voir plus loin). Les pièces elles-mêmes ne sont pas modélisées comme élément du protocole.
Cela peut conduire à la question : comment sont créées les pièces ? Il y a un système en place (appelé minage) qui permet aux transactions de donner des pièces à un destinataire, sans qu'il y ait un expéditeur spécifique (ainsi les pièces sont « créées » à partir de rien par des transactions). Cela sera expliqué dans le paragraphe sur le minage de blocs.
Making Sure a Person Has Enough Coins to Cover a Transaction Assume Alice wants to send Bob some coins. How are we sure that Alice has enough Bitcoins or other cryptocurrencies to send to Bob? To be sure that Alice has enough Bitcoins to send to Bob is easy: with each outgoing transaction, she needs to broadcast incoming transactions to show that she has enough money to send that money to Bob. So she will actually refer to transactions as below: • “I received 3 bitcoins on my wallet from Peter” • “I received 2 bitcoins on my wallet from Frodo” Therefore: “I can send 5 bitcoins to Bob’s wallet” Once this is done, the referred transactions (also known as the inputs of a transaction) will be considered to have been flagged as “Spent”, meaning she can no longer use them as referrals to send money, avoiding double-spending money (otherwise, Alice could keep referring to the 3 bitcoins she received from Peter and spend again and again from that transaction). In reality, none of the transactions are flagged as spent; it is simply easy to check all the transactions in the peer-to-peer-maintained transaction ledger to detect whether any transaction has been or is being double-spent (actually there is an index of unspent transactions to make that task easy).
S'assurer qu'une personne ait assez de pièces pour honorer une transaction
Supposons qu'Alice veuille envoyer quelques pièces de monnaie à Bob. Comment sommes-nous sûrs qu'Alice a assez de Bitcoins ou autres monnaies virtuelles pour les envoyer à Bob ?
Être sûr qu'Alice a assez de Bitcoins à envoyer à Bob est simple : à chaque transaction sortante, elle doit diffuser les transactions entrantes pour montrer qu'elle a assez d'argent pour l'envoyer à Bob. Donc, en fait, elle va faire référence à des transactions comme ci-dessous : • « J'ai reçu 3 bitcoins sur mon portefeuille de Pierre. » • « J'ai reçu 2 bitcoins sur mon portefeuille de Frodon. » Par conséquent : « Je peux envoyer 5 bitcoins sur le portefeuille de Bob. »
Une fois cela fait, les transactions en référence (aussi appelées les entrées de la transaction) seront considérées comme « dépensées », ce qui signifie qu'elles ne peuvent plus être utilisées comme références pour envoyer de l'argent, ce qui empêche les double-dépenses (autrement, Alice pourrait faire référence aux 3 bitcoins qu'elle a reçus de Pierre et dépenser encore et encore à partir de cette transaction). En réalité, aucune des transactions n'est signalée comme dépensée ; il est très facile de vérifier toutes les transactions dans la comptabilité maintenue par le réseau pair à pair pour détecter si une transaction a été, ou est, dépensée deux fois (en fait il y a un index des transactions non dépensées pour rendre cette tâche plus facile).
2
In effect, given a long list of transactions, it is computationally very difficult (and in many cases impossible) to find a set of previous transactions that show Alice received money for exactly the amount that she wants to send. This problem is well-known in mathematics, and commonly referred to as the knapsack problem. To solve this issue, with each outgoing transaction, Alice will simply refer to ALL of her previous incoming transactions (which will be flagged as spent), and two transactions will be generated: • one that goes to Bob, for 5 BTC • one that goes back to Alice, for her remaining Balance In other words, with this outgoing transaction, Alice flags all of her previous incoming transactions as spent, and replaces them by a single transaction that summarizes her remaining balance. This solves the issue of knowing whether Alice has enough to cover the outgoing transaction.
Effectivement, quand on a une longue liste de transactions, il est très difficile en terme d'algorithmique - et dans de nombreux cas impossible - de trouver un ensemble de transactions antérieures qui montrent qu'Alice a reçu de l'argent pour exactement le montant qu'elle veut envoyer. Ce problème est bien connu en mathématiques et communément appelé le problème du sac à dos.
Pour résoudre ce problème, à chaque transaction sortante, Alice va simplement se référer à l'ensemble de ses transactions entrantes précédentes (qui seront marquées comme dépensées) et deux transactions seront générées : • celle qui va à Bob, pour 5 BTC. • celle qui retourne à Alice, pour son Solde restant.
En d'autres termes, avec cette transaction sortante, Alice marque toutes ses transactions entrantes précédentes comme dépensées, et les remplace par une seule opération qui résume son solde restant.
Cela résout la question de savoir si Alice a assez d'argent pour honorer la transaction sortante.
An example is as below: • Alice received 7 bitcoins from Peter (Transaction1) • Alice received 10 bitcoins from Jason (Transaction2) • Alice received 6 bitcoins from Steven (Transaction 3) • Alice wants to send 15 bitcoins to Bob (Transaction4) So what will happen is: • Alice creates Transaction4, referring to Transaction 1, 2, and 3 as inputs, and broadcasts it to the network • Transactions 1,2,3 are therefore spent, and cannot be used as referral transactions to send money anymore • A new transaction, Transaction5, is created that gives back 8 bitcoins to Alice. That transaction is still valid, and can be used by Alice to send bitcoins later on.
Par exemple : • Alice a reçu 7 bitcoins de Pierre. (Transaction1) • Alice a reçu 10 bitcoins de Jason. (Transaction2) • Alice a reçu 6 bitcoins d'Étienne. (Transaction3) • Alice veut envoyer 15 bitcoins à Bob. (Transaction4)
Ce qu'il va se passer : • Alice crée la Transaction4, se référant aux Transactions 1, 2, et 3 comme entrées, et la diffuse sur le réseau. • Les Transactions 1,2 et 3 sont ainsi dépensées et ne peuvent plus être utilisées comme des transactions de référence pour envoyer de l'argent. • Une nouvelle transaction, Transaction5, est créée, qui redonne 8 bitcoins à Alice. Cette opération est toujours valide et peut être utilisée par Alice pour envoyer des bitcoins plus tard.
3
Making Sure That Alice is the True Originator of the Send Request One of the problems faced by cryptocurrencies was: when looking at the transaction “Alice gave Bob 5 BTC,” how are we sure that it is really Alice who sent Bob 5 BTC? Could it be that Bob sent a fake message to the peer-to-peer network saying there was such a transaction, in order to steal 5 BTC from Alice? Or might Alice be referring to other transactions that were not sent to her? Proving that Alice is indeed the owner of the money is accomplished by signing the message using a public and private key system. Basically, when receiving money from Peter and Frodo, Alice gave each sender a public key (her receiving public key, effectively an address that identifies an account), which is a 64-digit hexadecimal number. When she generated that public key, she also generated a private key, that she alone knows - it is critical to protect that private key.
S'assurer qu'Alice soit la vraie créatrice de la demande envoyée
L'un des problèmes rencontrés par les monnaies virtuelles était : quand on regarde la transaction « Alice envoie 5 BTC à Bob », comment sommes-nous sûrs que c'est vraiment Alice qui a envoyé 5 BTC à Bob ? Serait-il possible que Bob ait envoyé un faux message sur le réseau pair à pair, disant qu'il y avait une telle transaction, afin de voler 5 BTC à Alice ? Ou Alice pourrait-elle faire référence à d'autres transactions qui ne lui ont pas été envoyées ?
Prouver qu'Alice est bien la propriétaire de l'argent se fait en signant le message avec un système à clé publique et privée.
Fondamentalement, lorsqu'elle a reçu l'argent de Pierre et de Frodon, Alice a donné à chaque expéditeur une clé publique (sa clé publique de réception, en fait c'est une adresse qui identifie un compte), qui est un nombre hexadécimal à 64 chiffres. Quand elle a généré cette clé publique, elle a aussi généré une clé privée, qu'elle seule connaît ; il est essentiel de protéger cette clé privée.
For each incoming transaction (input) that Alice refers to when she wants to send money, Alice needs to prove that she is the owner of the Public key that this incoming transaction was sent to. To do so, she mathematically combines her transaction message “Alice sends 5 BTC to Bob” to the private key (linked to her incoming account public key) to generate a signature that is appended to her transaction message. This signature does not contain her private key, nor can her private key be inferred from it. However, it is possible to verify that a message was properly signed by the relevant private key by comparing the public key to that signature and the message. Therefore, all nodes on the peer-to-peer network can do the following for each transaction sent: • check the referral transactions that prove the sender has enough coins to send (i.e. that previous transactions that the sender received are enough to cover the amount being sent); • get the public key (or public keys) that the referral transactions were sent to (this should be the sender’s receiving public key); • check the signature of the send transaction against each public key and the send transaction message content; • if the signature matches the public key, then it means that indeed the sender is the owner of the private key linked to the public key that the referral transactions were sent to. The sender is therefore entitled to send that money, and mark the referral transactions as spent.
Pour chaque transaction en entrée (input) à laquelle se réfère Alice quand elle veut envoyer de l'argent, elle doit prouver qu'elle est la propriétaire de la clé publique vers laquelle cette transaction d'entrée a été envoyée. Pour ce faire, elle combine mathématiquement son message de transaction « Alice envoie 5 BTC à Bob » avec la clé privée (liée à la clé publique d'entrée de son compte) pour générer une signature qui est ajoutée à son message de transaction. Cette signature ne contient pas sa clé privée et sa clé privée ne peut en être déduite. Cependant, il est possible de vérifier si un message a été correctement signé par la clé privée correspondante en comparant la clé publique avec la signature et le message.
Ainsi, tous les nœuds du réseau pair à pair peuvent effectuer les opérations suivantes pour chaque transaction envoyée : • vérifier les transactions en référence qui prouvent que l'expéditeur a assez d'argent à envoyer (c-à-d que les transactions précédentes reçues par l'expéditeur sont suffisantes pour honorer le montant envoyé) ; • obtenir la clé publique (ou les clés publiques) vers laquelle (lesquelles) les transactions en référence ont été envoyées (qui devrait être la clé publique de réception de l'expéditeur) ; • comparer la signature de la transaction d'envoi avec chaque clé publique et le contenu du message de la transaction d'envoi) ; • si la signature correspond à la clé publique, cela signifie que l'émetteur est en effet le propriétaire de la clé privée liée à la clé publique vers laquelle les transactions en référence furent envoyées. L'expéditeur est donc en droit d'envoyer cet argent et de marquer les transactions en référence comme dépensées.
4
This ingenious system makes it easy for anybody to check whether a sender owns the private key to a public key to which money was sent, and therefore to check that the sender indeed was the recipient of enough money to be able to send money. All of this without knowing the sender’s private key! What is also interesting is that, each message being different, the signature generated by mixing the private key to that message is also always different, even though the private key itself doesn’t change. Therefore the signature not only serves to prove that the sender is the owner of a receiving account that has received enough money to cover the transaction, but also to protect the message against tampering: if anyone were to change the contents of the message (such as the public key to which the message is being sent to in order to receive it maliciously), the signature would not match the message it is attached to anymore, and the transaction would be rejected. Generating new public keys and private keys is easy, and can be done without access to the Internet - it is almost impossible to have a collision with another user, because of the sheer number of possible public keys. Cryptocurrency clients will usually do it for you. Terminology point: referral transactions are usually referred to as the “input” to a transaction, and the “output” of the transaction is the public key and account to which money is being sent.
Ce système ingénieux permet facilement, à quiconque, de vérifier si un expéditeur possède la clé privée d'une clé publique à laquelle l'argent a été envoyé, et donc de vérifier que l'expéditeur était réellement le destinataire de suffisamment d'argent lui permettant d'en envoyer. Tout cela sans connaître la clé privée de l'expéditeur !
Ce qui est également intéressant, c'est que, chaque message étant différent, la signature générée par le mélange de la clé privée avec un message est aussi toujours différente, même si la clé privée elle-même ne change pas. Par conséquent, la signature ne sert pas seulement à prouver que l'expéditeur est le propriétaire d'un compte de réception qui a reçu assez d'argent pour honorer la transaction, mais aussi pour protéger le message contre la manipulation : si quelqu'un venait à changer le contenu du message (comme la clé publique à laquelle le message est envoyé afin de le recevoir malicieusement), la signature ne correspondrait plus au message auquel elle est attachée, et la transaction serait rejetée.
Générer de nouvelles clés publiques et clés privées est facile et peut se faire sans accès à Internet ; il est presque impossible d'avoir une collision avec un autre utilisateur, en raison du nombre des clés publiques techniquement possibles. Habituellement, les clients de monnaie virtuelle s'en chargent.
Point de terminologie : les transactions de référence sont généralement désignées par le nom d'« entrées » (input) d'une transaction, et les « sorties » (output) de la transaction sont la clé publique et le compte sur lequel l'argent est envoyé.
Checking the Input Transactions Of course, all of the referral transactions need to be checked as well! This is achieved by looking at their inputs (their own referral transactions) and then checking those, all the way back to the beginning. When downloading a cryptocurrency client (such as a Bitcoin client), the first thing the client does is actually download the whole history of transactions from nodes on the network, and validate each and every one of the transactions and their inputs, and it keeps doing so for any new transactions received from the network. It also makes sure that no transaction has been referred to as input more than once, since that would indicate there was a double-spend. Thus a peer-to-peer security network, requiring no trust between nodes, is formed.
Vérification des transactions en entrée
Bien sûr, toutes les transactions de référence doivent être vérifiées aussi ! Cela se fait en regardant leurs entrées (leurs propres transactions de référence) et ensuite en les vérifiant depuis le début.
Lors du téléchargement d'un client de monnaie virtuelle (comme un client Bitcoin), la première chose que le client fait est, en fait, de télécharger tout l'historique des opérations des nœuds sur le réseau, et de valider chacune des transactions et de leurs entrées, et il continue de le faire pour toutes les nouvelles transactions reçues du réseau. Il s'assure également qu'aucune transaction n'a été désignée comme entrée plus d'une fois, car cela indiquerait qu'il y a eu une double dépense.
Ainsi se forme un réseau pair à pair sécurisé, ne nécessitant pas de relation de confiance entre les nœuds.
5
Quick Summary of What We Have Seen Thus Far A cryptocurrency is just a list of transactions, which are protected against tampering and negative balances through a public/private key system. In effect, any public key used on the network is an account, also referred to as a wallet. The only thing necessary to claim ownership of that Public key (and therefore to claim ownership of all the transactions that were sent to that public key) is the Private key linked to that Public key. That Private key gives the power to send money to another Public key address. In other words, a cryptocurrency account is a simple tuple of (public key, private key), which can be printed on paper. If you have that tuple, you own the account. All the records are kept in the peer-to-peer network, and it is therefore not necessary to keep track of anything other than your own public and private key tuples. You can at any time know how much coin each of your public keys is entitled to spend by getting the most recent ledger from the peer-to-peer network, and adding up all unspent transactions that were sent to each public key until you get your balance. All cryptocurrency transactions are irreversible. There is no customer support, no central entity to refund you. Transactions cannot be rolled back because they are already part of the public record across many nodes.
Résumé rapide de ce que nous venons de voir
Une monnaie virtuelle n'est qu'une liste de transactions, qui sont protégées contre la falsification et les soldes négatifs grâce à un système de clé publique/privée.
En effet, toute clé publique utilisée sur le réseau est un compte, également appelé un portefeuille. La seule chose nécessaire pour revendiquer le droit sur cette clé publique (et donc la revendication de propriété de toutes les transactions qui ont été envoyées à cette clé publique) est la clé privée liée à celle de la clé publique. Cette clé privée donne le pouvoir d'envoyer de l'argent à une autre adresse de clé publique. En d'autres termes, un compte de monnaie virtuelle est un simple couple de clé publique et clé privée, qui peut être imprimé sur du papier. Si vous avez ce couple, vous possédez le compte. Tous les enregistrements sont conservés dans le réseau pair à pair et il n'est donc pas nécessaire de garder une trace de quoi que ce soit d'autre que vos propres couples de clés publiques et privées.
Vous pouvez à tout moment savoir combien d'argent chacune de vos clés publiques est en droit de dépenser en obtenant la comptabilité la plus récente du réseau pair à pair et en additionnant toutes les transactions non dépensées qui ont été envoyés à chaque clé publique jusqu'à ce que vous obteniez votre solde.
Toutes les transactions de monnaie virtuelle sont irréversibles. Il n'y a pas de support client, aucune entité centrale ne vous remboursera. Les transactions ne peuvent pas être annulées parce qu'elles font déjà partie des enregistrements publics sur de nombreux nœuds.
Main sources: • the bitcoin paper: http://bitcoin.org/bitcoin.pdf • the excellent, but fast-moving, under-the-hood explanation of bitcoin (this explanation follows roughly the same structure, but spends more time on some points and less on others): http://www.imponderablethings.com/2013/07/how-bitcoin-works-under-hood.html • the Primecoin paper: http://primecoin.org/static/primecoin-paper.pdf • an explanation of the paper: http://www.reddit.com/r/primecoin/comments/1rp5vx/could_someone_explain_in_detail_the_algorithm/ COMPETITION Win 500 Dogecoin (DOGE) by answering the following question: Referral transactions are usually referred to as _ _ _ _ _ _ ? (Hint: the answer is in the article) Email your answer to: ronnie@fullcirclemagazine.org before Friday 21st March. The winner will be notified via email for a valid Dogecoin wallet address. Another 500 DOGE will be up for grabs next month in Cryptocurrency Part 2.
Principales sources : • le document de bitcoin : http://bitcoin.org/bitcoin.pdf • l'excellente, mais très rapide, explication de ce qui se passe sous le capot de bitcoin (cette explication suit à peu près la même structure, mais passe plus de temps sur certains points et moins sur d'autres): http://www.imponderablethings.com/2013/07/how-bitcoin-works-under-hood.html • le document de Primecoin : http://primecoin.org/static/primecoin-paper.pdf • une explication du document : http://www.reddit.com/r/primecoin/comments/1rp5vx/could_someone_explain_in_detail_the_algorithm/
CONCOURS
Gagnez 500 Dogecoin (DOGE) en répondant à la question suivante : Les transactions de référence sont généralement appelés _ _ _ _ _ _ _ ? (Indice : la réponse est dans l'article)
Envoyez votre réponse à : ronnie@fullcirclemagazine.org avant le vendredi 21 mars. Le gagnant sera avisé par courriel et recevra une adresse de portefeuille Dogecoin valide.
Un autre lot de 500 DOGE sera à gagner le mois prochain dans la Partie 2.