Full Circle Magazine FR

The ledger of transactions is protected by different mechanisms, but one of the main features used is a hash algorithm. The reason why will be discussed later. A hash algorithm is simply a function that maps any input of any length, into an output of a fixed length. A very simple hash algorithm would be: “count the number of characters in the input, and pad with leading zeros until you have 10 digits”. For example, running “a word” through this algorithm would yield the result 0000000006. This algorithm would work only for inputs of less than 9999999999 characters, so in that sense it is a limited hash function that works only from a specific domain. A hash function often used in online banking is SHA256, which maps any input to a binary output of 256 bits length (or 64 hexadecimal characters, the most common representation). It is very interesting, as it is very easy to generate a hash for any data input, is almost impossible to find collisions (two different inputs that give the same output hash), the hash cannot be reverse-engineered to the original content, and of course the same input will always generate the same hash. Another essential feature is that each input will give a completely different hash, even for a very small difference. “MyHash” and “myHash” will give completely different outputs.

Le grand livre des transactions est protégé par différent mécanismes, mais l'un des principaux est un algorithme de hachage. Nous parlerons de la raison pour cela plus tard. Un algorithme de hachage n'est qu'une fonction qui transforme n'importe quelle donnée de n'importe quelle taille en un résultat d'une longueur pré-déterminée. Un très simple algorithme de hachage serait : « compter le nombre de caractères dans les données saisies et mettre assez de zéros devant ce nombre pour arriver à un total de 10 chiffres ». Par exemple, le résultat du traitement de « un mot » avec cet algorithme serait 0000000006. Cet algorithme ne fonctionnera que pour des données de moins de 9999999999 caractères et est ainsi, dans ce sens un algorithme de hachage limité qui ne fonctionne qu'à partir d'un domaine particulier.

Une fonction de hachage qui est souvent utilisée pour les opérations bancaires en ligne est la SHA256, qui transforme toute entrée en sortie binaire d'une longueur de 256 bytes (ou 64 caractères hexadécimaux, la représentation la plus usuelle). Cela est très intéressant, car il est très facile de générer un hachage pour n'importe quelle donnée, c'est presque impossible de trouver des « collisions » (deux entrées différentes qui donnent le même résultat), le hash ne peut pas être décompilé pour obtenir le contenu d'origine et, bien entendu, les mêmes données entrées généreront toujours le même hachage.

Une autre de ses caractéristiques essentielles est que chaque entrée aura comme résultat un hachage complètement différent, même si les différences sont minimes. « MyHash » et « myHash » donneront des résultats totalement différents.

Additional Security Issue: the Order of Transactions It is difficult to maintain an order of transactions. Because new transactions are continuously being propagated across the network, it would be possible for the following scenario to happen: • transaction 1 is done, and starts propagating through the network • transaction 2 is done 10 seconds later and starts propagating through the network • a peer-to-peer node much closer to the origin of transaction 2 receives transaction 2 first and transaction 1 later. For that node, the correct chronological order of transactions is transaction 2 → transaction 1. This is an issue, because it is critical to know the correct order of transactions to avoid double-spending. For example, the following scenario can occur: • a buyer pays for a product (transaction 1, referring to transaction A as input) • seller ships the product • the buyer sends a second transaction to themselves or a different public key they own (transaction 2, also referring to transaction A as input) • because of speed of propagation of the transaction in the network, some nodes may receive transaction 2 before transaction 1, and therefore declare that transaction 1 is invalid because it double-spends transaction A. • if the consensus becomes such, the seller of the product will not get paid because transaction 1 has been deemed invalid. The seller has therefore shipped a product for free. This also shows that it is difficult to obtain a consensus on the order of the transactions throughout the network. The problem can only be solved if the entire network can agree on a transaction order.

Un problème supplémentaire de sécurité : l'Ordre des Transactions

Maintenir l'ordre des transactions est difficile. Parce que de nouvelles transactions sont propagées continuellement sur le réseau, le scénario suivant devient possible :

- transaction 1 se fait et commence à se propager sur le réseau ; - transaction 2 se fait 10 secondes plus tard et commence à se propager sur le réseau ; - un nœud peer-to-peer beaucoup plus près de l'origine de la transaction 2 reçoit la transaction 2 en premier lieu et la transaction 1 plus tard. Pour ce qui concerne ce nœud-là le bon ordre chronologique des transactions est transaction 2 → transaction 1.

