Les transactions bitcoin

Chaque transaction bitcoin permettent d'échanger des bitcoins (BTC) entre deux utilisateurs. Tous les bitcoins en circulation depuis la création de la monnai sont exclusivement décrits par les transactions qui les font circuler entre les leurs différents propriétaires successifs.

Le principe de bitcoin est d'annoncer publiquement l'ensemble des transactions effectuées entre les différents participants, de les valider, puis de les intégrer par blocs dans un journal public de transactions. L'intégration des blocs de transactions dans le journal fait l'objet d'un autre article. Nous nous focalisons ici sur la création d'une transaction d'échange. N'importe quel pair du réseau peut suivre la circulation de bitcoins entre noeuds en suivant les transactions concernées. La circulation est annoncée publiquement dans le journal mais l'identité des sources et des destinations reste inconnue.

Pour réaliser un transfert de BTC d'une adresse @B vers une adresse @C. B doit s'occuper de préparer une transaction décrivant le transfert. La transaction est préparée en 4 étapes.

  • Etape 1 : afin de pouvoir transférer des bitcoins vers C, B doit posséder les fonds suffisants, il faut donc que l'adresse de B soit présente dans des transactions précédentes qui fourniront les bitcoins d'entrées. Toutes les transactions validées sont identifiées par une valeur de hash qui représente de manière unique sa description interne.

La transaction référencée Tx0x52 possède dans sa description de sortie l'identification de l'adresse de B. On voit également que cette transaction, transfère 50 BTC vers @B (exprimé en satoshi 1 BTC:100 000 000 satoshi). Elle peut être utilisée comme transaction d'entrée pour une transaction fabriquée par B.

  • Etape 2 : B prépare une transaction, qui indique dans la section txIn les sources d'entrée de BTC et dans la section txOut les montants et les adresses destinataires des bitcoins. Tout ce qui rentre dans une transaction (Somme des valeurs des transactions d'entrées), doit sortir (Somme des valeurs des transactions de sortie). Si la transaction envisagée ne couvre pas toutes les sommes, on peut, soit ajouter l'adresse de B comme destinataire du reliquat, soit accepter que les pairs qui valideront la transaction récupérent ce reliquat, ou n'importe quelle combinaison de ces deux facteurs. La figure suivante illustre un transfert multiple (indépendant de notre exemple entre B et C).

La transaction Z extrait 0.008 BTC et produit deux sorties à 0.003 BTC et 0.004 BTC pour un reliquat de 0.001 BTC qui sera fourni au mineur qui aura validé cette transaction.

En reprenant l'exemple précédent, la transaction considérée transfère l'intégralité des BTC de sa transaction précédente de A vers B vers une transaction initiée par B.

  • Etape 3 : comme la transaction est définie par B, celui-ci doit prouver qu'il en est l'auteur. La preuve est fournie par une signature unique qui permet également de vérifier que la description publique n'a pas été modifiée. Pour signer la transaction, on utilise un principe 'classique' de cryptage asymétrique. B signe le document avec sa clé privé que personne ne connait, mais il diffuse sa clé publique qui peut être utilisée pour vérifier la conformité de la signature. La figure suivante ajoute à la description de la transaction la signature et la clé publique de B.

La ligne en gras stocke deux valeurs numériques : la signature de la transaction signée avec la clé privée de B, et la clé publique de B.

  • Etape 4 : la dernière étape consiste à chainer la nouvelle transaction avec la précédente. Le chaînage est vérifiable par n'importe quel participant, il consiste principalement à exécuter un script de validation. Le script est apporté d'une part, par les scripts de sortie des transactions précédentes et par le script d'entrée de la transaction à valider. Pour la partie sortante (txOut), il permet de vérifier que certaines conditions sont réunies pour que l'utilisateur puisse toucher les fonds, pour la partie entrante (txIn), il permet de vérifier que l'adresse ciblée (dans txOut) correspond bien à la clé publique indiquée (dans txIn). Cette vérification est nécessaire car avant d'utiliser des fonds l'utilisateur B n'est connu que par son adresse (@B) qui est un hash de sa clé publique. Le script vérifie donc la correspondance entre le hash et la clé publique présentée. Pour préservé l'anonymat des transferts, on recommande de changer de paire hash/clé publique à chaque transaction. L'exemple précis du script est indiqué dans la figure suivante.

Pour vérifier l'exactitude de la transaction à droite de la figure, un noeud va réaliser les opérations suivantes.
1. Récupérer le script txIn de la transaction à vérifier
2. Récupérer le script txOut de la transaction référencée (ici tx0x52) et le concaténer au script précédent.
3. Exécuter le script.
4. Si l'exécution retourne vrai, la transaction est valide.

Dans notre exemple, le script suivant est fabriqué.

   /*Partie droite (txIn)*/
1. <sig(privB)> // Empile la signature de la Tx  
2. <pubB>       // Empile la clé publique de B  
   /*Partie gauche (txOut)*/
3. dup          // Duplique le haut de la pile  
4. hash160      // Remplace par un hash le sommet de la pile  
5. <@B>         // Empile @B  
6. equalverify  // Compare les deux valeurs du sommet de pile  
8. checksig     // Vérifie la signature  

Dans le cas où le script termine sur 'true' voici l'évolution de la pile pendant l'interprétation.

Dans notre exemple d'une transaction simple, le script vérifie deux choses :
1. Que l'adresse destinatrice indiquée dans la sortie précédente soit bien celle correspondante à la clé publique indiquée dans la transaction. Donc, que B est bien celui qui dit être.
2. Que la signature fournie avec cette clé publique valide la signature réalisée avec la clé privée correspondante.

Le script est fondamental car le langage est suffisamment puissant pour exprimer de nombreuses conditions d'accès aux fonds de la transaction entrante. Dans notre exemple, seule l'identité de la destination est vérifiée. Mais certains scripts peuvent valider n'importe quelle identification (don général), bloquer les fonds par une clé tierce, interdire la transaction au bout d'un certain délai ...

Le script est validé par des participants avant d'intégrer la transaction dans un bloc du cahier publique des transactions (les mineurs sont décrits dans l'article suivant). Le chaînage des transactions peut se représenter selon la figure suivante.

On constate qu'une transaction ne peut être valide que si elle référence une transaction précédente, et que pour valider une transaction, il faut valider l'identité publique du créateur et la disponibilité des fonds provenant des transactions de la gauche de la figure.

Refs

Raw Bitcoin

Video Rapide

Wikipedia

comments powered by Disqus