3.2) Recevoir une transaction

Remarque préliminaire (TRÈS IMPORTANT)

Avec le système IOTA, la sécurité de vos transactions diminue à chaque fois que vous envoyez une transaction d'une adresse donnée. Afin d'assurer que tout se passe avec la meilleure sécurité possible, il convient de générer une nouvelle adresse de réception à chaque fois que vous effectuez une transaction sortante et de ne plus envoyer de IOTA sur l'ancienne adresse.
Si vous ne faites qu'envoyer des IOTAs vers votre wallet, vos adresses ne courent aucun problème. Mais il est tout de même conseillé de lire l'explication ci-dessous.

L'image suivante explique pourquoi il ne faut pas réutiliser une adresse qui a déjà servi à envoyer des IOTAs.

Pour simplifier, on peut considérer qu'une adresse IOTA fonctionne comme une tirelire. Au début vous pouvez mettre des IOTAs dedans autant que vous voulez, mais quand vous devez retirer de l'argent (même juste une partie), vous êtes obligés de casser la tirelire (ce qui se traduit par une perte de sécurité au niveau de votre adresse). Pour protéger le reste de vos IOTAs, votre wallet va automatiquement les transférer vers une nouvelle adresse pour les remettre en sécurité (ça se passe sans que vous le voyiez). Par la suite, il faudra alors "regénérer" une adresse avec le Wallet pour y envoyer de nouveau des IOTAs (et donner cette nouvelle adresse aux gens qui seraient suceptibles de vous envoyer des IOTAs). Si vous ne le faites pas, celà revient à continuer a remplir une tirelire déjà cassée, ce qui a pour effet immédiat de faciliter grandement le piratage de cette adresse. Dans l'éventuel cas où ça se produirait, sachez enfin que seuls les IOTAs transférés à l'adresse compromise courent un risque de piratage, ceux restant de la transaction originelle ne risquent rien vu que le wallet les a transféré ailleurs.

Ce fait de ne pas comprendre ceci est la cause principale de vol des IOTAs des utilisateurs. IL EST PRIMORDIAL D'EN TENIR COMPTE SI VOUS COMPTEZ FAIRE DES TRANSACTIONS SORTANTES. Pour information, le nouveau UCL Wallet devrait inclure une fonction automatisant ce processus pour ne plus que vous ayez a vous en soucier. Cependant aucune date pour sa sortie définitive n'a été annoncée actuellement. Il faut donc se contenter du light wallet à l'heure actuelle.

Générer une adresse