Ceci est un problème, car il est essentiel de connaître le bon ordre des transactions pour pouvoir éviter de dépenser le même argent deux fois.

Par exemple, le scénario suivant peut arriver : - un acheteur paie un produit (transaction 1, en se référant à la transaction A comme entrée d'argent) ; - le vendeur envoie le produit ; - l'acheteur envoie une deuxième transaction vers lui-même ou vers une autre clé publique dont il est propriétaire (transaction 2, en se référant également à la transaction A comme entrée d'argent) ; - à cause de la vitesse de propagation de la transaction sur le réseau, certains nœuds peuvent recevoir la transaction 2 avant la transaction 1 et déclarent donc que la transaction 1 est invalide parce qu'il dépense l'argent de la transaction A une deuxième fois ; - s'il y a un consensus sur ce fait, le vendeur du produit ne sera pas payé, parce que la transaction 1 a été jugée invalide. Ainsi, le vendeur aura envoyé un produit gratuitement.

Cela démontre aussi qu'il est difficile d'obtenir un consensus sur l'ordre des transactions sur le réseau entier.

Le problème ne peut être résolu que si le réseau entier peut arriver à un accord sur l'ordre des transactions.

Transaction Blocks and the Block Chain The cryptocurrency answer to that has been to group transactions in blocks, which are chronologically ordered by their “height”. The first block of transaction has a height of 0, the second block has a height of 1, the third a height of 2, etc. All transactions in one block are marked as having taken place at exactly the same time. Therefore, blocks provide a chronological order of transactions, and the chain of blocks, dynamically validated by the peer-to-peer network processing power is called the Block Chain. Transactions are worthless and are referred to as unordered or unconfirmed transactions, until they have been made part of a block. A Transaction that has been put into the latest block is said to have been confirmed once. A transaction that was put into the block directly before that is said to have been confirmed twice, etc. The reason for that is important, and will be explained in the Block Chain Security sections.

Les Blocs de Transactions et la Chaîne des Blocs

La réponse de la monnaie virtuelle à ce problème est de grouper les transactions par blocs qui sont organisés chronologiquement selon leur « hauteur ». La hauteur du premier bloc de transactions est de 0, celle du deuxième bloc est de 1, la hauteur du troisième bloc est de 2, et ainsi de suite. Toutes les transactions dans un bloc sont supposées avoir eu lieu exactement en même temps et sont étiquetées en conséquence.

Ainsi, les blocs fournissent un ordre chronologique des transactions et la chaîne des blocs, validée de façon dynamique par la puissance de traitement du réseau peer-to-peer, s'appelle la Chaîne des Blocs. Les transactions qui n'ont pas été incorporées dans un bloc sont sans valeur et dites non triées ou non confirmées jusqu'à leur incorporation dans un bloc.

On dit d'une transaction qui a été incorporée dans le bloc le plus récent, qu'elle a été confirmée une fois. On dit d'une transaction qui a été incorporée dans le bloc précédent le bloc le plus récent, qu'elle a été confirmée deux fois, etc. La raison pour tout cela est importante et je l'expliquerai dans les sections concernant la sécurité d'une chaîne de blocs.

Securing the Block Chain: Mining Of course there needs to be a system to agree on the order of the block chain, as well as to protect the block chain against any tampering (which would open the network to double-spend attacks). The first way to avoid tampering is to ensure that each block contains simply a reference to the previous block, but not a block height. Therefore, with the exception of the very first block created, a block cannot be created without having a direct parent, the previous block, and explicitly referring to that parent through that parent’s block hash (the output of the hash function applied to a block). Block heights are deduced from this ordered chain of blocks. Any node on the network can build a block from unconfirmed transactions it is aware of, and broadcast it as a suggestion of what the next block in the chain should be. Of course if every node in the network did that, there would be too many suggestions for new blocks.

Sécurisant la chaîne de blocs : le minage

Cela va sans dire qu'il faut un système pour pouvoir se mettre d'accord sur l'ordre de la chaîne de blocs et pour protéger la chaîne de blocs de toute falsification (qui rendrait le réseau vulnérable aux attaques de dépenses en double).

La première façon d'empêcher toute modification frauduleuse est de faire en sorte que chaque bloc ne contient qu'une référence au bloc précédent, mais sans une « hauteur » de bloc. Ainsi, à l'exception du tout premier bloc créé, un bloc ne peut pas être créé sans un parent direct, le bloc précédent, et en se référant explicitement à ce parent avec l'utilisation du hachage du bloc parent (le résultat de l'algorithme de hachage appliqué à un bloc). La hauteur des blocs découle de cette chaîne de blocs bien ordonnée.

N'importe quel nœud sur le réseau peut construire un bloc à partir de transactions non confirmées dont il a connaissance et le diffuser en tant que suggestion du bloc suivant de la chaîne. Bien entendu, si tout les nœuds du réseau faisaient cela, il y aurait beaucoup trop de suggestions pour de nouveaux blocs.

One way to avoid getting many block suggestions is to make creating blocks difficult. And so a very difficult task is required of every block builder. With Bitcoin, a block is created in the following way: • A node creates a block by grouping transactions and adding a reference to the previous block (the SHA256 hash of the previous block); • A small random number (referred to as the nonce) is appended to the block; • The whole block along with the nonce is passed through a SHA256 hash function with the block hash as output; • Bitcoin requires that the hexadecimal representation of the block hash be inferior to a certain value (representing the difficulty of solving a block), which leads to block hashes having a certain number of leading zeroes, giving results like 0000000000000003bd7d2916ffa0d112d0797ffa9eef32ba62a219d215e02b55. This kind of requirement is referred to as a proof-of-work requirement.

Une façon d'éviter la réception de trop de suggestions de bloc est de rendre la création des blocs difficile. Une tâche très difficile est donc requise de tout créateur de bloc. Avec Bitcoin, un bloc se crée de la façon suivante : * Un nœud crée un bloc en groupant des transactions et en ajoutant une référence au bloc précédent (le hash SHA 256 du bloc précédent). * Un petit nombre, choisi au hasard, (appelé le « nonce » ou valeur de circonstance) est rajouté au bloc. * Le bloc entier accompagné du nonce est soumis à un algorithme de hachage du type SHA256 dont la sortie est le hash du bloc. * Bitcoin demande que la représentation hexadécimale du hash du bloc soit inférieure à une certaine valeur (qui représente la difficulté de résoudre le bloc), ce qui signifie que le hash des blocs doit avoir un nombre quelconque de zéros au début et donne des résultats comme 0000000000000003bd7d2916ffa0d112d0797ffa9eef32ba62a219d215e02b55.

Ce genre d'exigence s'appelle l'exigence relative à la preuve du travail exécuté.

Because hashes are fully random, and generate completely different outputs with each different nonce, the only way to find a hash that satisfies the requirement of the network is to try nonce after nonce after nonce, until finally the hash of the block satisfies the requirement. This could take years and years for a standard desktop computer, depending on the difficulty chosen (linked to the number that the hashed value needs to be inferior to). There is a reward system for a node that manages to create a block with the correct hash: the node is entitled to put a transaction for a pre-determined amount to themselves in the list of transactions that make up the block. Currently the reward for solving a block, and making it part of the block chain, is 25 bitcoins, equivalent to 20,000 USD at time of writing! The very first bitcoin block contained a single transaction for the block author, which was the reward for creating that block (at the time 50 bitcoins).

Puisque les hashs sont entièrement aléatoires et génèrent des résultats complètement différents avec chaque nonce différent, la seule façon de trouver un hash qui convienne au réseau est d'essayer nonce après nonce, jusqu'à ce que, enfin, le hash du bloc satisfasse aux exigences. Sur un ordinateur de bureau standard, il faudrait sans doute y passer de longues années, selon le degré de difficulté choisie (liée au nombre que la valeur du hash ne doit ni égaler ni dépasser).

Il y a un système de récompenses pour un nœud qui réussit à créer un bloc avec le bon hash : le nœud a le droit d'insérer dans la liste des transactions du bloc une transaction qui leur est destinée pour une somme prédéterminée. Actuellement, la récompense pour la solution d'un bloc ajouté ensuite à la chaîne des blocs, est de 25 bitcoins, ce qui, au moment où l'article fut écrit, était l'équivalent de 20 000 $ US (presque 15 200 euros) !

Le tout premier bloc de bitcoins contenait une seule transaction pour l'auteur du bloc, autrement dit, la récompense pour la création du bloc (à l'époque, 50 bitcoins).

This whole process of creating blocks, which is very demanding computationally by having to check the block hash for each nonce value until a hash that satisfies the requirements is found, is called mining. Mining has two purposes: • It helps secure the block chain by guaranteeing that very few block candidates can be generated at any given time; • it mints new bitcoins by giving a reward to the node that successfully mined the block, and therefore puts more currency into circulation. The block mining process also further secures the block chain almost fully, but this will be explained after the next section, which describes how to deal with multiple block candidates, and introduces the concept of the longest chain.

Tout le processus de la création de blocs - qui nécessite de grandes puissances de computation, car il faut regarder le hash du bloc pour chaque valeur du nonce jusqu'à ce qu'un hash qui satisfasse aux exigences soit trouvé - s'appelle le minage. Le minage a deux objectifs : * Il aide à sécuriser la chaîne des blocs en garantissant que très peu de candidats au bloc peuvent être générés à un temps donné ; * Il crée de nouveaux bitcoins en accordant une récompense au nœud qui a résolu le bloc avec succès. Ainsi, il augmente la quantité de monnaie en circulation.

Le processus de minage de blocs sécurise la chaîne des blocs de façon presque complète, mais j'expliquerai ceci après la prochaine section où je décris le traitement des candidats aux blocs multiples et présente le concept de la chaîne la plus longue.

Securing the Block Chain: Dealing with Multiple Candidates Consider the following scenario (arrows indicate a child block that refers to its parent block): [Block 10] ← [Block 11] The latest block generated is block 11. From this block 11, a miner can start working on submitting a candidate for block 12. For this, the miner gathers the unconfirmed transactions in his block, adds the block 11 hash in there, and starts checking nonce after nonce until he gets a hash output that satisfies the currency conditions. Block 12 is thus created and added to the chain, assuming no other miner found a solution first: [Block 10] ← [Block 11] ← [Block 12]

La sécurisation de la chaîne de blocs : le traitement de candidats multiples[Bloc 11] ←

Examinez le scénario suivant (les flèches indiquent un bloc enfant se référant à son bloc parent) :

[Bloc 10] ← [Bloc 11]

Le dernier bloc créé est le bloc 11. À partir de ce bloc 11, un mineur peut commencer à travailler sur la création d'un candidat au bloc 12. Pour ce faire, le mineur rassemble les transactions dans son bloc qui ne sont pas confirmées, y rajoute le hash du bloc 11 et commence à vérifier, nonce après nonce, jusqu'à ce qu'il obtienne un résultat de hachage qui satisfasse aux conditions de la monnaie.

Le Bloc 12 est créé ainsi et rajouté à la chaîne (si aucun autre mineur n'a trouvé une solution avant) :

[Bloc 10] ← [Bloc 11] ← [Bloc 12]

Now it so happens that at roughly the same time, two miners manage to create a candidate block 13 that satisfies the currency conditions. We have two chains that start getting broadcast around the network. This is referred to as a Block Chain Fork. [Block 10] ← [Block 11] ← [Block 12] ← [Block 13A] [Block 10] ← [Block 11] ← [Block 12] ← [Block 13B] Depending on which block first reached them through the network, miners will try to find a child block to either Block 13A or Block 13B. Assume that, very quickly, a miner manages to find a child block to Block 13B, while no such child block has been found for 13A, we now have: [Block 10] ← [Block 11] ← [Block 12] ← [Block 13A] [Block 10] ← [Block 11] ← [Block 12] ← [Block 13B] ← [Block 14] This chain that includes Block 14 is now the longest, and Block 14 refers back to Block 13B. Block 14 starts propagating throughout the network. Each node that receives it will understand that the longest chain available is now the one with Block 13B and Block 14, and will discard Block 13A as invalid. Therefore the block chain that includes Block 13B is now the official main chain.

Il se trouve cependant que, à peu près en même temps, deux mineurs ont réussi à créer un candidat au bloc 13 qui satisfait aux conditions de la monnaie. Nous avons donc deux chaînes qui commencent à être diffusées sur le réseau. On appelle ceci un fork de la chaîne de blocs.

[Bloc 10] ← [Bloc 11] ← [Bloc 12] ← [Bloc 13A]

[Bloc 10] ← [Bloc 11] ← [Bloc 12] ← [Bloc 13B]

Selon le bloc qui leur est parvenu en premier au travers du réseau, des mineurs essaieront de trouver un bloc enfant de soit Bloc 13A, soit Bloc 13B.

Supposons que, très rapidement, un mineur réussit à trouver un bloc enfant du Bloc 13B alors qu'aucun bloc enfant n'a encore été trouvé pour 13A, il y a maintenant :

[Bloc 10] ← [Bloc 11] ← [Bloc 12] ← [Bloc 13A]

[Bloc 10] ← [Bloc 11] ← [Bloc 12] ← [Bloc 13B] ← [Bloc 14]

Cette chaîne comprenant le Bloc 14 est maintenant la plus longue chaîne ; en outre, le Bloc 14 se réfère au Bloc 13B. Le Bloc 14 commence à se diffuser partout sur le réseau. Chaque nœud qui le reçoit comprendra que la chaîne la plus disponible est, à ce stade, celle contenant le Bloc 13B et le Bloc14 et se débarrassera du Bloc 13A suite à son invalidité. Ainsi, la chaîne de blocs qui contient le Bloc 13B est maintenant devenue la chaîne principale officielle.

Any transactions that were included in block 13A but not block 13B will go back to the pool of unconfirmed transactions. Block 13A didn’t truly integrate the chain, the miner of that block does not receive any reward (because there is no record of the reward transaction in the main block chain), and therefore block 13A is referred to as an orphaned block. This exposes a weakness in the system: a double-spend attacker could send some currency to themselves via Transaction 1 (referring to input Transaction A), and at the same time send currency to a product seller via Transaction 2 (also referring to input Transaction A, therefore double-spending it). If Transaction 2 is accepted in Block 13A, and therefore gets confirmed once, the seller may ship the product immediately. If at the same time Transaction 1 gets accepted into Block 13B, the following will happen: • eventually Transaction 2 is put back into the pool of unconfirmed orders because Block 13A has been orphaned; • however, at the same time Transaction 1 has been accepted as part of the main block chain. Because of this, Transaction A, which it refers to, is considered Spent. • Once Block 15 starts being built, it will gather transactions. However, Transaction 2 cannot be included in the block, because it refers to Transaction A, which is already spent. Therefore the seller will have shipped a product for free.

Toute transaction contenue dans le Bloc 13A, mais pas dans le Bloc 13B, reprendra sa place parmi l'ensemble de transactions non confirmées. Le Bloc 13A n'a pas vraiment intégré la chaîne, le mineur de ce bloc-là ne recevra pas de récompense (puisqu'il n'y a pas de transaction de récompense enregistrée dans la chaîne de blocs principale) ; le Bloc 13A devient donc ce qui s'appelle un bloc orphelin.

Une faiblesse du système est ainsi mise en lumière : un attaquant qui voudrait dépenser son argent deux fois pourrait s'envoyer une somme d'argent via Transaction 1 (en se référant à la Transaction A) et, en même temps envoyer une somme d'argent à un vendeur de produit via Transaction 2 (en se référant également à la Transaction A, ce qui ferait qu'il dépense cet argent deux fois).

Si la Transaction 2 est acceptée dans le Bloc 13A et est donc confirmée une fois, le vendeur pourrait envoyer le produit immédiatement. Si, au même moment, la Transaction A est acceptée dans le Bloc 13B, voici ce qui se passera : * après un certain temps, la Transaction 2 sera remise avec les autres ordres non confirmés parce que le Bloc 13A est devenu orphelin ; * toutefois, en même temps, la Transaction 1 est acceptée comme faisant partie de la chaîne de blocs principale. Pour cette raison, la Transaction A, à laquelle elle se réfère, est qualifiée de « Dépensée ». * Une fois le Bloc 15 en construction, il rassemblera des transactions. La Transaction 2 ne peut pas y être incluse, car elle se réfère à la Transaction A, qui est déjà dépensée. Ainsi, le vendeur aura envoyé un produit gratuitement.

Because of this inherent problem, when a seller accepts bitcoins, he will want to wait until transactions have been confirmed multiple times (are older in the block chain), to make sure that he is not the victim of such a scenario. In Bitcoin, each block takes an average of 10 minutes to solve (and the difficulty is adjusted to maintain that). It is considered that waiting 6 blocks (6 confirmations) is a good way to ensure security, which means that one hour is needed before a transaction is fully validated. This is pointed out (and rightfully so) as being one of the weaknesses of Bitcoin as a currency. Other alternative coins have adopted shorter block times to fix that issue. Why is the Block Chain Secure? We have seen that there are mechanisms to ensure that there is only a single version of the block chain propagated across the network, in the end, by enforcing the longest-chain policy (in case of a fork, the chain that generates the next block the fastest wins). In addition, it is extremely difficult to tamper with the block chain (thereby enabling double-spend attacks) because each block contains as part of its payload the hash of the previous block.

À cause de ce problème systémique, quand un vendeur accepte des bitcoin, il voudra attendre que les transactions soient confirmées plusieurs fois (sont présentes depuis plus longtemps dans la chaîne de blocs), pour s'assurer qu'il ne soit pas victime d'un tel scénario.

Chez Bitcoin, il faut une moyenne de 10 minutes pour résoudre un bloc (et la difficulté est ajustée pour que ce temps reste constant). On considère qu'attendre 6 blocs (6 confirmations) est une bonne façon d'assurer la sécurité, ce qui signifie qu'il faut une heure avant qu'une transaction soit entièrement validée. Cela est considéré (à juste titre) comme étant une des faiblesses de Bitcoin en tant que monnaie.

D'autres monnaies alternatives ont choisi un temps de résolution de bloc plus court pour corriger le problème.

Pourquoi la chaîne de blocs est-elle sécurisée ?

Nous avons vu que des mécanismes existent pour s'assurer qu'il n'y a finalement qu'une seule version d'une chaîne de blocs diffusée sur le réseau, en assurant le respect de la politique de la chaîne la plus longue (en cas de fork, la chaîne qui génère le bloc suivant le plus rapidement est le vainqueur).

Qui plus est, il est extrêmement difficile de manipuler la chaîne de blocs (pour rendre des attaques de double dépense d'argent possible), parce que le hash du bloc précédent fait partie de la charge de chaque bloc.

Look at the following scenario: [Block 10] ← [Block 11] ← [Block 12] ← [Block 13] ← [Block 14] Say I want to change the official order of the transactions by having a transaction that was in Block 10 put into Block 14, enabling me to effect a double-spend attack. I can try to create a fork at the level of Block 10. To create that fork, I need to: • create an alternate version of Block 10, Block 10B, containing the transactions I want, and the hash of block 9; • to do so, I need to very quickly find a nonce that makes the hash of my new block fit the conditions of the currency (difficult); • then I need to create block 11B, with the hash of Block 10B, finding the nonce; • rinse and repeat until I create block 15B. IF I have managed that feat BEFORE the true Block 15 from the main chain has been created, then my new fork will become the longest chain, and therefore be accepted as the main chain. However, to do this, I need a lot of computing power. At least 50% of the total computing power in the network and more, as the origin point of my intended fork gets older. Currently, even the best super-computer in the world cannot match 50% of the network, so we are effectively safe. Anyway, with that kind of computing power, it would probably be more profitable just to mine many coins rather than try to subvert the system.

Regardez le scénario suivant :

[Bloc 10] ← [Bloc 11] ← [Bloc 12] ← [Bloc 13] ← [Bloc 14]

Supposons que je veuille modifier l'ordre officiel des transactions en faisant en sorte qu'une transaction qui figurait dans le Bloc 10 soit mise dans le Bloc 14, me permettant ainsi de dépenser l'argent deux fois. Je peux essayer de créer un fork au niveau du Bloc 10. Afin de créer ce fork, j'ai besoin de : * créer une autre version du Bloc 10, Bloc 10B, qui contient les transactions voulues ainsi que le hash du Bloc 9 ; * pour ce faire je dois très rapidement trouver un nonce qui rendra le hash de mon nouveau bloc conforme aux conditions de la monnaie (difficile) ; * ensuite, je dois créer le Bloc 11B, avec le hash du Bloc 10B, en trouvant le nonce ; * et ainsi de suite jusqu'à ce que je crée le Bloc 15B.

SI j'ai réussi cette prouesse AVANT QUE le véritable Bloc 15 de la chaîne principale ne soit créé, alors mon nouveau fork deviendra la chaîne la plus longue et sera donc acceptée comme chaîne principale.

Cependant, pour le faire, j'aurai besoin de beaucoup de puissance de calcul. Au moins 50 % de la puissance totale de calcul du réseau et davantage encore, lorsque le point d'origine du fork que je veux créer devient de plus en plus ancien. Actuellement, même le meilleur superordinateur au monde ne peut pas atteindre une puissance comme celle de 50 % du réseau ; ainsi, nous sommes vraiment à l'abri de telles attaques. De toutes les façons, si on avait une telle puissance de calcul, on pourrait sans doute faire plus d'argent avec le minage de beaucoup de monnaie virtuelle qu'avec des essais de contourner le système.

Cryptocurrency Parameters In fact, a cryptocurrency has only a few main parameters: • the block difficulty, which determines, on average, how much time it will take for the network to solve/mine a block (the block solving time); • the interval after which the block difficulty will be adjusted. This is necessary because as the network grows, the computing power grows, and therefore if the difficulty remains stable, the amount of time to mine a block will decrease from the target. For Bitcoin, the interval is 2016 blocks; • the reward for mining a block; • the interval after which the reward is revised (to ensure a limited supply of currency). The reward is revised for Bitcoin every 210,000 blocks; • the requirement method to mine a block, typically just specified as the hashing algorithm used. Note that cryptocurrencies usually have a target time for blocks. This target time for blocks is 10 minutes for Bitcoin, 1 minute for Primecoin. An interesting corollary is that the more computing power spent across the network mining a given coin, the faster the blocks will be solved, and thus it becomes more and more difficult to keep the block solving time fixed!

Les paramètres de la Monnaie virtuelle

En fait, une monnaie virtuelle n'a que quelques paramètres principaux : * la difficulté du bloc, qui détermine, en moyenne, le temps qu'il faudrait pour que le réseau résolve/mine un bloc (le temps de résolution d'un bloc) ; * l’intervalle après lequel la difficulté du bloc sera ajustée. Cela est nécessaire parce que, au fur et à mesure que le réseau croît, la puissance de calcul croît. Ainsi, si la difficulté reste stable, le temps nécessaire pour le minage d'un bloc n'atteindra plus le temps voulu. Pour ce qui concerne Bitcoin, l'intervalle est de 2 016 blocs ; * la récompense pour le minage d'un bloc ; * l'intervalle après lequel la récompense est rajustée (pour s'assurer que l'offre de monnaie est limitée). Pour ce qui concerne Bitcoin, la récompense est rajustée tous les 210 000 blocs ; * la méthode requise pour le minage d'un bloc ; habituellement précisée en tant qu'algorithme de hachage utilisé.

Notez bien que les monnaies virtuelles ont généralement un temps cible pour les blocs. Ce temps cible pour les blocs est de 10 minutes pour Bitcoin et 1 minute pour Primecoin. Un corollaire intéressant est que plus il y a de puissance de calcul sur le réseau, dépensée pour le minage d'une monnaie donnée, plus vite les blocs seront résolus. Ainsi il devient de plus en plus difficile de garder stable le temps de résolution d'un bloc !

Most cryptocurrencies are similar, and use two main hashing algorithms: • SHA256 • Scrypt (for which a Debian package exists) Some other currencies have more original methods. For example, Quarks uses multiple hashing algorithms on top of one another and Primecoin uses the difficulty of finding prime number chains of certain types and whose mathematical origin satisfies certain criteria, such as being a multiple of the hash of the block, as the proof-of-work method. We will go into details about what impact that choice has on mining in the next section. 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: There are two main hasing algorithms; SHA256 and ___ ? (Hint: the answer is in the article) Email your answer to: ronnie@fullcirclemagazine.org before Friday 18th April. The winner will be notified via email for a valid Dogecoin wallet address. A final 500 DOGE will be up for grabs next month, in the final part of this series, Cryptocurrency Part 3.

La plupart des monnaies virtuelles sont similaires et utilisent deux algorithmes de hachage principaux : * SHA256. * Scrypt (pour lequel un paquet Debian existe).

D'autres monnaies ont des méthodes plus originales. Par exemple, Quarks utilise de multiples algorithmes de hachage, l'un par-dessus l'autre, et Primecoin se sert de la difficulté de trouver des chaînes de nombres primes de certain types et dont l'origine mathématique satisfait à certains critères, tels qu'être un multiple du hash du bloc, comme l'exigence relative à la preuve du travail exécuté.

Dans la prochaine section, nous verrons en détail l'impact qu'a ce choix sur le minage.

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 : Il y a deux principaux algorithmes de hachage : SHA256 et _ _ _ _ _ _ _ ? (Indice : la réponse est dans l'article.)

Envoyez votre réponse à : ronnie@fullcirclemagazine.org avant le vendredi 18 avril. Le gagnant sera avisé par courriel et recevra une adresse de portefeuille Dogecoin valide.

Un dernier lot de 500 DOGE sera à gagner le mois prochain, dans la partie finale de cette série, Monnaie virtuelle, Partie 3.