Dans les coulisses, une transaction réelle est très différente d’une transaction fournie par un explorateur de blocs typique. En fait, la plupart des constructions de haut niveau que nous voyons dans les différentes interfaces utilisateur des applications bitcoin n’existent pas réellement dans le système Bitcoin.

Nous pouvons utiliser l’interface de ligne de commande de Bitcoin Core (getrawtransaction et decoderawtransaction) pour récupérer la transaction "brute" d’Alice, la décoder et voir ce qu’elle contient. Le résultat ressemble à ceci :

Vous remarquerez peut-être certaines choses à propos de cette transaction, principalement les choses qui manquent ! Où est l’adresse d’Alice ? Où est l’adresse de Bob ? Où est l’entrée 0.1 "envoyée" par Alice ? En bitcoin, il n’y a pas de pièces, pas d’expéditeurs, pas de destinataires, pas de soldes, pas de comptes et pas d’adresses. Toutes ces choses sont construites à un niveau supérieur pour le bénéfice de l’utilisateur, pour rendre les choses plus faciles à comprendre.

Vous pouvez également remarquer de nombreux champs étranges et indéchiffrables et des chaînes hexadécimales. Ne vous inquiétez pas, nous expliquerons en détail chaque champ affiché ici dans ce chapitre.

Chaque transaction bitcoin crée des sorties, qui sont enregistrées sur le grand livre bitcoin. Presque toutes ces sorties, à une exception près (voir [op_return]) créent des morceaux de bitcoin utilisables appelés UTXO, qui sont ensuite reconnus par l’ensemble du réseau et disponibles pour que le propriétaire les dépense lors d’une future transaction.

Les UTXO sont suivis par chaque client Bitcoin à nœud complet dans l’ensemble UTXO. Les nouvelles transactions consomment (dépensent) une ou plusieurs de ces sorties de l’ensemble UTXO.

Les sorties de transaction se composent de deux parties :

Le puzzle cryptographique est également connu sous le nom de script de verrouillage, un script de témoin ou un scriptPubKey.

Le langage de script de transaction, utilisé dans le script de verrouillage mentionné précédemment, est décrit en détail dans Scripts de transaction et langage de script.

Maintenant, regardons la transaction d’Alice (montrée précédemment dans Transactions : Dans les coulisses) et voir si nous pouvons identifier les sorties. Dans l’encodage JSON, les sorties sont dans un tableau (liste) nommé vout :

Comme vous pouvez le voir, la transaction contient deux sorties. Chaque sortie est définie par une valeur et un puzzle cryptographique. Dans l’encodage indiqué par Bitcoin Core, la valeur est indiquée en bitcoin, mais dans la transaction elle-même, elle est enregistrée sous la forme d’un entier libellé en satoshis. La deuxième partie de chaque sortie est le puzzle cryptographique qui fixe les conditions de dépenses. Bitcoin Core le montre comme scriptPubKey et nous montre une représentation lisible par l’homme du script.

Le sujet du verrouillage et du déverrouillage de l’UTXO sera abordé plus tard, dans Construction du script (Verrouiller + Déverrouiller). Le langage de script utilisé pour le script dans scriptPubKey est décrit dans Scripts de transaction et langage de script. Mais avant d’approfondir ces sujets, nous devons comprendre la structure globale des entrées et sorties des transactions.

Les entrées de transaction identifient (par référence) quel UTXO sera consommé et fournissent une preuve de propriété via un script de déverrouillage.

Pour construire une transaction, un portefeuille sélectionne parmi l’UTXO qu’il contrôle, l’UTXO avec une valeur suffisante pour effectuer le paiement demandé. Parfois un UTXO suffit, d’autres fois plus d’un est nécessaire. Pour chaque UTXO qui sera consommé pour effectuer ce paiement, le portefeuille crée une entrée pointant vers l’UTXO et le déverrouille avec un script de déverrouillage.

Examinons plus en détail les composants d’une entrée. La première partie d’une entrée est un pointeur vers un UTXO par référence au hachage de transaction et à un index de sortie, qui identifie l’UTXO spécifique dans cette transaction. La deuxième partie est un script de déverrouillage, que le portefeuille construit afin de satisfaire aux conditions de dépenses définies dans l’UTXO. Le plus souvent, le script de déverrouillage est une signature numérique et une clé publique prouvant la propriété du bitcoin. Cependant, ce ne sont pas tous les scripts de déverrouillage qui contiennent une signature. La troisième partie est un numéro de séquence, qui sera discuté plus tard.