Dans votre light Wallet :

  1. Cliquez sur "Receive"
  2. Cliquez sur "Attach address to Tangle"
    1. Attacher une adresse au Tangle devrait prendre entre quelques secondes et une à deux minutes. (Par simplicité, il est préférable de générer une nouvelle adresse pour chaque nouvelle transaction que vous recevez. [Plus de détails à venir]).
    2. Note : Votre nouvelle adresse apparaitra dans l'historique comme étant sous le status "Pending". C'(est parfaitement normal, car les adresses nouvellement attachées n'ont pas besoin d'être confirmées.
  3. Maintenant que votre adresse est attachée, cliquez sur l'adresse pour la copier. Vous pouvez maintenant donner cette adresse à n'importe qui afin de recevoir des IOTA ! (vérifiez bien que vous leurs transmettez bien l'adresse et pas votre seed quand même).

Pourquoi attacher une adresse à la Tangle ?

C'est juste un petit truc qui permet au wallet de savoir quelles adresses ont été utilisées. Ce permet aussi au réseau d'être un peu plus actif en ajoutant une nouvelle transaction. [Plus de détails à venir]

Note : Il n'est techniquement pas obligatoire d'attacher une adresse au Tangle pour recevoir votre transaction. C'est simplement une petite foncitonnalité du wallet. Vous recevrez aussi vos IOTAs sur une adresse non attachée.

Temps de confirmation d'une transaction?

Le temps de confirmation d'une transaction est un sujet très complexe et qui dépend d'une multitude de facteurs. Dans le meilleur des cas, les transactions sont validées en quelques secondes à peine, mais il est possible que certaines prennent plusieurs heures.

Avec les développements du système et du réseau, ce temps de transaction devrait se stabiliser et décroitre assez rapidement vers quelques secondes à chaque fois.

Comme expliqué au chapitre 1, lorque quelqu'un envoie une transaction, il doit d'abord valider cette transaction puis ensuite valider deux autres transactions (des _tips _du tangle), soit lui même soit en demandant à un full node de le faire pour lui.

La réception de IOTAs entre deux wallet

A ce moment là, le temps de transaction vient principalement de la proof of work que doit réaliser l'envoyeur de celle que doit réaliser le full node et puis surtout du temps que mettra une autre transaction à valider la votre. Comme nous l'avons vu précédemment ce dernier temps devrait se réduire avec le nombre de transactions qui augmente.

Si une transaction met vraiment longtemps à arriver et apparaît comme étant "pending" dans votre historique, cliquez sur "show bundle" (qui se trouve jsute en dessous de la transaction dans la section historique), puis cliquez ensuite sur "reattach". Vous pouvez vous réattacher un fois toutes les 30 minutes tant que cette transaction reste en attente.
Si vraiment après de nombreux réattachement sans confirmation vous n'avez toujours pas recu la transaction, il est également possible que votre hôte soit désyncronisé. Pour changer d'hôte, il faut cliquer sur "Tools" > "Edit Node Configuration" > choisir un hôte différent dans la liste et puis essayer de se réattacher à nouveau.

La réception de IOTAs au départ d'une exchange

Ce cas de figure est un peu plus particulier. En effet, contrairement aux autres cryptos, le IOTA nécessite que la Proof of Work soit faite en interne, puis par un full node pour deux autres transactions. En général, les autres blockchains nécessitent celle en interne puis envoie le reste sur le réseau en attendant qu'un mineur les insérent dans un bloc.

Donc lorsque beaucoup de gens veulent retirer les IOTAs des exchanges vers leurs wallet (typiquement après un gros rallye), les servers de l'exchange qui servent de full nodes se retrouvent débordés. En effet, comme une PoW prends un temps prédéfini, il leur est impossible de traiter les transactions plus vite. Donc l'exchange créer une liste d'attente interne et y stock provisoirement les transactions en attendant que leur full node fasse les trois PoW (celle de la transactions et les deux autres de validation). A cette étape du processus, votre transaction apparait sur l'échange comme étant "pending" ou "en cours de traitement", mais n'apparait pas encore dans la section historique de votre wallet ou dans un tangle explorer. Une fois que c'est votre tour, le full node de l'échange traitera votre transaction et la postera sur le tangle. A ce moment vous pourrez alors la voir dans l'historique comme étant "pending" en attendant que deux autres transactions valident la votre. Et SEULEMENT A CE MOMENT, si la transaction met du temps à arriver, vous pouvez essayer de la réattacher comme pour le cas de transferts entre deux wallets.

Cas particulier : l'attaque de spam

Il arrive parfois que des gros cons petits plaisantins s'amusent à spammer le tangle en y postant un nombre énorme de transactions. Dans ces cas, les full nodes sont débordés en essayant de se tenir à jour, et à cela vient s'ajouter le fait que les transactions nouvellement postées viennent plus souvent valider des transactions de spam inutiles que vos transactions à vous. Donc par conséquent, les transactions légitimes mettent plus de temps à être validées. La seule chose à faire à ce moment est d'attendre que l'attaque de spam soit finie pour réattacher votre transaction, afin de ne pas alourdir encore la charge des full nodes et de vous énerver en vain.
Sachez toutefois que la fondation IOTA pourrait très bien empêcher que ces attaques de spam bêtes et méchantes ne se produisent. Toutefois, elles fournissent un excellent moyen d'analyser le comprtement du tangle sous stress intense (et surtout pour pas un rond, alors que sinon ça nécéssiterait pas mal d'argent). Donc c'est un mal pour un bien, car les informations récoltées pendant ce type d'attaque permettent à la fondation d'améliorer le code du tangle et de le rendre plus robuste, fonctionnel et efficace.

results matching ""

    No results matching ""