Full Circle Magazine FR

Outils pour utilisateurs

Outils du site

Piste : • c_c • finalisation • greatcowbasic • labo_linux_1 • c_c • c_c • finalisation • c_c • c_c • labo_linux
issue82:cryptocurrency

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Prochaine révision		Révision précédente
issue82:cryptocurrency [2014/06/08 17:05] – créée auntieeissue82:cryptocurrency [2014/07/02 17:10] (Version actuelle) – [5] auntiee
Ligne 1: Ligne 1:
 +===== 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. 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.
  
Ligne 11: Ligne 13:
  
 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. 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 Making Sure a Person Has Enough Coins to Cover a Transaction
  
Ligne 22: Ligne 39:
  
 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). 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. 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.
  
Ligne 28: Ligne 59:
 • one that goes to Bob, for 5 BTC • one that goes to Bob, for 5 BTC
 • one that goes back to Alice, for her remaining Balance • 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. 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. 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: An example is as below:
 • Alice received 7 bitcoins from Peter (Transaction1) • Alice received 7 bitcoins from Peter (Transaction1)
Ligne 43: Ligne 85:
 • Transactions 1,2,3 are therefore spent, and cannot be used as referral transactions to send money anymore • 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. • 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 Making Sure That Alice is the True Originator of the Send Request
  
Ligne 51: Ligne 107:
  
 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. 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. 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.
  
Ligne 59: Ligne 125:
 • check the signature of the send transaction against each public key and the send transaction message content; • 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. • 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! 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!
  
Ligne 67: Ligne 144:
  
 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. 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 Checking the Input Transactions
  
Ligne 75: Ligne 162:
  
 Thus a peer-to-peer security network, requiring no trust between nodes, is formed. 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 Quick Summary of What We Have Seen Thus Far
  
Ligne 85: Ligne 183:
  
 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. 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: Main sources:
 • the bitcoin paper: http://bitcoin.org/bitcoin.pdf • the bitcoin paper: http://bitcoin.org/bitcoin.pdf
Ligne 91: Ligne 203:
 • the Primecoin paper: http://primecoin.org/static/primecoin-paper.pdf • 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/ • an explanation of the paper: http://www.reddit.com/r/primecoin/comments/1rp5vx/could_someone_explain_in_detail_the_algorithm/
- 
  
 COMPETITION COMPETITION
  
 Win 500 Dogecoin (DOGE) by answering the following question: Win 500 Dogecoin (DOGE) by answering the following question:
-Referral transactions are usually referred to as _______ ?+Referral transactions are usually referred to as _ _ _ _ _ _ ?
 (Hint: the answer is in the article) (Hint: the answer is in the article)
  
Ligne 102: Ligne 213:
  
 Another 500 DOGE will be up for grabs next month in Cryptocurrency Part 2. 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.
 +
issue82/cryptocurrency.1402239954.txt.gz · Dernière modification : 2014/06/08 17:05 de auntiee