Considérez notre exemple dans Transactions : Dans les coulisses. Les entrées de transaction sont un tableau (liste) appelé vin :

Comme vous pouvez le voir, il n’y a qu’une seule entrée dans la liste (car un UTXO contenait une valeur suffisante pour effectuer ce paiement). L’entrée contient quatre éléments :

Dans la transaction d’Alice, l’entrée pointe vers l’ID de transaction :

et l’indice de sortie 0 (c’est-à-dire le premier UTXO créé par cette transaction). Le script de déverrouillage est construit par le portefeuille d’Alice en récupérant d’abord l’UTXO référencé, en examinant son script de verrouillage, puis en l’utilisant pour créer le script de déverrouillage nécessaire pour le satisfaire.

En regardant simplement l’entrée, vous avez peut-être remarqué que nous ne savons rien de cet UTXO, à part une référence à la transaction parent qui le contient. Nous ne connaissons pas sa valeur (montant en satoshi), et nous ne connaissons pas le script de verrouillage qui fixe les conditions pour le dépenser. Pour retrouver ces informations, il faut récupérer l’UTXO référencé en récupérant la transaction mère qui le contient. Notez que parce que la valeur de l’entrée n’est pas explicitement indiquée, nous devons également utiliser l’UTXO référencé afin de calculer les frais qui seront payés dans cette transaction (voir Frais de transaction).

Ce n’est pas seulement le portefeuille d’Alice qui doit récupérer l’UTXO référencé dans les entrées. Une fois cette transaction diffusée sur le réseau, chaque nœud de validation devra également récupérer l’UTXO référencé dans les entrées de transaction afin de valider la transaction.

Les transactions en elles-mêmes semblent incomplètes car elles manquent de contexte. Elles référencent l’UTXO dans leurs entrées mais sans récupérer cet UTXO on ne peut pas connaître la valeur des entrées ni leurs conditions de verrouillage. Lors de l’écriture d’un logiciel bitcoin, chaque fois que vous décodez une transaction dans le but de la valider ou de compter les frais ou de vérifier le script de déverrouillage, votre code devra d’abord récupérer l’UTXO référencé de la chaîne de blocs afin de construire le contexte implicite mais non présent dans les références UTXO des entrées. Par exemple, pour calculer le montant payé en frais, vous devez connaître la somme des valeurs des entrées et des sorties. Mais sans récupérer les UTXO référencés dans les entrées, vous ne connaissez pas leur valeur. Ainsi, une opération apparemment simple comme le comptage des frais dans une seule transaction implique en fait plusieurs étapes et des données provenant de plusieurs transactions.

Nous pouvons utiliser la même séquence de commandes avec Bitcoin Core que celle que nous avons utilisée lors de la récupération de la transaction d’Alice (getrawtransaction et decoderawtransaction). Avec cela, nous pouvons obtenir l’UTXO référencé dans l’entrée de la transaction d’Alice et jeter un œil :

On voit que cet UTXO a une valeur de 0.1 BTC et qu’il a un script de verrouillage (scriptPubKey) qui contient "OP_DUP OP_HASH160…​".

La plupart des transactions incluent des frais de transaction, qui rémunèrent les mineurs de bitcoins pour la sécurisation du réseau. Les frais servent également de mécanisme de sécurité eux-mêmes, en rendant économiquement impossible pour les attaquants d’inonder le réseau de transactions. L’exploitation minière et les frais et récompenses perçus par les mineurs sont discutés plus en détail dans [mining].

Cette section examine comment les frais de transaction sont inclus dans une transaction typique. La plupart des portefeuilles calculent et incluent automatiquement les frais de transaction. Toutefois, si vous créez des transactions par programmation ou à l’aide d’une interface de ligne de commande, vous devez comptabiliser et inclure manuellement ces frais.

Les frais de transaction servent d’incitation à inclure (exploiter) une transaction dans le bloc suivant et également de dissuasion contre les abus du système en imposant un petit coût sur chaque transaction. Les frais de transaction sont perçus par le mineur qui exploite le bloc qui enregistre la transaction sur la chaîne de blocs.

Les frais de transaction sont calculés en fonction de la taille de la transaction en kilo-octets, et non de la valeur de la transaction en bitcoin. Dans l’ensemble, les frais de transaction sont fixés en fonction des forces du marché au sein du réseau Bitcoin. Les mineurs hiérarchisent les transactions en fonction de nombreux critères différents, y compris les frais, et peuvent même traiter les transactions gratuitement dans certaines circonstances. Les frais de transaction affectent la priorité de traitement, ce qui signifie qu’une transaction avec des frais suffisants est susceptible d’être incluse dans le prochain bloc miné, alors qu’une transaction avec des frais insuffisants ou nuls peut être retardée, traitée au mieux après quelques blocs, ou pas traité du tout. Les frais de transaction ne sont pas obligatoires et les transactions sans frais peuvent éventuellement être traitées ; cependant, l’inclusion des frais de transaction encourage le traitement prioritaire.

Au fil du temps, la façon dont les frais de transaction sont calculés et leur effet sur la hiérarchisation des transactions ont évolué. Au départ, les frais de transaction étaient fixes et constants sur l’ensemble du réseau. Progressivement, la structure tarifaire s’est assouplie et peut être influencée par les forces du marché, en fonction de la capacité du réseau et du volume des transactions. Depuis au moins le début de 2016, les limites de capacité en bitcoin ont créé une concurrence entre les transactions, entraînant des frais plus élevés et faisant des transactions gratuites une chose du passé. Les transactions sans frais ou à très faibles frais sont rarement minées et parfois ne seront même pas propagées sur le réseau.

Dans Bitcoin Core, les politiques de relais des frais sont définies par l’option minrelaytxfee. Le minrelaytxfee par défaut actuel est de 0,00001 bitcoin ou un centième de millibitcoin par kilooctet. Par conséquent, par défaut, les transactions dont les frais sont inférieurs à 0,00001 bitcoin sont traitées comme gratuites et ne sont relayées que s’il y a de la place dans le mempool ; sinon, ils sont supprimés. Les nœuds Bitcoin peuvent remplacer la politique de relais de frais par défaut en ajustant la valeur de minrelaytxfee.

Tout service bitcoin qui crée des transactions, y compris les portefeuilles, les échanges, les applications de vente au détail, etc., doit implémenter des frais dynamiques. Les frais dynamiques peuvent être mis en œuvre via un service tiers d’estimation des frais ou avec un algorithme d’estimation des frais intégré. Si vous n’êtes pas sûr, commencez par un service tiers et, à mesure que vous acquérez de l’expérience, concevez et implémentez votre propre algorithme si vous souhaitez supprimer la dépendance tierce.

Les algorithmes d’estimation des frais calculent les frais appropriés, en fonction de la capacité et des frais offerts par les transactions « concurrentes ». Ces algorithmes vont du simple (frais moyens ou médians dans le dernier bloc) au sophistiqué (analyse statistique). Ils estiment les frais nécessaires (en satoshis par octet) qui donneront à une transaction une forte probabilité d’être sélectionnée et incluse dans un certain nombre de blocs. La plupart des services offrent aux utilisateurs la possibilité de choisir des frais de priorité élevés, moyens ou faibles. Une priorité élevée signifie que les utilisateurs paient des frais plus élevés, mais la transaction est susceptible d’être incluse dans le bloc suivant. Une priorité moyenne et faible signifie que les utilisateurs paient des frais de transaction moins élevés, mais que la confirmation des transactions peut prendre beaucoup plus de temps.

De nombreuses applications de portefeuille utilisent des services tiers pour le calcul des frais. Un service populaire est https://bitcoinfees.earn.com/, qui fournit une API et un graphique visuel montrant les frais en satoshi/octet pour différentes priorités.

Le graphique en Service d’estimation des frais bitcoinfees.earn.com affiche l’estimation en temps réel des frais par incréments de 10 satoshi/octet et le temps de confirmation attendu (en minutes et en nombre de blocs) pour les transactions avec des frais dans chaque plage. Pour chaque fourchette de frais (par exemple, 61 à 70 satoshi/octet), deux barres horizontales indiquent le nombre de transactions non confirmées (1 405) et le nombre total de transactions au cours des dernières 24 heures (102 975), avec des frais compris dans cette fourchette. Sur la base du graphique, les frais de haute priorité recommandés à ce moment étaient de 80 satoshi/octet, des frais susceptibles d’entraîner l’inclusion de la transaction dans le bloc suivant (délai de bloc nul). Pour la perspective, la taille médiane des transactions est de 226 octets, donc les frais recommandés pour cette taille de transaction seraient de 18 080 satoshis (0,00018080 BTC).

Les données d’estimation des frais peuvent être récupérées via une simple API HTTP REST, à l’adresse https://bitcoinfees.earn.com/api/v1/fees/recommended . Par exemple, sur la ligne de commande en utilisant la commande curl :

L’API renvoie un objet JSON avec l’estimation actuelle des frais pour la confirmation la plus rapide (fastestFee), la confirmation dans les trois blocs (halfHourFee) et six blocs (hourFee), en satoshi par octet.

La structure de données des transactions n’a pas de champ pour les frais. Au lieu de cela, les frais sont implicites comme la différence entre la somme des entrées et la somme des sorties. Tout montant excédentaire qui reste après que toutes les sorties ont été déduites de toutes les entrées est la redevance perçue par les mineurs :

Il s’agit d’un élément quelque peu déroutant des transactions et d’un point important à comprendre, car si vous construisez vos propres transactions, vous devez vous assurer de ne pas inclure par inadvertance des frais très importants en sous-dépensant les intrants. Cela signifie que vous devez comptabiliser toutes les entrées, si nécessaire en créant du change, ou vous finirez par donner un très gros pourboire aux mineurs !

Par exemple, si vous consommez un UTXO de 20 bitcoins pour effectuer un paiement de 1 bitcoin, vous devez inclure une sortie de modification de 19 bitcoins dans votre portefeuille. Sinon, le "reste" de 19 bitcoins sera compté comme des frais de transaction et sera collecté par le mineur qui exploite votre transaction dans un bloc. Bien que vous receviez un traitement prioritaire et rendiez un mineur très heureux, ce n’est probablement pas ce que vous vouliez.

Voyons comment cela fonctionne en pratique, en examinant à nouveau l’achat de café d’Alice. Alice veut dépenser 0,015 bitcoin pour payer son café. Pour s’assurer que cette transaction est traitée rapidement, elle voudra inclure des frais de transaction, disons 0,0005. Cela signifie que le coût total de la transaction sera de 0,0155. Son portefeuille doit donc se procurer un ensemble d’UTXO qui totalise 0,0155 bitcoin ou plus et, si nécessaire, créer de la monnaie. Disons que son portefeuille dispose d’un UTXO de 0,1 bitcoin. Elle devra donc consommer cet UTXO, créer une sortie pour le Bob’s Café pour 0,015, et une seconde sortie avec 0,0845 bitcoin en retour vers son propre portefeuille, laissant 0,0005 bitcoin non alloué, comme frais implicites pour la transaction.

Regardons maintenant un scénario différent. Eugenia, directrice de notre association caritative pour enfants aux Philippines, a organisé une collecte de fonds pour acheter des manuels scolaires pour les enfants. Elle a reçu plusieurs milliers de petits dons de personnes du monde entier, totalisant 50 bitcoins, donc son portefeuille est plein de très petits paiements (UTXO). Maintenant, elle veut acheter des centaines de manuels scolaires auprès d’un éditeur local, en payant en bitcoins.

Alors que l’application de portefeuille d’Eugenia tente de construire une seule transaction de paiement plus importante, elle doit s’approvisionner à partir de l’ensemble UTXO disponible, qui est composé de nombreux montants plus petits. Cela signifie que la transaction résultante proviendra de plus d’une centaine d’UTXO de petite valeur en tant qu’entrées et d’une seule sortie, payant l’éditeur du livre. Une transaction avec autant d’entrées sera supérieure à un kilo-octet, peut-être plusieurs kilo-octets. En conséquence, cela nécessitera des frais beaucoup plus élevés que la transaction de taille médiane.

L’application de portefeuille d’Eugenia calculera les frais appropriés en mesurant la taille de la transaction et en la multipliant par les frais par kilo-octet. De nombreux portefeuilles surpayeront les frais pour les transactions plus importantes afin de s’assurer que la transaction est traitée rapidement. Les frais plus élevés ne sont pas dus au fait qu’Eugenia dépense plus d’argent, mais au fait que sa transaction est plus complexe et plus volumineuse - les frais sont indépendants de la valeur en bitcoins de la transaction.

Une signature numérique est un schéma mathématique qui se compose de deux parties. La première partie est un algorithme de création d’une signature, à l’aide d’une clé privée (la clé de signature), à partir d’un message (la transaction). La deuxième partie est un algorithme qui permet à quiconque de vérifier la signature, étant donné également le message et une clé publique.

Pour vérifier la signature, il faut avoir la signature (R et S), la transaction sérialisée, et la clé publique (qui correspond à la clé privée utilisée pour créer la signature). Essentiellement, la vérification d’une signature signifie "Seul le propriétaire de la clé privée qui a généré cette clé publique pourrait avoir produit cette signature sur cette transaction."

L’algorithme de vérification de signature prend le message (un hachage de la transaction ou de parties de celui-ci), la clé publique du signataire et la signature (valeurs R et S), et renvoie TRUE si la signature est valide pour ce message et cette clé publique.

Les signatures numériques sont appliquées aux messages, qui dans le cas du bitcoin, sont les transactions elles-mêmes. La signature implique un engagement du signataire sur des données de transaction spécifiques. Dans sa forme la plus simple, la signature s’applique à l’ensemble de la transaction, engageant ainsi toutes les entrées, sorties et autres champs de transaction. Cependant, une signature ne peut s’engager que sur un sous-ensemble des données d’une transaction, ce qui est utile pour un certain nombre de scénarios, comme nous le verrons dans cette section.

Les signatures Bitcoin ont un moyen d’indiquer quelle partie des données d’une transaction est incluse dans le hachage signé par la clé privée à l’aide d’un drapeau SIGHASH. Le drapeau SIGHASH est un octet unique ajouté à la signature. Chaque signature a un drapeau SIGHASH et le drapeau peut être différent d’une entrée à l’autre. Une transaction avec trois entrées signées peut avoir trois signatures avec des drapeaux SIGHASH différents, chaque signature signant (committant) différentes parties de la transaction.

N’oubliez pas que chaque entrée peut contenir une signature dans son script de déverrouillage. Par conséquent, une transaction qui contient plusieurs entrées peut avoir des signatures avec différents indicateurs SIGHASH qui valident différentes parties de la transaction dans chacune des entrées. Notez également que les transactions bitcoin peuvent contenir des entrées de différents "propriétaires", qui ne peuvent signer qu’une seule entrée dans une transaction partiellement construite (et invalide), collaborant avec d’autres pour rassembler toutes les signatures nécessaires pour effectuer une transaction valide. De nombreux types d’indicateurs SIGHASH n’ont de sens que si vous pensez à plusieurs participants collaborant en dehors du réseau Bitcoin et mettant à jour une transaction partiellement signée.

De plus, il existe un drapeau modificateur SIGHASH_ANYONECANPAY, qui peut être combiné avec chacun des drapeaux précédents. Lorsque ANYONECANPAY est défini, une seule entrée est signée, laissant le reste (et leurs numéros de séquence) ouverts pour modification. Le ANYONECANPAY a la valeur 0x80 et est appliqué par OR au niveau du bit, ce qui donne les drapeaux combinés comme indiqué dans Types SIGHASH avec modificateurs et leurs significations.

Ces combinaisons de drapeaux sont résumées dans Résumé des différentes combinaisons de sighash.

La façon dont les drapeaux SIGHASH sont appliqués lors de la signature et de la vérification est qu’une copie de la transaction est faite et que certains champs à l’intérieur sont tronqués (mis à zéro et vidés). La transaction résultante est sérialisée. Le drapeau SIGHASH est ajouté à la fin de la transaction sérialisée et le résultat est haché. Le hachage lui-même est le "message" qui est signé. Selon l’indicateur SIGHASH utilisé, différentes parties de la transaction sont tronquées. Le hachage résultant dépend de différents sous-ensembles de données dans la transaction. En incluant le SIGHASH comme dernière étape avant le hachage, la signature valide également le type SIGHASH, de sorte qu’il ne peut pas être modifié (par exemple, par un mineur).

Dans l’exemple de la transaction d’Alice (voir la liste dans Sérialisation des signatures (DER)), nous avons vu que la dernière partie de la signature codée en DER était 01, qui est le drapeau SIGHASH_ALL. Cela verrouille les données de transaction, de sorte que la signature d’Alice valide l’état de toutes les entrées et sorties. C’est la forme de signature la plus courante.

Examinons quelques-uns des autres types de SIGHASH et comment ils peuvent être utilisés dans la pratique :

Il y a quelques propositions pour modifier ou étendre le système SIGHASH. L’une de ces propositions est Bitmask Sighash Modes de Glenn Willen de Blockstream, dans le cadre du projet Elements. Cela vise à créer un remplacement flexible pour les types SIGHASH qui permet "des masques de bits arbitraires et réinscriptibles par des mineurs d’entrées et de sorties" qui peuvent exprimer "des schémas de pré-engagement contractuels plus complexes, tels que des offres signées avec changement dans un échange d’actifs distribué".

Comme mentionné précédemment, les signatures sont créées par une fonction mathématique F_sig qui produit une signature composée de deux valeurs R et S. Dans cette section, nous examinons la fonction F_sig plus en détail.

L’algorithme de signature génère d’abord une paire de clés publiques privées éphémères (temporaires). Cette paire de clés temporaire est utilisée dans le calcul des valeurs R et S, après une transformation impliquant la clé privée de signature et le hachage de la transaction.

La paire de clés temporaire est basée sur un nombre aléatoire k, qui est utilisé comme clé privée temporaire. À partir de k, nous générons la clé publique temporaire correspondante P (calculée comme P = k*G, de la même manière que les clés publiques bitcoin sont dérivées ; voir [pubkey]). La valeur R de la signature numérique est alors la coordonnée x de la clé publique éphémère P.

A partir de là, l’algorithme calcule la valeur S de la signature, telle que :

S = k^-1 (Hash(m) + dA * R) mod n

où:

La vérification est l’inverse de la fonction de génération de signature, utilisant les valeurs R, S et la clé publique pour calculer une valeur P, qui est un point sur la courbe elliptique (la clé publique éphémère utilisée dans la création de signature) :

P = S^-1 * Hash(m) * G + S^-1 * R * Qa

où:

Si la coordonnée x du point calculé P est égale à R, alors le vérificateur peut conclure que la signature est valide.

Notez qu’en vérifiant la signature, la clé privée n’est ni connue ni révélée.

Comme nous l’avons vu dans Mathématiques ECDSA, l’algorithme de génération de signature utilise une clé aléatoire k, comme base d’un couple clé privée/publique éphémère. La valeur de k n’est pas importante, tant qu’elle est aléatoire. Si la même valeur k est utilisée pour produire deux signatures sur différents messages (transactions), alors la signature clé privée peut être calculée par n’importe qui. La réutilisation de la même valeur pour k dans un algorithme de signature conduit à l’exposition de la clé privée !

Ce n’est pas seulement une possibilité théorique. Nous avons vu ce problème conduire à l’exposition de clés privées dans quelques implémentations différentes d’algorithmes de signature de transaction en bitcoin. Des personnes se sont fait voler des fonds en raison de la réutilisation par inadvertance d’une valeur k. La raison la plus courante de réutilisation d’une valeur k est un générateur de nombres aléatoires mal initialisé.

Pour éviter cette vulnérabilité, la meilleure pratique de l’industrie est de ne pas générer k avec un générateur de nombres aléatoires semé d’entropie, mais plutôt d’utiliser un processus déterministe-aléatoire semé avec les données de transaction elles-mêmes. Cela garantit que chaque transaction produit un k différent. L’algorithme standard de l’industrie pour l’initialisation déterministe de k est défini dans RFC 6979, publié par l’Internet Engineering Task Force.

Si vous implémentez un algorithme pour signer des transactions en bitcoin, vous devez utiliser la RFC 6979 ou un algorithme déterministe-aléatoire similaire pour vous assurer de générer un k différent pour chaque transaction.