Maîtriser Bitcoin

Je suis tombé sur bitcoin pour la première fois à la mi-2011. Ma réaction immédiate a été plus ou moins "Pfft ! Nerd money !" et je l’ai ignoré pendant encore six mois, n’en saisissant pas l’importance. C’est une réaction que j’ai vue se répéter chez bon nombre des personnes les plus intelligentes que je connaisse, ce qui me réconforte un peu. La deuxième fois que je suis tombé sur bitcoin, lors d’une discussion sur une liste de diffusion, j’ai décidé de lire le livre blanc écrit par Satoshi Nakamoto pour étudier la source faisant autorité et voir de quoi il s’agissait. Je me souviens encore du moment où j’ai fini de lire ces neuf pages, quand j’ai réalisé que le bitcoin n’était pas simplement une monnaie numérique, mais un réseau de confiance qui pouvait aussi fournir la base de bien plus que de simples devises. La prise de conscience que "ce n’est pas de l’argent, c’est un réseau de confiance décentralisé", m’a lancé dans un voyage de quatre mois pour dévorer toutes les informations sur le bitcoin que j’ai pu trouver. Je suis devenu obsédé et captivé, passant 12 heures ou plus par jour collé à un écran, lisant, écrivant, codant et apprenant autant que possible. Je suis sorti de cet état de fugue, plus de 20 livres en moins à cause du manque de repas réguliers, déterminé à me consacrer au travail sur le bitcoin.

Deux ans plus tard, après avoir créé un certain nombre de petites start-ups pour explorer divers services et produits liés au bitcoin, j’ai décidé qu’il était temps d’écrire mon premier livre. Bitcoin était le sujet qui m’avait poussé dans une frénésie de créativité et consommé mes pensées; c’était la technologie la plus excitante que j’avais rencontrée depuis Internet. Il était maintenant temps de partager ma passion pour cette technologie incroyable avec un public plus large.

Ce livre est principalement destiné aux codeurs. Si vous pouvez utiliser un langage de programmation, ce livre vous apprendra comment fonctionnent les monnaies cryptographiques, comment les utiliser et comment développer des logiciels qui fonctionnent avec elles. Les premiers chapitres conviennent également comme une introduction approfondie au bitcoin pour les non-codeurs, tel ceux qui veulent comprendre le fonctionnement interne du bitcoin et des crypto-monnaies.

Les conventions typographiques suivantes sont utilisées dans ce livre :

Les exemples sont illustrés en Python, C++, et en utilisant la ligne de commande d’un système d’exploitation de type Unix tel que Linux ou macOS. Tous les extraits de code sont disponibles dans le référentiel GitHub (https://github.com/bitcoinbook/bitcoinbook) dans le sous-répertoire code du référentiel principal. Fourchez le code du livre, essayez les exemples de code ou soumettez des corrections via GitHub.

Tous les extraits de code peuvent être répliqués sur la plupart des systèmes d’exploitation avec une installation minimale de compilateurs et d’interpréteurs pour les langages correspondants. Si nécessaire, nous fournissons des instructions d’installation de base et des exemples étape par étape de la sortie de ces instructions.

Certains des extraits de code et des sorties de code ont été reformatés pour l’impression. Dans tous ces cas, les lignes ont été séparées par un caractère barre oblique inverse (\), suivi d’un caractère de saut de ligne. Lors de la transcription des exemples, supprimez ces deux caractères et rejoignez les lignes à nouveau et vous devriez voir des résultats identiques comme indiqué dans l’exemple.

Tous les extraits de code utilisent des valeurs réelles et des calculs dans la mesure du possible, afin que vous puissiez construire d’exemple en exemple et voir les mêmes résultats dans n’importe quel code que vous écrivez pour calculer les mêmes valeurs. Par exemple, les clés privées et les clés et adresses publiques correspondantes sont toutes réelles. Les exemples de transactions, de blocs et de références de chaîne de blocs ont tous été introduits dans la chaîne de blocs bitcoin réelle et font partie du grand livre public, vous pouvez donc les consulter sur n’importe quel système bitcoin.

Les adresses bitcoin, les transactions, les clés, les codes QR et les données de chaîne de blocs utilisées dans ce livre sont, pour la plupart, réelles. Cela signifie que vous pouvez parcourir la chaîne de blocs, regarder les transactions proposées en exemple, les récupérer avec vos propres scripts ou programmes, etc.

Cependant, notez que les clés privées utilisées pour construire les adresses sont soit imprimées dans ce livre, soit ont été "radiées". Cela signifie que si vous envoyez de l’argent à l’une de ces adresses, l’argent sera perdu pour toujours ou, dans certains cas, tous ceux qui peuvent lire ce livre peuvent le prendre en utilisant les clés privées imprimées dans celui-ci.

Ce livre est dérivé sous licence du livre "Mastering Bitcoin 2nd Edition", par O’Reilly Media.

Copyright (c) 2014 Andreas M. Antonopoulos LLC

Ce travail est sous licence Creative Commons Attribution-ShareAlike 4.0 International License. Pour voir une copie de cette licence, visitez

http://creativecommons.org/licenses/by-sa/4.0/.

Pour fournir une attribution, veuillez créer un lien vers le référentiel du livre :

https://github.com/bitcoinbook/bitcoinbook

et inclure cette licence ou une licence ouverte équivalente, pour satisfaire aux exigences ShareAlike.

Cette licence conforme à la "Culture libre" a été approuvée par mon éditeur O’Reilly Media (http://oreilly.com), qui comprend la valeur du mouvement de source ouverte. O’Reilly Media n’est pas seulement le meilleur éditeur de livres techniques au monde, mais aussi un fervent partisan d’une culture ouverte et du partage des connaissances.

Merci O’Reilly !

Ce livre représente les efforts et les contributions de nombreuses personnes. Je suis reconnaissant pour toute l’aide que j’ai reçue d’amis, de collègues et même de parfaits inconnus, qui m’ont rejoint dans cet effort pour écrire le livre technique définitif sur les crypto-monnaies et le bitcoin.

Il est impossible de faire une distinction entre la technologie bitcoin et la communauté bitcoin, et ce livre est autant un produit de cette communauté qu’un livre sur la technologie. Mon travail sur ce livre a été encouragé, applaudi, soutenu et récompensé par toute la communauté bitcoin du tout début jusqu’à la toute fin. Plus que tout, ce livre m’a permis de faire partie d’une merveilleuse communauté pendant deux ans et je ne vous remercierai jamais assez de m’avoir accepté dans cette communauté. Il y a beaucoup trop de personnes à mentionner par leur nom - des personnes que j’ai rencontrées lors de conférences, d’événements, de séminaires, de rencontres, de pizzas et de petits rassemblements privés, ainsi que beaucoup qui ont communiqué avec moi par Twitter, sur reddit, sur bitcointalk. org, et sur GitHub qui ont eu un impact sur ce livre. Chaque idée, analogie, question, réponse et explication que vous trouverez dans ce livre a été à un moment donné inspirée, testée ou améliorée grâce à mes interactions avec la communauté. Merci à tous pour votre soutien; sans vous ce livre n’aurait pas vu le jour. Je suis éternellement reconnaissant.

Le voyage pour devenir auteur commence bien avant le premier livre, bien sûr. Ma première langue (et ma scolarité) était le grec, j’ai donc dû suivre un cours de rattrapage en anglais écrit lors de ma première année d’université. Je dois remercier Diana Kordas, mon professeur d’écriture d’anglais, qui m’a aidé à développer ma confiance et mes compétences cette année-là. Plus tard, en tant que professionnel, j’ai développé mes compétences en rédaction technique sur le thème des centres de données, en écrivant pour le magazine Network World. Je dois remercier John Dix et John Gallant, qui m’ont donné mon premier travail d’écriture en tant que chroniqueur à Network World et à mon éditeur Michael Cooney et mon collègue Johna Till Johnson qui ont édité mes chroniques et les ont rendues aptes à la publication. Écrire 500 mots par semaine pendant quatre ans m’a donné suffisamment d’expérience pour éventuellement envisager de devenir auteur.

Merci également à ceux qui m’ont soutenu lorsque j’ai soumis ma proposition de livre à O’Reilly, en fournissant des références et en examinant la proposition. Plus précisément, merci à John Gallant, Gregory Ness, Richard Stiennon, Joel Snyder, Adam B. Levine, Sandra Gittlen, John Dix, Johna Till Johnson, Roger Ver et Jon Matonis. Remerciements particuliers à Richard Kagan et Tymon Mattoszko, qui ont révisé les premières versions de la proposition et à Matthew Taylor, qui a révisé la proposition.

Merci à Cricket Liu, auteur du titre O’Reilly DNS et BIND, qui m’a présenté O’Reilly. Merci également à Michael Loukides et Allyson MacDonald de O’Reilly, qui ont travaillé pendant des mois pour aider à la réalisation de ce livre. Allyson a été particulièrement patiente lorsque les délais ont été manqués et les livrables retardés alors que la vie intervenait dans notre échéancier. Pour la deuxième édition, je remercie Timothy McGovern d’avoir guidé le processus, Kim Cofer d’avoir patiemment édité et Rebecca Panzer d’avoir illustré de nombreux nouveaux diagrammes.

Les premières ébauches des premiers chapitres ont été les plus difficiles, car le bitcoin est un sujet difficile à démêler. Chaque fois que je tirais sur un fil de la technologie bitcoin, je devais tirer sur le tout. Je me suis retrouvé coincé à plusieurs reprises et un peu découragé alors que je luttais pour rendre le sujet facile à comprendre et créer un récit autour d’un sujet technique aussi dense. Finalement, j’ai décidé de raconter l’histoire du bitcoin à travers les histoires des personnes utilisant le bitcoin et tout le livre est devenu beaucoup plus facile à écrire. Je dois remercier mon ami et mentor, Richard Kagan, qui m’a aidé à démêler l’histoire et à surmonter les moments de blocage de l’écrivain. Je remercie Pamela Morgan, qui a révisé les premières ébauches de chaque chapitre de la première et de la deuxième édition du livre, et a posé les questions difficiles pour les améliorer. Merci également aux développeurs du groupe San Francisco Bitcoin Developers Meetup ainsi qu’à Taariq Lewis et Denise Terry pour avoir aidé à tester le premier matériel. Merci également à Andrew Naugler pour la conception infographique.

Pendant le développement du livre, j’ai rendu les premières ébauches disponibles sur GitHub et j’ai invité les commentaires du public. Plus d’une centaine de commentaires, suggestions, corrections et contributions ont été soumis en réponse. Ces contributions sont explicitement reconnues, avec mes remerciements, dans Version préliminaire (contributions GitHub). Surtout, mes sincères remerciements à mes éditeurs bénévoles de GitHub, Ming T. Nguyen (1ère édition) et Will Binns (2e édition), qui ont travaillé sans relâche pour organiser, gérer et résoudre les demandes d’extraction, publier des rapports et effectuer des corrections de bogues sur GitHub.

Une fois le livre rédigé, il est passé par plusieurs séries d’examens techniques. Merci à Cricket Liu et Lorne Lantz pour leur examen approfondi, leurs commentaires et leur soutien.

Plusieurs développeurs de bitcoins ont fourni des échantillons de code, des critiques, des commentaires et des encouragements. Merci à Amir Taaki et Eric Voskuil pour les extraits de code par exemple et de nombreux excellents commentaires ; Chris Kleeschulte pour sa contribution à l’annexe Bitcore ; Vitalik Buterin et Richard Kiss pour leur aide avec les mathématiques des courbes elliptiques et leurs contributions au code ; Gavin Andresen pour les corrections, les commentaires et les encouragements ; Michalis Kargakis pour les commentaires, les contributions et la rédaction de btcd ; et Robin Inge pour les soumissions d’errata améliorant la deuxième impression. Dans la deuxième édition, j’ai de nouveau reçu beaucoup d’aide de la part de nombreux développeurs de Bitcoin Core, dont Eric Lombrozo qui a démystifié le Témoin Séparé, Luke Dashjr qui a aidé à améliorer le chapitre sur les transactions, Johnson Lau qui a revu le Témoin Séparé et d’autres chapitres, et bien d’autres. Je dois remercier Joseph Poon, Tadge Dryja et Olaoluwa Osuntokun qui ont expliqué le Lightning Network, revu mes écrits et répondu aux questions lorsque je suis resté bloqué.

Je dois mon amour des mots et des livres à ma mère, Theresa, qui m’a élevé dans une maison avec des livres tapissant tous les murs. Ma mère m’a également acheté mon premier ordinateur en 1982, bien qu’elle se décrive comme une technophobe. Mon père, Menelaos, un ingénieur civil qui vient de publier son premier livre à 80 ans, est celui qui m’a enseigné la pensée logique et analytique et l’amour de la science et de l’ingénierie.

Merci à tous de m’avoir soutenu tout au long de ce parcours.

Le système Bitcoin, contrairement aux systèmes bancaires et de paiement traditionnels, est basé sur la confiance décentralisée. Au lieu d’une autorité centrale de confiance, dans le bitcoin, la confiance est obtenue en tant que propriété émergente à partir des interactions des différents participants au système Bitcoin. Dans ce chapitre, nous examinerons le bitcoin d’un niveau élevé en suivant une seule transaction via le système Bitcoin et en observant qu’elle devient "de confiance" et acceptée par le mécanisme de consensus distribué bitcoin et est finalement enregistrée sur la chaîne de blocs, le grand livre distribué de toutes transactions. Les chapitres suivants approfondiront la technologie derrière les transactions, le réseau et l’exploitation minière.

En termes simples, une transaction indique au réseau que le propriétaire d’une valeur bitcoin a autorisé le transfert de cette valeur à un autre propriétaire. Le nouveau propriétaire peut désormais dépenser le bitcoin en créant une autre transaction qui autorise le transfert à un autre propriétaire, et ainsi de suite, dans une chaîne de propriété.

L’application de portefeuille d’Alice contient toute la logique pour sélectionner les entrées et les sorties appropriées pour construire une transaction à la spécification d’Alice. Alice n’a qu’à spécifier une destination et un montant, et le reste se passe dans l’application portefeuille sans qu’elle ne voie les détails. Il est important de noter qu’une application de portefeuille peut créer des transactions même si elle est complètement hors ligne. Comme écrire un chèque à la maison et l’envoyer plus tard à la banque dans une enveloppe, la transaction n’a pas besoin d’être construite et signée tout en étant connectée au réseau Bitcoin.

La transaction d’Alice est maintenant propagé sur le réseau Bitcoin. Il ne fait pas partie de la chaîne de blocs tant qu’il n’est pas vérifié et inclus dans un bloc par un processus appelé minage. Voir Minage et Consensus pour une explication détaillée.

Le système de confiance Bitcoin est basé sur le calcul. Les transactions sont regroupées en blocs, qui nécessitent une énorme quantité de calculs pour prouver, mais seulement une petite quantité de calculs pour vérifier comme prouvé. Le processus de minage sert à deux fins dans le bitcoin :

L’exploitation minière atteint un bon équilibre entre le coût et la récompense. L’exploitation minière utilise l’électricité pour résoudre un problème mathématique. Un mineur qui réussit recevra une récompense sous la forme de nouveaux bitcoins et de frais de transaction. Cependant, la récompense ne sera perçue que si le mineur a correctement validé toutes les transactions, à la satisfaction des règles de consensus. Cet équilibre délicat assure la sécurité du bitcoin sans autorité centrale.

Une bonne façon de décrire l’exploitation minière est comme un jeu compétitif géant de sudoku qui se réinitialise chaque fois que quelqu’un trouve une solution et dont la difficulté s’ajuste automatiquement de sorte qu’il faut environ 10 minutes pour trouver une solution. Imaginez un puzzle sudoku géant, de plusieurs milliers de lignes et de colonnes. Si je vous montre un puzzle terminé, vous pouvez le vérifier assez rapidement. Cependant, si le puzzle a quelques cases remplies et que les autres sont vides, cela demande beaucoup de travail à résoudre ! La difficulté du sudoku peut être ajustée en modifiant sa taille (plus ou moins de lignes et de colonnes), mais elle peut toujours être vérifiée assez facilement même si elle est très grande. Le "casse-tête" utilisé dans le bitcoin est basé sur un hachage cryptographique et présente des caractéristiques similaires : il est asymétriquement difficile à résoudre mais facile à vérifier, et sa difficulté peut être ajustée.

In Utilisations, utilisateurs et histoires de Bitcoin, nous avons présenté Jing est un entrepreneur à Shanghai. Jing dirige une ferme minière, qui est une entreprise qui gère des milliers d’ordinateurs miniers spécialisés, en compétition pour la récompense. Toutes les 10 minutes environ, les ordinateurs miniers de Jing rivalisent avec des milliers de systèmes similaires dans une course mondiale pour trouver une solution à un bloc de transactions. Trouver une telle solution, la soi-disant Proof-of-Work (ou Preuve de travail) (PoW), nécessite des quadrillions d’opérations de hachage par seconde sur l’ensemble du réseau Bitcoin. L’algorithme de preuve de travail implique de hacher à plusieurs reprises l’en-tête du bloc et un nombre aléatoire avec l’algorithme cryptographique SHA256 jusqu’à ce qu’une solution correspondant à un modèle prédéterminé émerge. Le premier mineur à trouver une telle solution remporte la compétition et publie ce bloc dans la chaîne de blocs.

Jing a commencé l’exploitation minière en 2010 en utilisant un ordinateur de bureau très rapide pour trouver une preuve de travail appropriée pour les nouveaux blocs. Au fur et à mesure que de plus en plus de mineurs rejoignaient le réseau Bitcoin, la difficulté du problème augmentait rapidement. Bientôt, Jing et d’autres mineurs sont passés à du matériel plus spécialisé, avec des unités de traitement graphique (GPU) dédiées de haute de gamme, souvent utilisées dans les ordinateurs de bureau ou les consoles de jeu. Au moment d’écrire ces lignes, la difficulté est si élevée qu’il n’est rentable de miner qu’avec des circuits intégrés à application spécifique (ASIC), essentiellement des centaines d’algorithmes de minage imprimé en matériel, fonctionnant en parallèle sur une seule puce de silicium. La société de Jing participe également à un groupe ou bassin de mineurs, qui, tout comme un groupe de loterie, permet à plusieurs participants de partager leurs efforts et leurs récompenses. La société de Jing gère désormais un entrepôt contenant des milliers de mineurs ASIC pour extraire du bitcoin 24 heures sur 24. L’entreprise paie ses frais d’électricité en vendant le bitcoin qu’elle est capable de générer à partir de l’exploitation minière, créant ainsi des revenus à partir des bénéfices.

De nouvelles transactions affluent constamment sur le réseau à partir des portefeuilles des utilisateurs et d’autres applications. Comme ceux-ci sont vus par les nœuds du réseau Bitcoin, ils sont ajoutés à un bassin temporaire de transactions non vérifiées maintenues par chaque nœud. Lorsque les mineurs construisent un nouveau bloc, ils ajoutent des transactions non vérifiées de ce bassin au nouveau bloc, puis tentent de prouver la validité de ce nouveau bloc, avec l’algorithme de minage (la preuve de travail). Le processus d’extraction est expliqué en détail dans Minage et Consensus.

Les transactions sont ajoutées au nouveau bloc, classées par ordre de priorité par les transactions les plus payantes en premier et quelques autres critères. Chaque mineur commence le processus d’extraction d’un nouveau bloc de transactions dès qu’il reçoit le bloc précédent du réseau, sachant qu’il a perdu le tour de compétition précédent. Ils créent immédiatement un nouveau bloc, le remplissent avec les transactions et l’empreinte numérique du bloc précédent, et commencent à calculer la preuve de travail pour le nouveau bloc. Chaque mineur inclut une transaction spéciale dans son bloc, une transaction qui paie à sa propre adresse Bitcoin la récompense du bloc (actuellement 6,25 bitcoins nouvellement créés) plus la somme des frais de transaction de toutes les transactions incluses dans le bloc. S’ils trouvent une solution qui rend ce bloc valide, ils "gagnent" cette récompense car leur bloc réussi est ajouté à la chaîne de blocs mondiale et la transaction de récompense qu’ils ont incluse devient dépensable. Jing, qui participe à un groupe de minage, a mis en place son logiciel pour créer de nouveaux blocs qui attribuent la récompense à une adresse de pool. À partir de là, une part de la récompense est distribuée à Jing et aux autres mineurs proportionnellement à la quantité de travail qu’ils ont apportée lors du dernier tour.

La transaction d’Alice a été récupérée par le réseau et incluse dans le groupe de transactions non vérifiées. Une fois validé par le logiciel de minage, il a été inclus dans un nouveau bloc, appelé bloc candidat, généré par le pool de minage de Jing. Tous les mineurs participant à ce pool de minage commencent immédiatement à calculer la preuve de travail pour le bloc candidat. Environ cinq minutes après la première transmission de la transaction par le portefeuille d’Alice, l’un des mineurs ASIC de Jing a trouvé une solution pour le bloc candidat et l’a annoncée au réseau. Une fois que les autres mineurs ont validé le bloc gagnant, ils ont commencé la course pour générer le bloc suivant.

Le bloc gagnant de Jing est devenu une partie de la chaîne de blocs en tant que bloc # 277316, contenant 419 transactions, y compris la transaction d’Alice. Le bloc contenant la transaction d’Alice est compté comme une "confirmation" de cette transaction.

Environ 20 minutes plus tard, un nouveau bloc, #277317, est miné par un autre mineur. Parce que ce nouveau bloc est construit au-dessus du bloc #277316 qui contenait la transaction d’Alice, il a ajouté encore plus de calculs à la chaîne de blocs, renforçant ainsi la confiance dans ces transactions. Chaque bloc miné en plus de celui contenant la transaction compte comme une confirmation supplémentaire pour la transaction d’Alice. Au fur et à mesure que les blocs s’empilent les uns sur les autres, il devient exponentiellement plus difficile d’inverser la transaction, ce qui la rend de plus en plus fiable par le réseau.

Dans le diagramme en Transaction d’Alice incluse dans le bloc #277316, nous pouvons voir le bloc #277316, qui contient la transaction d’Alice. En dessous se trouvent 277 316 blocs (y compris le bloc #0), liés les uns aux autres dans une chaîne de blocs jusqu’au bloc #0, connu sous le nom de bloc d’origine. Au fil du temps, à mesure que la "hauteur" des blocs augmente, la difficulté de calcul de chaque bloc et de la chaîne dans son ensemble augmente également. Les blocs extraits après celui qui contient la transaction d’Alice agissent comme une assurance supplémentaire, car ils accumulent plus de calculs dans une chaîne de plus en plus longue. Par convention, tout bloc avec plus de six confirmations est considéré comme irrévocable, car il faudrait une immense quantité de calculs pour invalider et recalculer six blocs. Nous examinerons plus en détail le processus d’exploitation minière et la manière dont il renforce la confiance dans Minage et Consensus.

Maintenant que la transaction d’Alice a été intégrée à la chaîne de blocs dans le cadre d’un bloc, il fait partie du grand livre distribué de Bitcoin et est visible par toutes les applications Bitcoin. Chaque client Bitcoin peut indépendamment vérifier que la transaction est valide et utilisable. Les clients du nœud complet peuvent suivre la source des fonds à partir du moment où les bitcoins ont été générés pour la première fois dans un bloc, progressivement d’une transaction à l’autre, jusqu’à ce qu’ils atteignent l’adresse de Bob. Les clients légers peuvent faire ce qu’on appelle une vérification de paiement simplifiée (voir Nœuds de vérification simplifiée des paiements, ou Simplified Payment Verification (SPV)) en confirmant que la transaction est dans la chaîne de blocs et qu’elle a plusieurs blocs extraits après elle, fournissant ainsi l’assurance que les mineurs l’ont acceptée comme valide.

Bob peut maintenant dépenser le résultat de cette transaction et d’autres transactions. Par exemple, Bob peut payer un entrepreneur ou un fournisseur en transférant la valeur du paiement de la tasse de café d’Alice à ces nouveaux propriétaires. Très probablement, le logiciel Bitcoin de Bob regroupera de nombreux petits paiements en un paiement plus important, concentrant peut-être tous les revenus Bitcoin de la journée en une seule transaction. Cela regrouperait les différents paiements en un seul résultat (et une seule adresse). Pour un diagramme d’une transaction d’agrégation, voir Transaction agrégeant des fonds.

Au fur et à mesure que Bob dépense les paiements reçus d’Alice et d’autres clients, il étend la chaîne des transactions. Supposons que Bob paie son concepteur Web Gopesh à Bangalore pour une nouvelle page Web. Maintenant, la chaîne de transactions ressemblera à La transaction d’Alice dans le cadre d’une chaîne de transactions de Joe à Gopesh, où la sortie d’une transaction est utilisée comme entrée de la transaction suivante.

Dans ce chapitre, nous avons vu comment les transactions construisent une chaîne qui déplace la valeur d’un propriétaire à l’autre. Nous avons également suivi la transaction d’Alice, à partir du moment où elle a été créée dans son portefeuille, via le réseau Bitcoin et jusqu’aux mineurs qui l’ont enregistrée sur la chaîne de blocs. Dans le reste de ce livre, nous examinerons les technologies spécifiques derrière les portefeuilles, les adresses, les signatures, les transactions, le réseau et enfin le minage.

Si vous êtes un développeur, vous souhaiterez configurer un environnement de développement avec tous les outils, bibliothèques et logiciels de support pour le développement d’applications bitcoin. Dans ce chapitre très technique, nous allons parcourir ce processus étape par étape. Si le matériel devient trop dense (et que vous n’êtes pas en train de mettre en place un environnement de développement), n’hésitez pas à passer au chapitre suivant, qui est moins technique.

Le code source de Bitcoin Core peut être téléchargé sous forme d’archive ou en clonant le référentiel source faisant autorité à partir de GitHub. Sur la page de téléchargement de Bitcoin Core, sélectionnez la version la plus récente et téléchargez l’archive compressée du code source, par exemple, bitcoin-0.15.0.2.tar.gz. Vous pouvez également utiliser la ligne de commande git pour créer une copie locale du code source à partir de la page GitHub de bitcoin.

Dans cet exemple, nous utilisons la commande git pour créer une copie locale (un "clone") du code source :

Une fois l’opération de clonage git terminée, vous aurez une copie locale complète du référentiel de code source dans le répertoire bitcoin. Accédez à ce répertoire en tapant cd bitcoin à l’invite :

Le réseau pair à pair de Bitcoin est composé de "nœuds" de réseau, gérés principalement par des bénévoles et certaines des entreprises qui créent des applications bitcoin. Ceux qui exécutent des nœuds Bitcoin ont une vue directe et faisant autorité sur la chaîne de blocs Bitcoin, avec une copie locale de toutes les transactions, validées indépendamment par leur propre système. En exécutant un nœud, vous n’avez pas besoin de faire appel à un tiers pour valider une transaction. De plus, en exécutant un nœud Bitcoin, vous contribuez au réseau Bitcoin en le rendant plus robuste et sécuritaire.

Cependant, l’exécution d’un nœud nécessite un système connecté en permanence avec suffisamment de ressources pour traiter toutes les transactions bitcoin. Selon que vous choisissez d’indexer toutes les transactions et de conserver une copie complète de la chaîne de blocs, vous pouvez également avoir besoin de beaucoup d’espace disque et de mémoire RAM. Au début de 2021, un nœud à index complet a besoin de 2 Go de RAM et d’un minimum de 360 Go d’espace disque (voir https://www.blockchain.com/charts/blocks-size). Les nœuds Bitcoin transmettent et reçoivent également des transactions et des blocs Bitcoin, consommant de la bande passante Internet. Si votre connexion Internet est limitée, a un faible plafond de données ou est mesurée (facturée au gigabit), vous ne devriez probablement pas exécuter un nœud Bitcoin, ou l’exécuter d’une manière qui limite sa bande passante (voir Exemple de configuration d’un système à ressources limitées).

Malgré ces besoins en ressources, des milliers de bénévoles gèrent des nœuds Bitcoin. Certains fonctionnent sur des systèmes aussi simples qu’un Raspberry Pi (un ordinateur à 35 $ US de la taille d’un paquet de cartes). De nombreux volontaires exécutent également des nœuds Bitcoin sur des serveurs loués, généralement une variante de Linux. Une instance de Virtual Private Server (VPS ou serveur virtuel privé) ou Cloud Computing Server (ou serveur en infonuagique) peut être utilisée pour exécuter un nœud Bitcoin. Ces serveurs peuvent être loués pour 25 $ à 50 $ US par mois auprès de divers fournisseurs.

Pourquoi voudriez-vous exécuter un nœud ? Voici quelques-unes des raisons les plus courantes :

Si vous lisez ce livre et êtes intéressé par le développement d’un logiciel Bitcoin, vous devriez exécuter votre propre nœud.

Le client Bitcoin Core implémente une interface JSON-RPC accessible également à l’aide de l’assistant de ligne de commande bitcoin-cli. La ligne de commande nous permet d’expérimenter de manière interactive les fonctionnalités qui sont également disponibles par programmation via l’API. Pour commencer, appelez la commande help pour voir une liste des commandes RPC bitcoin disponibles :

Chacune de ces commandes peut prendre un certain nombre de paramètres. Pour obtenir une aide supplémentaire, une description détaillée et des informations sur les paramètres, ajoutez le nom de la commande après help. Par exemple, pour voir l’aide sur la commande getblockhash RPC :

À la fin des informations d’aide, vous verrez deux exemples de la commande RPC, utilisant l’assistant bitcoin-cli ou le client HTTP curl. Ces exemples montrent comment vous pouvez appeler la commande. Copiez le premier exemple et voyez le résultat :

Le résultat est un hachage de bloc, qui est décrit plus en détail dans les chapitres suivants. Mais pour l’instant, cette commande devrait renvoyer le même résultat sur votre système, démontrant que votre nœud Bitcoin Core est en cours d’exécution, accepte les commandes et dispose d’informations sur le bloc 1000 à vous renvoyer.

Dans les sections suivantes, nous allons démontrer quelques commandes RPC très utiles et leur sortie attendue.

Il existe de nombreux clients alternatifs, bibliothèques, boîtes à outils et même des implémentations de nœuds complets dans l’écosystème bitcoin. Ceux-ci sont implémentés dans une variété de langages de programmation, offrant aux programmeurs des interfaces natives dans leur langue préférée.

Les sections suivantes répertorient certaines des meilleures bibliothèques, clients et kits d’outils, organisés par langages de programmation.

 La propriété du bitcoin est établie par le biais de clés numériques, adresses Bitcoin et signatures numériques. Les clés numériques ne sont pas réellement stockées dans le réseau, mais sont plutôt créées et stockées par les utilisateurs dans un fichier, ou une simple base de données, appelée wallet. Les clés numériques du portefeuille d’un utilisateur sont totalement indépendantes du protocole Bitcoin et peuvent être générées et gérées par le logiciel du portefeuille de l’utilisateur sans référence à la chaîne de blocs ni accès à Internet. Les clés permettent de nombreuses propriétés intéressantes du bitcoin, notamment la confiance et le contrôle décentralisés, l’attestation de propriété et le modèle de sécurité à l’épreuve de la cryptographie.

La plupart des transactions bitcoin nécessitent une signature numérique valide à inclure dans la chaîne de blocs, qui ne peut être générée qu’avec une clé secrète ; par conséquent, toute personne possédant une copie de cette clé a le contrôle du bitcoin. La signature numérique utilisée pour dépenser des fonds est également appelée témoin, un terme utilisé en cryptographie. Les données témoins dans une transaction bitcoin témoignent de la véritable propriété des fonds dépensés.

Les clés sont fournies par paires constituées d’une clé privée (secrète) et une clé publique. Considérez la clé publique comme similaire à un numéro de compte bancaire et la clé privée comme similaire au code PIN secret, ou à la signature d’un chèque, qui permet de contrôler le compte. Ces clés numériques sont très rarement vues par les utilisateurs de bitcoin. Pour la plupart, ils sont stockés dans le fichier du portefeuille et gérés par le logiciel du portefeuille bitcoin.

Dans la partie paiement d’une transaction bitcoin, la clé publique du destinataire est représentée par son empreinte numérique, appelée adresse Bitcoin, qui est utilisée de la même manière que le nom du bénéficiaire sur un chèque (c’est-à-dire "Payer à l’ordre de") . Dans la plupart des cas, une adresse Bitcoin correspond et est générée à partir d’une clé publique. Cependant, toutes les adresses Bitcoin ne représentent pas des clés publiques ; ils peuvent également représenter d’autres bénéficiaires tels que des scripts, comme nous le verrons plus loin dans ce chapitre. De cette manière, les adresses Bitcoin font abstraction du destinataire des fonds, ce qui rend les destinations de transaction flexibles, similaires aux chèques papier : un instrument de paiement unique qui peut être utilisé pour payer les comptes des personnes, payer les comptes de l’entreprise, payer des factures ou payer en espèces. L’adresse Bitcoin est la seule représentation des clés que les utilisateurs verront régulièrement, car c’est la partie qu’ils doivent partager avec le monde.

Tout d’abord, nous présenterons la cryptographie et expliquerons les mathématiques utilisées dans le bitcoin. Ensuite, nous verrons comment les clés sont générées, stockées et gérées. Nous passerons en revue les différents formats de codage utilisés pour représenter les clés privées et publiques, les adresses et les adresses de script. Enfin, nous nous pencherons sur l’utilisation avancée des clés et des adresses : adresses personnalisées, multisignatures, scripts et portefeuilles papier.

Une adresse Bitcoin est une chaîne de chiffres et de caractères qui peut être partagée avec toute personne souhaitant vous envoyer de l’argent. Les adresses produites à partir de clés publiques consistent en une chaîne de chiffres et de lettres commençant par le chiffre "1". Voici un exemple d’adresse Bitcoin :

L’adresse Bitcoin est ce qui apparaît le plus souvent dans une transaction en tant que "destinataire" des fonds. Si nous comparons une transaction bitcoin à un chèque papier, l’adresse Bitcoin est le bénéficiaire, c’est ce que nous écrivons sur la ligne après "Payer à l’ordre de". Sur un chèque papier, ce bénéficiaire peut parfois être le nom d’un titulaire de compte bancaire, mais peut également inclure des sociétés, des institutions ou même des espèces. Étant donné que les chèques papier n’ont pas besoin de spécifier un compte, mais utilisent plutôt un nom abstrait en tant que destinataire des fonds, ce sont des instruments de paiement très flexibles. Les transactions Bitcoin utilisent une abstraction similaire, l’adresse Bitcoin, pour les rendre très flexibles. Une adresse Bitcoin peut représenter le propriétaire d’une paire de clés privée/publique, ou elle peut représenter autre chose, comme un script de paiement, comme nous le verrons dans Pay-to-Script-Hash (P2SH). Pour l’instant, examinons le cas simple; une adresse Bitcoin qui représente et est dérivée d’une clé publique.

L’adresse Bitcoin est dérivée de la clé publique grâce à l’utilisation d’un hachage cryptographique unidirectionnel. Un "algorithme de hachage" ou simplement "algorithme de hachage" est une fonction à sens unique qui produit une empreinte digitale ou un "hachage" (ou un "résultat de hachage") d’une entrée de taille arbitraire. Les fonctions de hachage cryptographiques sont largement utilisées dans le bitcoin : dans les adresses Bitcoin, dans les adresses de script et dans l’algorithme de minage de preuve de travail. Les algorithmes utilisés pour créer une adresse Bitcoin à partir d’une clé publique sont le Secure Hash Algorithm (SHA) et le RACE Integrity Primitives Evaluation Message Digest (RIPEMD), ou plus précisément SHA256 et RIPEMD160.

En commençant par la clé publique K, nous calculons le hachage SHA256, puis calculons le hachage RIPEMD160 du résultat, produisant un nombre de 160 bits (20 octets) :

où K est la clé publique et A est l’adresse Bitcoin résultante.

Les adresses Bitcoin sont presque toujours encodées en "Base58Check" (voir Encodage Base58 et Base58Check), qui utilise 58 caractères (un système de numérotation Base58) et une somme de contrôle pour faciliter la lisibilité humaine, éviter toute ambiguïté et protéger contre les erreurs de transcription et de saisie d’adresse. Base58Check est également utilisé de nombreuses autres manières dans Bitcoin, par exemple lorsque chaque fois qu’un utilisateur a besoin de lire et de transcrire correctement un numéro, tel qu’une adresse Bitcoin, une clé privée, une clé cryptée ou un hachage de script. Dans la section suivante, nous examinerons les mécanismes d’encodage et de décodage Base58Check et les représentations qui en résultent. Clé publique vers adresse Bitcoin : conversion d’une clé publique en adresse Bitcoin illustre la conversion d’une clé publique en une adresse Bitcoin.

Regardons le processus complet de création d’une adresse Bitcoin, d’une clé privée, à une clé publique (un point sur la courbe elliptique), à une adresse à hachage double, et enfin, l’encodage Base58Check. Le code C++ dans Création d’une adresse Bitcoin encodée en Base58Check à partir d’une clé privée montre le processus complet étape par étape, de la clé privée à l’adresse Bitcoin encodée en Base58Check. L’exemple de code utilise la bibliothèque libbitcoin introduite dans Clients, bibliothèques et boîtes à outils alternatifs pour certaines fonctions d’assistance.

Le code utilise une clé privée prédéfinie pour produire la même adresse Bitcoin à chaque exécution, comme indiqué dans Compilation et exécution du code addr.

La bibliothèque bitcoin la plus complète en Python est pybitcointools par Vitalik Buterin. Dans Génération et formatage de clés et d’adresses avec la bibliothèque pybitcointools, nous utilisons la bibliothèque pybitcointools (importée en tant que "bitcoin") pour générer et afficher des clés et des adresses dans différents formats.

Exécution de key-to-address-ecc-example.py affiche la sortie de l’exécution de ce code.

Un script démontrant les mathématiques de la courbe elliptique utilisées pour les clés bitcoin est un autre exemple, utilisant la bibliothèque Python ECDSA pour les mathématiques de la courbe elliptique et sans utiliser de bibliothèques bitcoin spécialisées.

Installation de la bibliothèque Python ECDSA et exécution du script ec_math.py affiche la sortie produite en exécutant ce script.

Dans les sections suivantes, nous examinerons les formes avancées de clés et d’adresses, telles que les clés privées cryptées, les adresses de script et des multisignatures, les adresses personnalisées, et les portefeuilles en papier.

Dans cette section, nous résumons les différentes technologies utilisées pour construire des portefeuilles Bitcoin conviviaux, sécurisés et flexibles.

Une idée faussement courante à propos du bitcoin est que les portefeuilles bitcoin contiennent du bitcoin. En fait, le portefeuille ne contient que des clés. Les "monnaies ou coins" sont enregistrés dans la chaîne de blocs sur le réseau Bitcoin. Les utilisateurs contrôlent les pièces sur le réseau en signant des transactions avec les clés de leur portefeuille. Dans un sens, un portefeuille bitcoin est un porte-clés.

Il existe deux principaux types de portefeuilles, qui se distinguent par le fait que les clés qu’ils contiennent sont liées les unes aux autres ou non.

Le premier type est un portefeuille non déterministe, où chaque clé est générée indépendamment à partir d’un nombre aléatoire. Les clés ne sont pas liées les unes aux autres. Ce type de portefeuille est également connu sous le nom de portefeuille JBOK à partir de l’expression "Just a Bunch Of Keys" (juste une poignées de clés).

Le deuxième type de portefeuille est un portefeuille déterministe, où toutes les clés sont dérivées d’une seule clé principale, connue sous le nom de seed (ou valeur d’amorçage). Toutes les clés de ce type de portefeuille sont liées les unes aux autres et peuvent être générées à nouveau si l’on dispose de la valeur d’amorçage d’origine. Il existe un certain nombre de méthodes différentes de dérivation de clé utilisées dans les portefeuilles déterministes. La méthode de dérivation la plus couramment utilisée utilise une structure arborescente et est connue sous le nom de portefeuille déterministe hiérarchique ou HD.

Les portefeuilles déterministes sont initialisés à partir d’une séquence aléatoire (une entropie). Pour faciliter leur utilisation, les séquences aléatoires sont encodées sous forme de mots anglais, également appelés mots de code mnémoniques.

Les prochaines sections présentent chacune de ces technologies à un niveau élevé.

Examinons maintenant en détail chacune des normes importantes de l’industrie utilisées par de nombreux portefeuilles Bitcoin.

Les transactions sont la partie la plus importante du système Bitcoin. Tout le reste dans le bitcoin est conçu pour garantir que les transactions peuvent être créées, propagées sur le réseau, validées et finalement ajoutées au grand livre mondial des transactions (la chaîne de blocs). Les transactions sont des structures de données qui encodent le transfert de valeur entre les participants au système Bitcoin. Chaque transaction est une entrée publique dans la chaîne de blocs de bitcoin, le grand livre comptable mondial en partie double.

Dans ce chapitre, nous examinerons toutes les différentes formes de transactions, ce qu’elles contiennent, comment les créer, comment elles sont vérifiées et comment elles deviennent partie intégrante de l’enregistrement permanent de toutes les transactions. Lorsque nous utilisons le terme "portefeuille" dans ce chapitre, nous faisons référence au logiciel qui construit les transactions, et pas seulement à la base de données des clés.

Dans Comment fonctionne Bitcoin, nous avons examiné la transaction utilisée par Alice pour payer un café au Bob’s Café à l’aide d’un explorateur de blocs (Transaction d’Alice au Bob’s Café).

L’application de l’explorateur de blocs montre une transaction de "l’adresse" d’Alice à "l’adresse" de Bob. Il s’agit d’une vue très simplifiée de ce qui est contenu dans une transaction. En fait, comme nous le verrons dans ce chapitre, une grande partie des informations affichées sont construites par l’explorateur de blocs et ne se trouvent pas réellement dans la transaction.

La base fondamentale d’une transaction bitcoin est une sortie de transaction. Les sorties de transaction sont des morceaux indivisibles de monnaie bitcoin, enregistrés sur la chaîne de blocs et reconnus comme valides par l’ensemble du réseau. Les nœuds complets Bitcoin suivent toutes les sorties disponibles et utilisables, appelées sorties de transaction non dépensées, ou UTXO. La collection de tous les UTXO est connue sous le nom d'ensemble UTXO et compte actuellement des millions d’UTXO. L’ensemble UTXO augmente à mesure que de nouveaux UTXO sont créés et diminue lorsque UTXO est consommé. Chaque transaction représente un changement (transition d’état) dans l’ensemble UTXO.

Lorsque nous disons que le portefeuille d’un utilisateur a "reçu" du bitcoin, nous voulons dire que le portefeuille a détecté sur la chaîne de blocs un UTXO pouvant être dépensé avec l’une des clés contrôlées par ce portefeuille. Ainsi, le "solde" de bitcoins d’un utilisateur est la somme de tous les UTXO que le portefeuille de l’utilisateur peut dépenser et qui peuvent être dispersés parmi des centaines de transactions et des centaines de blocs. Le concept de solde est créé par l’application de portefeuille. Le portefeuille calcule le solde de l’utilisateur en scannant la chaîne de blocs et en agrégeant la valeur de tout UTXO que le portefeuille peut dépenser avec les clés qu’il contrôle. La plupart des portefeuilles maintiennent une base de données ou utilisent un service de base de données pour stocker un ensemble de référence rapide de tous les UTXO qu’ils peuvent dépenser avec les clés qu’ils contrôlent.

Chaîne de transaction de Joe à Gopesh en cours de construction sur la chaîne de blocs affiche la chaîne de blocs à trois moments différents, alors que la chaîne de transaction de Joe à Gopesh est en cours de construction. Remarquez comment chaque transaction dépense un UTXO qui a été créé dans une transaction précédente, le transformant en une sortie de transaction dépensée, ou STXO. Puisque la transaction #1 (de Joe à Alice) dépense un seul UTXO (de Joe) et crée un seul UTXO (à Alice), elle ne modifie pas la taille de l’ensemble UTXO. D’autre part, les transactions #2 et #3 créent toutes deux des sorties de change à l’expéditeur, dépensant un seul UTXO et créant deux UTXO (le paiement et la sortie de change). Par conséquent, chacun d’eux augmente la taille de l’ensemble UTXO de 1.

Une sortie de transaction peut avoir une valeur arbitraire (entière) libellée comme un multiple de satoshis. Tout comme les dollars peuvent être divisés jusqu’à deux décimales sous forme de cents, le bitcoin peut être divisé jusqu’à huit décimales sous forme de satoshis. Bien qu’une sortie puisse avoir n’importe quelle valeur arbitraire, une fois créée, elle est indivisible. Il s’agit d’une caractéristique importante des sorties qui doit être soulignée : les sorties sont des unités de valeur discrètes et indivisibles, libellées en satoshis entiers. Une production non dépensée ne peut être consommée dans son intégralité que par une transaction.

Si un UTXO est supérieur à la valeur souhaitée d’une transaction, il doit toujours être consommé dans son intégralité et le changement doit être généré dans la transaction. En d’autres termes, si vous avez un UTXO d’une valeur de 20 bitcoins et que vous souhaitez payer seulement 1 bitcoin, votre transaction doit consommer l’intégralité de l’UTXO de 20 bitcoins et produire deux sorties : une payant 1 bitcoin au destinataire souhaité et une autre payant 19 bitcoin en échange. retour dans votre portefeuille. En raison de la nature indivisible des sorties de transaction, la plupart des transactions bitcoin devront générer du change.

Imaginez une cliente qui achète une boisson à 1,50 $, puise dans son portefeuille et essaie de trouver une combinaison de pièces et de billets de banque pour couvrir le coût de 1,50 $. L’acheteur choisira la monnaie exacte si disponible, par exemple un billet d’un dollar et deux quarts (un quart vaut 0,25 $), ou une combinaison de coupures plus petites (six quarts), ou si nécessaire, une unité plus grande comme un billet de 5 $. Si elle remet trop d’argent, disons 5 $, au propriétaire du magasin, elle s’attendra à 3,50 $ de monnaie, qu’elle remettra dans son portefeuille et qu’elle disposera pour de futures transactions.

De même, une transaction bitcoin doit être créée à partir de l’UTXO d’un utilisateur dans toutes les dénominations disponibles pour cet utilisateur. Les utilisateurs ne peuvent pas couper un UTXO en deux, pas plus qu’ils ne peuvent couper un billet d’un dollar en deux et l’utiliser comme monnaie. L’application de portefeuille de l’utilisateur sélectionne généralement à partir de l’UTXO disponible de l’utilisateur pour composer un montant supérieur ou égal au montant de transaction souhaité.

Comme dans la vraie vie, l’application bitcoin peut utiliser plusieurs stratégies pour satisfaire le montant de l’achat : combiner plusieurs unités plus petites, trouver la monnaie exacte ou utiliser une seule unité supérieure à la valeur de la transaction et rendre la monnaie. Tout cet assemblage complexe d’UTXO dépensables est effectué automatiquement par le portefeuille de l’utilisateur et est invisible pour les utilisateurs. Cela n’est pertinent que si vous construisez par programme des transactions brutes à partir d’UTXO.

Une transaction consomme des sorties de transaction non dépensées précédemment enregistrées et crée de nouvelles sorties de transaction qui peuvent être consommées par une transaction future. De cette façon, des morceaux de valeur bitcoin passent d’un propriétaire à l’autre dans une chaîne de transactions consommant et créant des UTXO.

L’exception à la chaîne de sortie et d’entrée est une type spécial de transaction appelé transaction coinbase, qui est la première transaction de chaque bloc. Cette transaction y est placée par le mineur "gagnant" et crée un tout nouveau bitcoin payable à ce mineur en récompense de l’exploitation minière. Cette transaction coinbase spéciale ne consomme pas d’UTXO ; à la place, il a un type spécial d’entrée appelé "coinbase". C’est ainsi que la masse monétaire du bitcoin est créée pendant le processus de minage, comme nous le verrons dans Minage et Consensus.

Jusqu’à présent, nous n’avons approfondi aucun détail sur les "signatures numériques". Dans cette section, nous examinons le fonctionnement des signatures numériques et comment elles peuvent présenter la preuve de la propriété d’une clé privée sans révéler cette clé privée.

L’algorithme de signature numérique utilisé dans le bitcoin est l'Elliptic Curve Digital Signature Algorithm, ou ECDSA. ECDSA est l’algorithme utilisé pour les signatures numériques basées sur des paires de clés privées/publiques à courbe elliptique, comme décrit dans La cryptographie à courbe elliptique expliquée. ECDSA est utilisé par les fonctions de script OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG et OP_CHECKMULTISIGVERIFY. Chaque fois que vous les voyez dans un script de verrouillage, le script de déverrouillage doit contenir une signature ECDSA.

Une signature numérique a trois objectifs en bitcoin. Premièrement, la signature prouve que le propriétaire de la clé privée, qui est implicitement le propriétaire des fonds, a autorisé la dépense de ces fonds. Deuxièmement, la preuve de l’autorisation est indéniable (non-répudiable). Troisièmement, la signature prouve que la transaction (ou des parties spécifiques de la transaction) n’a pas et ne peut pas être modifiée par qui que ce soit après avoir été signée.

Notez que chaque entrée de transaction est signée indépendamment. Ceci est essentiel, car ni les signatures ni les entrées ne doivent appartenir ou être appliquées par les mêmes "propriétaires". En fait, un schéma de transaction spécifique appelé "CoinJoin" utilise ce fait pour créer des transactions multipartites pour la confidentialité.

Nous avons commencé ce chapitre avec la découverte que les transactions sont très différentes "dans les coulisses" de la façon dont elles sont présentées dans les portefeuilles, les explorateurs de chaîne de blocs, et d’autres applications destinées aux utilisateurs. De nombreux concepts simplistes et familiers des chapitres précédents, tels que les adresses et les soldes Bitcoin, semblent être absents de la structure de transaction. Nous avons vu que les transactions ne contiennent pas d’adresses Bitcoin en soi, mais fonctionnent plutôt via des scripts qui verrouillent et déverrouillent des valeurs discrètes de bitcoin. Les soldes ne sont présents nulle part dans ce système et pourtant, chaque application de portefeuille affiche bien en évidence le solde du portefeuille de l’utilisateur.

Maintenant que nous avons exploré ce qui est réellement inclus dans une transaction bitcoin, nous pouvons examiner comment les abstractions de niveau supérieur sont dérivées des composants apparemment primitifs de la transaction.

Regardons à nouveau comment la transaction d’Alice a été présentée sur un explorateur de blocs populaire (Transaction d’Alice au Bob’s Café).

Sur le côté gauche de la transaction, l’explorateur de explorateur de chaîne de blocs affiche l’adresse Bitcoin d’Alice comme "expéditeur". En fait, cette information n’est pas dans la transaction elle-même. Lorsque l’explorateur de chaîne de blocs fait référence à la transaction, il fait également référence à la transaction précédente associée à l’entrée et extrait la première sortie de cette transaction plus ancienne. Dans cette sortie se trouve un script de verrouillage qui verrouille l’UTXO sur le hachage de la clé publique d’Alice (un script P2PKH). L’explorateur de chaîne de blocs a extrait le hachage de la clé publique et l’a encodé à l’aide de l’encodage Base58Check pour produire et afficher l’adresse Bitcoin qui représente cette clé publique.

De même, sur le côté droit, l’explorateur de chaîne de blocs affiche les deux sorties ; le premier à l’adresse Bitcoin de Bob et le second à l’adresse Bitcoin d’Alice (comme change). Encore une fois, pour créer ces adresses Bitcoin, l’explorateur de chaîne de blocs a extrait le script de verrouillage de chaque sortie, l’a reconnu comme un script P2PKH et a extrait le hachage de clé publique de l’intérieur. Enfin, l’explorateur de chaîne de blocs a réencodé chaque hachage de clé publique avec Base58Check pour produire et afficher les adresses Bitcoin.

Si vous deviez cliquer sur l’adresse Bitcoin de Bob, l’explorateur de explorateur de chaîne de blocs vous montrerait la vue dans Le solde de l’adresse Bitcoin de Bob.

L’explorateur de la chaîne de blocs affiche le solde de l’adresse Bitcoin de Bob. Mais nulle part dans le système Bitcoin il n’y a un concept de "solde". Au lieu de cela, les valeurs affichées ici sont construites par l’explorateur de explorateur de chaîne de blocs comme suit.

Pour construire le montant "Total reçu", l’explorateur de explorateur de la chaîne de blocs décodera d’abord l’encodage Base58Check de l’adresse Bitcoin pour récupérer le hachage 160 bits de la clé publique de Bob qui est encodé dans l’adresse. Ensuite, l’explorateur de chaîne de blocs recherchera dans la base de données des transactions, à la recherche de sorties avec des scripts de verrouillage P2PKH contenant le hachage de la clé publique de Bob. En additionnant la valeur de toutes les sorties, l’explorateur de la chaîne de blocs peut produire la valeur totale reçue.

Construire le solde actuel (affiché comme "Solde final") nécessite un peu plus de travail. L’explorateur de la chaîne de blocs conserve une base de données distincte des sorties actuellement non dépensées, l’ensemble UTXO. Pour maintenir cette base de données, l’explorateur de la chaîne de blocs doit surveiller le réseau Bitcoin, ajouter les UTXO nouvellement créés et supprimer les UTXO dépensés, en temps réel, tels qu’ils apparaissent dans les transactions non confirmées. Il s’agit d’un processus compliqué qui dépend du suivi des transactions au fur et à mesure qu’elles se propagent, ainsi que du maintien d’un consensus avec le réseau Bitcoin pour s’assurer que la chaîne correcte est suivie. Parfois, l’explorateur de la chaîne de blocs est désynchronisé et sa perspective de l’ensemble UTXO est incomplète ou incorrecte.

À partir de l’ensemble UTXO, l’explorateur de la chaîne de blocs résume la valeur de toutes les sorties non dépensées faisant référence au hachage de la clé publique de Bob et produit le numéro "Solde final" affiché à l’utilisateur.

Afin de produire cette image unique, avec ces deux "soldes", l’explorateur de la chaîne de blocs doit indexer et rechercher parmi des dizaines, des centaines, voire des centaines de milliers de transactions.

En résumé, les informations présentées aux utilisateurs via les applications de portefeuille, les explorateurs de chaînes de blocs et d’autres interfaces utilisateur Bitcoin sont souvent composées d’abstractions de niveau supérieur qui sont dérivées en recherchant de nombreuses transactions différentes, en inspectant leur contenu et en manipulant les données qu’elles contiennent. En présentant cette vision simpliste des transactions bitcoin qui ressemblent à des chèques bancaires d’un expéditeur à un destinataire, ces applications doivent extraire de nombreux détails sous-jacents. Ils se concentrent principalement sur les types de transactions courants : P2PKH avec des signatures SIGHASH_ALL sur chaque entrée. Ainsi, alors que les applications bitcoin peuvent présenter plus de 80 % de toutes les transactions de manière facile à lire, elles sont parfois bloquées par des transactions qui s’écartent de la norme. Les transactions qui contiennent des scripts de verrouillage plus complexes, ou différents indicateurs SIGHASH, ou de nombreuses entrées et sorties, démontrent la simplicité et la faiblesse de ces abstractions.

Chaque jour, des centaines de transactions qui ne contiennent pas de sorties P2PKH sont confirmées sur la chaîne de blocs. Les explorateurs de chaîne de blocs les présentent souvent avec des messages d’avertissement rouges indiquant qu’ils ne peuvent pas décoder une adresse.

Comme nous le verrons au chapitre suivant, il ne s’agit pas nécessairement de transactions étranges. Ce sont des transactions qui contiennent des scripts de verrouillage plus complexes que le P2PKH commun. Nous apprendrons ensuite à décoder et à comprendre des scripts plus complexes et les applications qu’ils prennent en charge.

Dans le chapitre précédent, nous avons présenté les éléments de base des transactions bitcoin et examiné le type de script de transaction le plus courant, le script P2PKH. Dans ce chapitre, nous examinerons des scripts plus avancés et comment nous pouvons les utiliser pour créer des transactions avec des conditions complexes.

Tout d’abord, nous examinerons les scripts multisignature. Ensuite, nous examinerons le deuxième script de transaction le plus courant, Pay-to-Script-Hash, qui ouvre tout un monde de scripts complexes. Ensuite, nous examinerons de nouveaux opérateurs de script qui ajoutent une dimension temporelle au bitcoin, via les timelocks (verrouillage temporel). Enfin, nous examinerons les Segregated Witness (témoins séparés), une modification architecturale de la structure des transactions.

Les scripts multisignatures définissent une condition dans laquelle N clés publiques sont enregistrées dans le script et au moins M d’entre elles doivent fournir des signatures pour débloquer les fonds. Ceci est également connu sous le nom de schéma M-sur-N, où N est le nombre total de clés et M est le seuil de signatures requises pour la validation. Par exemple, une multisignature 2 sur 3 est celle où trois clés publiques sont répertoriées comme signataires potentiels et au moins deux d’entre elles doivent être utilisées pour créer des signatures pour une transaction valide afin de dépenser les fonds.

À l’heure actuelle, les scripts multisignatures standard sont limités à un maximum de 3 clés publiques répertoriées, ce qui signifie que vous pouvez faire n’importe quoi d’une multisignature 1 sur 1 jusqu’à 3 sur 3 ou toute combinaison dans cette plage. La limitation à 3 clés répertoriées pourrait être levée au moment de la publication de ce livre, alors vérifiez la fonction IsStandard() pour voir ce qui est actuellement accepté par le réseau. Notez que la limite de 3 clés s’applique uniquement aux scripts multisignatures standard (également appelés "nus (bare en anglais)"), et non aux scripts multisignatures enveloppés dans un script Pay-to-Script-Hash (P2SH). Les scripts multisignatures P2SH sont limités à 15 clés, permettant jusqu’à 15 multisignatures sur 15. Cette limitation est également imposée par la fonction IsStandard(). Nous en apprendrons davantage sur P2SH dans Pay-to-Script-Hash (P2SH).

La forme générale d’un script de verrouillage définissant une condition multisignature M-de-N est :

où N est le nombre total de clés publiques répertoriées et M est le seuil de signatures requises pour dépenser la sortie.

Un script de verrouillage définissant une condition multisignature 2 sur 3 ressemble à ceci :

Le script de verrouillage précédent peut se contenter d’un script de déverrouillage contenant n’importe quelle combinaison de deux signatures issues des clés privées correspondant aux trois clés publiques listées :

Les deux scripts ensemble formeraient le script de validation combiné :

Lorsqu’il est exécuté, ce script combiné sera évalué à TRUE si, et seulement si, le script de déverrouillage correspond aux conditions définies par le script de verrouillage. Dans ce cas, la condition est de savoir si le script de déverrouillage possède une signature valide à partir des deux clés privées qui correspondent à deux des trois clés publiques définies comme une charge.

Pay- to-Script-Hash (P2SH) a été introduit en 2012 en tant que nouveau type de transaction puissant qui simplifie grandement l’utilisation de scripts de transaction complexes. Pour expliquer le besoin de P2SH, regardons un exemple pratique.

("Pay-to-Script-Hash (P2SH)", "exemple d’import/export")Dans Présentation nous avons présenté Mohammed, un importateur d’électronique basé à Dubaï. La société de Mohammed utilise largement la fonction multisignature de Bitcoin pour ses comptes d’entreprise. Les scripts multisignatures sont l’une des utilisations les plus courantes des capacités de script avancées de Bitcoin et constituent une fonctionnalité très puissante. La société de Mohammed utilise un script multisignature pour tous les paiements des clients, connu en termes comptables sous le nom de "comptes débiteurs ou recevables". Avec le schéma multisignature, tous les paiements effectués par les clients sont verrouillés de telle manière qu’ils nécessitent au moins deux signatures pour être libérés, de Mohammed et de l’un de ses partenaires ou de son avocat qui dispose d’une clé de secours. Un système multisignature comme celui-ci offre des contrôles de gouvernance d’entreprise et protège contre le vol, le détournement de fonds ou la perte.

Le script résultant est assez long et ressemble à ceci :

Bien que les scripts multisignatures soient une fonctionnalité puissante, ils sont lourds à utiliser. Compte tenu du script précédent, Mohammed devrait communiquer ce script à chaque client avant le paiement. Chaque client devrait utiliser un logiciel spécial de portefeuille bitcoin avec la possibilité de créer des scripts de transaction personnalisés, et chaque client devrait comprendre comment créer une transaction à l’aide de scripts personnalisés. De plus, la transaction résultante serait environ cinq fois plus importante qu’une simple transaction de paiement, car ce script contient des clés publiques très longues. Le fardeau de cette transaction extra-large serait supporté par le client sous la forme de frais. Enfin, un gros script de transaction comme celui-ci serait transporté dans l’UTXO défini dans la RAM de chaque nœud complet, jusqu’à ce qu’il soit dépensé. Tous ces problèmes rendent difficile l’utilisation de scripts de verrouillage complexes dans la pratique.

P2SH a été développé pour résoudre ces difficultés pratiques et rendre l’utilisation de scripts complexes aussi simple qu’un paiement à une adresse Bitcoin. Avec les paiements P2SH, le script de verrouillage complexe est remplacé par son empreinte numérique, un hachage cryptographique. Lorsqu’une transaction tentant de dépenser l’UTXO est présentée ultérieurement, elle doit contenir le script correspondant au hachage, en plus du script de déverrouillage. En termes simples, P2SH signifie "payer à un script correspondant à ce hachage, un script qui sera présenté plus tard lorsque cette sortie sera dépensée".

Dans les transactions P2SH, le script de verrouillage qui est remplacé par un hachage est appelé redeem script ou script de rachat car il est présenté au système au moment du rachat plutôt que comme un script de verrouillage. Script complexe sans P2SH affiche le script sans P2SH et Script complexe comme P2SH montre le même script encodé avec P2SH.

Comme vous pouvez le voir dans les tableaux, avec P2SH, le script complexe qui détaille les conditions de dépense de la sortie (script de rachat) n’est pas présenté dans le script de verrouillage. Au lieu de cela, seul un hachage de celui-ci se trouve dans le script de verrouillage et le script de rachat lui-même est présenté plus tard, dans le cadre du script de déverrouillage lorsque la sortie est dépensée. Cela déplace le fardeau des frais et de la complexité de l’expéditeur (qui crée la transaction) vers le destinataire (qui déverrouille et dépense la transaction).

Examinons la société de Mohammed, le script multisignature complexe et les scripts P2SH qui en résultent.

Tout d’abord, le script multisignature que la société de Mohammed utilise pour tous les paiements entrants des clients :

Si les espaces réservés sont remplacés par des clés publiques réelles (affichées ici sous forme de nombres de 520 bits commençant par 04), vous pouvez voir que ce script devient très long :

Ce script entier peut à la place être représenté par un hachage cryptographique de 20 octets, en appliquant d’abord l’algorithme de hachage SHA256, puis en appliquant l’algorithme RIPEMD160 sur le résultat.

Nous utilisons libbitcoin-explorer (bx) sur la ligne de commande pour produire le hachage du script, comme suit :

La série de commandes ci-dessus encode d’abord le script de rachat multisig de Mohammed en tant que script bitcoin sérialisé encodé en hexadécimal. La commande bx suivante calcule le hachage SHA256 de cela. La prochaine commande bx hache à nouveau avec RIPEMD160, produisant le hachage de script final :

Le hachage de 20 octets du script de rachat de Mohammed est :

Une transaction P2SH verrouille la sortie sur ce hachage au lieu du script de rachat plus long, en utilisant le script de verrouillage :

qui, comme vous pouvez le voir, est beaucoup plus courte. Au lieu de "payer à ce script multisignature à 5 clés", la transaction équivalente à P2SH est "payer à un script avec ce hachage". Un client effectuant un paiement à la société de Mohammed n’a qu’à inclure ce script de verrouillage beaucoup plus court dans son paiement. Lorsque Mohammed et ses partenaires veulent dépenser cet UTXO, ils doivent présenter le script de rachat original (celui dont le hachage a verrouillé l’UTXO) et les signatures nécessaires pour le déverrouiller, comme ceci :

Les deux scripts sont combinés en deux étapes. Tout d’abord, le script de rachat est vérifié par rapport au script de verrouillage pour s’assurer que le hachage correspond :

Si le hachage du script de rachat correspond, le script de déverrouillage est exécuté de lui-même pour déverrouiller le script de rachat :

Presque tous les scripts décrits dans ce chapitre ne peuvent être implémentés qu’en tant que scripts P2SH. Par exemple, un script de verrouillage multisignature standard 2 sur 5 ne peut pas être utilisé directement dans le script de verrouillage d’un UTXO, car IsStandard() invaliderait la transaction. Pour se conformer, un script de verrouillage P2SH peut être utilisé à la place, comme vu ci-dessus. Une transaction qui comprend alors un script de déverrouillage P2SH peut être utilisée pour racheter cet UTXO et sera valide tant qu’elle ne contient pas plus de 15 clés publiques.

Les bitcoins sont distribués et Le grand livre horodaté, la chaîne de blocs, a des utilisations potentielles bien au-delà des paiements. De nombreux développeurs ont essayé d’utiliser le langage de script de transaction pour tirer parti de la sécurité et de la résilience du système pour des applications telles que les services de notaire numérique, les certificats d’actions et les contrats intelligents. Les premières tentatives d’utilisation du langage de script de bitcoin à ces fins impliquaient la création de sorties de transaction qui enregistraient des données sur la chaîne de blocs; par exemple, pour enregistrer une empreinte digitale d’un fichier de manière à ce que n’importe qui puisse établir la preuve de l’existence de ce fichier à une date précise par référence à cette transaction.

L’utilisation de la chaîne de blocs de Bitcoin pour stocker les données non liées aux paiements en bitcoins sont un sujet controversé. De nombreux développeurs considèrent cette utilisation abusive et veulent la décourager. D’autres y voient une démonstration des puissantes capacités de la technologie chaîne de blocs et souhaitent encourager une telle expérimentation. Ceux qui s’opposent à l’inclusion de données de non-paiement soutiennent que cela provoque un "gonflement de la chaîne de blocs", ce qui impose à ceux qui exécutent des nœuds Bitcoin complets de supporter le coût du stockage sur disque pour les données que la chaîne de blocs n’était pas destinée à transporter. De plus, de telles transactions créent des UTXO qui ne peuvent pas être dépensés, en utilisant l’adresse Bitcoin de destination comme un champ libre de 20 octets. Parce que l’adresse est utilisée pour les données, elle ne correspond pas à une clé privée et l’UTXO résultant ne peut jamais être dépensé ; c’est un faux paiement. Ces transactions qui ne peuvent jamais être dépensées ne sont donc jamais supprimées de l’ensemble UTXO et entraînent une augmentation permanente de la taille de la base de données UTXO, ou un "gonflement".

Dans la version 0.9 du client Bitcoin Core, un compromis a été trouvé avec l’introduction de l’opérateur RETURN. RETURN permet aux développeurs d’ajouter 80 octets de données de non-paiement à une sortie de transaction. Cependant, contrairement à l’utilisation de "faux" UTXO, l’opérateur RETURN crée une sortie explicitement et manifestement indépensable, qui n’a pas besoin d’être stockée dans l’ensemble UTXO. Les sorties RETURN sont enregistrées sur la chaîne de blocs, elles consomment donc de l’espace disque et contribuent à l’augmentation de la taille de la chaîne de blocs, mais elles ne sont pas stockées dans l’ensemble UTXO et ne gonflent donc pas le bassin de mémoire UTXO et ne surchargent pas les nœuds complets avec plus de dépenses en RAM.

Les scripts RETURN ressemblent à ceci :

La portion de données est limitée à 80 octets et représente le plus souvent un hachage, comme la sortie de l’algorithme SHA256 (32 octets). De nombreuses applications mettent un préfixe devant les données pour aider à identifier l’application. Par exemple, le service de notarisation numérique Preuve d’existence utilise le préfixe de 8 octets DOCPROOF, qui est encodé en ASCII sous la forme 44 4f 43 50 52 4f 4f 46 en hexadécimal.

Gardez à l’esprit qu’il n’y a pas de "script de déverrouillage" correspondant à RETURN qui pourrait éventuellement être utilisé pour "passer" une sortie RETURN. L’intérêt de RETURN est que vous ne pouvez pas dépenser l’argent bloqué dans cette sortie, et donc il n’a pas besoin d’être conservé dans l’ensemble UTXO comme potentiellement dépensable - RETURN est manifestement indépensable. RETURN est généralement une sortie avec un montant de zéro bitcoin, car tout bitcoin attribué à une telle sortie est effectivement perdu à jamais. Si un RETURN est référencé comme entrée dans une transaction, le moteur de validation de script arrêtera l’exécution du script de validation et marquera la transaction comme invalide. L’exécution de RETURN provoque essentiellement le script "RETURN" avec un FALSE et s’arrête. Ainsi, si vous référencez accidentellement une sortie RETURN comme entrée dans une transaction, cette transaction n’est pas valide.

Une transaction standard (c’est-à-dire conforme aux vérifications IsStandard()) ne peut avoir qu’une seule sortie RETURN. Cependant, une seule sortie RETURN peut être combinée dans une transaction avec des sorties de tout autre type.

Deux nouvelles options de ligne de commande ont été ajoutées dans Bitcoin Core à partir de la version 0.10. L’option datacarrier contrôle le relais et l’exploration des transactions RETURN, avec la valeur par défaut définie à "1" pour les autoriser. L’option datacarriersize prend un argument numérique spécifiant la taille maximale en octets du script RETURN, 83 octets par défaut, ce qui permet un maximum de 80 octets de données RETURN plus un octet d’opcode RETURN et deux octets de Opcode PUSHDATA.

Les verrous temporels (ou timelocks) sont des restrictions sur les transactions ou les sorties qui ne permettent de dépenser qu’après un certain temps. Bitcoin a eu une fonction de verrouillage du temps au niveau de la transaction depuis le début. Il est implémenté par le champ nLocktime dans une transaction. Deux nouvelles fonctionnalités de verrou temporel ont été introduites fin 2015 et mi-2016 qui offrent des verrous temporels de niveau UTXO. Ce sont CHECKLOCKTIMEVERIFY et CHECKSEQUENCEVERIFY.

Les verrous temporels sont utiles pour postdater les transactions et verrouiller les fonds à une date future. Plus important encore, les verrous temporels étendent les scripts bitcoin dans la dimension du temps, ouvrant la porte à des contrats intelligents complexes en plusieurs étapes.

L’une des fonctionnalités les plus puissantes de Bitcoin Script est le contrôle de flux, également connu sous le nom de clauses conditionnelles. Vous êtes probablement familiarisé avec le contrôle de flux dans divers langages de programmation qui utilisent la construction IF...THEN...ELSE. Les clauses conditionnelles Bitcoin semblent un peu différentes, mais sont essentiellement la même construction.

À un niveau de base, les opcodes conditionnels bitcoin nous permettent de construire un script de rachat qui a deux façons d’être déverrouillé, en fonction d’un résultat TRUE/FALSE d’évaluation d’une condition logique. Par exemple, si x est TRUE, le script de rachat est A et le script de rachat ELSE est B.

De plus, les expressions conditionnelles Bitcoin peuvent être "imbriquées" indéfiniment, ce qui signifie qu’une clause conditionnelle peut en contenir une autre, qui en contient une autre, etc. Le contrôle de flux Bitcoin Script peut être utilisé pour construire des scripts très complexes avec des centaines voire des milliers de chemins d’exécution possibles. Il n’y a pas de limite à l’imbrication, mais les règles de consensus imposent une limite à la taille maximale, en octets, d’un script.

Bitcoin implémente le contrôle de flux à l’aide des opcodes IF, ELSE, ENDIF et NOTIF. De plus, les expressions conditionnelles peuvent contenir des opérateurs booléens tels que BOOLAND, BOOLOR et NOT.

À première vue, vous pouvez trouver les scripts de contrôle de flux du bitcoin déroutants. En effet, Bitcoin Script est un langage de pile. De la même manière que 1 + 1 semble "renversé" lorsqu’il est exprimé comme 1 1 ADD, les clauses de contrôle de flux dans bitcoin semblent également "renversés".

Dans la plupart des langages de programmation traditionnels (procéduraux), le contrôle de flux ressemble à ceci :

Dans un langage basé sur la pile comme Bitcoin Script, la condition logique vient avant le IF, ce qui le fait apparaître "en arrière", comme ceci :

Lors de la lecture du script Bitcoin, rappelez-vous que la condition évaluée vient avant l’opcode IF.

Dans cette section, nous combinons de nombreux concepts de ce chapitre en un seul exemple.

Notre exemple utilise l’histoire de Mohammed, le propriétaire d’une entreprise à Dubaï qui exploite une entreprise d’import/export.

Dans cet exemple, Mohammed souhaite construire un compte de capital d’entreprise avec des règles flexibles. Le schéma qu’il crée nécessite différents niveaux d’autorisation en fonction des verrous temporels. Les participants au programme multisig sont Mohammed, ses deux partenaires Saeed et Zaira, et leur avocat Abdul. Les trois partenaires prennent des décisions basées sur une règle de majorité, donc deux des trois doivent être d’accord. Cependant, en cas de problème avec leurs clés, ils souhaitent que leur avocat puisse récupérer les fonds avec l’une des trois signatures d’associés. Enfin, si tous les associés sont indisponibles ou inaptes pendant un certain temps, ils souhaitent que l’avocat puisse gérer directement le compte.

Voici le script de rachat que Mohammed conçoit pour y parvenir (préfixe de numéro de ligne en tant que XX) :

Le script de Mohammed implémente trois chemins d’exécution à l’aide de clauses de contrôle de flux imbriquées IF...ELSE.

Dans le premier chemin d’exécution, ce script fonctionne comme un simple multisig 2 sur 3 avec les trois partenaires. Ce chemin d’exécution se compose des lignes 3 et 9. La ligne 3 définit le quorum du multisig à 2 (2-de-3). Ce chemin d’exécution peut être sélectionné en mettant TRUE TRUE à la fin du script de déverrouillage :

Le deuxième chemin d’exécution ne peut être utilisé qu’après 30 jours à compter de la création de l’UTXO. À ce moment-là, il faut la signature d’Abdul l’avocat et de l’un des trois partenaires (un multisig 1 sur 3). Ceci est réalisé par la ligne 7, qui fixe le quorum pour le multisig à 1. Pour sélectionner ce chemin d’exécution, le script de déverrouillage se terminerait par FALSE TRUE :

Enfin, la troisième voie d’exécution permet à Abdul l’avocat de dépenser les fonds seul, mais seulement après 90 jours. Pour sélectionner ce chemin d’exécution, le script de déverrouillage doit se terminer par FALSE :

Essayez d’exécuter le script sur papier pour voir comment il se comporte sur la pile.

Quelques éléments supplémentaires à prendre en compte lors de la lecture de cet exemple. Voyez si vous pouvez trouver les réponses :

Le Segregated Witness (segwit) ou le "témoin séparé" est une mise à niveau des règles de consensus bitcoin et du protocole réseau, proposée et mise en œuvre en tant que embranchement convergent BIP-9 qui a été activé sur le réseau principal de bitcoin le 1er août 2017.

En cryptographie, le terme « témoin » est utilisé pour décrire une solution à un puzzle cryptographique. En termes de bitcoin, le témoin satisfait une condition cryptographique placée sur une sortie de transaction non dépensée (UTXO).

Dans le contexte du bitcoin, une signature numérique est un type de témoin, mais un témoin est plus largement toute solution qui peut satisfaire les conditions imposées à un UTXO et débloquer cet UTXO pour les dépenses. Le terme "témoin" est un terme plus général pour un "script de déverrouillage" ou "scriptSig".

Avant l’introduction de segwit, chaque entrée d’une transaction était suivie des données témoins qui la déverrouillaient. Les données témoins ont été intégrées à la transaction dans le cadre de chaque entrée. Le terme témoin séparé, ou segwit en abrégé, signifie simplement séparer la signature ou le script de déverrouillage d’une sortie spécifique. Pensez "scriptSig séparé" ou "signature séparée" dans sa forme la plus simple.

Le témoin séparé (Segregated Witness) est donc une modification architecturale du bitcoin qui vise à déplacer les données témoins du champ scriptSig (script de déverrouillage) d’une transaction vers une structure de données témoin distincte qui accompagne une transaction. Les clients peuvent demander des données de transaction avec ou sans les données de témoin qui les accompagnent.

Dans cette section, nous examinerons certains des avantages du témoin séparé, décrirons le mécanisme utilisé pour déployer et mettre en œuvre ce changement d’architecture et démontrerons l’utilisation du témoin séparé dans les transactions et les adresses.

Le témoin séparé est défini par les BIP suivants :

Bitcoin est structuré comme une architecture de réseau pair à pair au-dessus de l’Internet. Le terme pair à pair, ou P2P, signifie que les ordinateurs qui participent au réseau sont des pairs les uns des autres, qu’ils sont tous égaux, qu’il n’y a pas de nœuds "spéciaux" et que tous les nœuds partagent la charge de fournir services réseau. Les nœuds du réseau s’interconnectent dans un réseau maillé avec une topologie "plate". Il n’y a pas de serveur, pas de service centralisé et pas de hiérarchie au sein du réseau. Les nœuds d’un réseau P2P fournissent et consomment des services en même temps, la réciprocité agissant comme une incitation à la participation. Les réseaux P2P sont intrinsèquement résilients, décentralisés et ouverts. Un exemple prééminent d’une architecture de réseau P2P était le début d’Internet lui-même, où les nœuds du réseau IP étaient égaux. L’architecture Internet d’aujourd’hui est plus hiérarchique, mais le protocole Internet conserve toujours son essence de topologie plate. Au-delà du bitcoin, l’application la plus importante et la plus réussie des technologies P2P est le partage de fichiers, avec Napster comme pionnier et BitTorrent comme l’évolution la plus récente de l’architecture.

L’architecture du réseau P2P de Bitcoin est bien plus qu’un choix de topologie. Bitcoin est un système de paiement numérique P2P de par sa conception, et l’architecture du réseau est à la fois le reflet et le fondement de cette caractéristique essentielle. La décentralisation du contrôle est un principe de conception de base qui ne peut être atteint et maintenu que par un réseau consensuel P2P plat et décentralisé.

Le terme "réseau Bitcoin" fait référence à l’ensemble de nœuds exécutant le protocole bitcoin P2P. En plus du protocole bitcoin P2P, il existe d’autres protocoles tels que Stratum qui sont utilisés pour le minage et les portefeuilles légers ou mobiles. Ces protocoles supplémentaires sont fournis par des serveurs de routage de passerelle qui accèdent au réseau Bitcoin à l’aide du protocole bitcoin P2P, puis étendent ce réseau aux nœuds exécutant d’autres protocoles. Par exemple, les serveurs Stratum connectent les nœuds de minage Stratum via le protocole Stratum au réseau Bitcoin principal et relient le protocole Stratum au protocole bitcoin P2P. Nous utilisons le terme « réseau Bitcoin étendu » pour désigner le réseau global qui comprend le protocole Bitcoin P2P, les protocoles de minage de groupe, le protocole Stratum et tout autre protocole connexe reliant les composants du système Bitcoin.

Bien que les nœuds dans le bitcoin Les réseaux P2P sont égaux, ils peuvent jouer différents rôles en fonction de la fonctionnalité qu’ils prennent en charge. Un nœud Bitcoin est un ensemble de fonctions : le routage, la base de données chaîne de blocs, le minage et les services de portefeuille. Un nœud complet avec ces quatre fonctions est affiché dans Un nœud de réseau Bitcoin avec les quatre fonctions : portefeuille, mineur, base de données chaîne de blocs complète et routage réseau.

Tous les nœuds incluent la fonction de routage pour participer au réseau et peuvent inclure d’autres fonctionnalités. Tous les nœuds valident et propagent les transactions et les blocs, et découvrent et maintiennent les connexions aux pairs. Dans l’exemple de nœud complet dans Un nœud de réseau Bitcoin avec les quatre fonctions : portefeuille, mineur, base de données chaîne de blocs complète et routage réseau, la fonction de routage est indiquée par un cercle nommé "Network Routing Node" ou par la lettre "N".

Certains nœuds, appelés nœuds complets, conservent également une copie complète et à jour de la chaîne de blocs. Les nœuds complets peuvent vérifier de manière autonome et autoritaire toute transaction sans référence externe. Certains nœuds ne conservent qu’un sous-ensemble de la chaîne de blocs et vérifient les transactions à l’aide d’une méthode appelée simplified-payment-verification, ou SPV. Ces nœuds sont appelés nœuds SPV ou nœuds légers. Dans l’exemple de nœud complet de la figure, la fonction de base de données chaîne de blocs de nœud complet est indiquée par un cercle appelé "Full Blockchain" ou la lettre "B". Dans Le réseau Bitcoin étendu montrant divers types de nœuds, passerelles et protocoles, les nœuds SPV sont dessinés sans le cercle "B", montrant qu’ils n’ont pas une copie complète de la chaîne de blocs.

Les nœuds de minage se font concurrence pour créer de nouveaux blocs en exécutant du matériel spécialisé pour résoudre l’algorithme de preuve de travail. Certains nœuds de minage sont également des nœuds complets, conservant une copie complète de la chaîne de blocs, tandis que d’autres sont des nœuds légers participant au minage de groupe et dépendant d’un serveur de groupe pour maintenir un nœud complet. La fonction d’exploration de données est affichée dans le nœud complet sous la forme d’un cercle appelé "Miner" ou de la lettre "M".

Les portefeuilles d’utilisateurs peuvent faire partie d’un nœud complet, comme c’est généralement le cas avec les clients Bitcoin de bureau. De plus en plus, de nombreux portefeuilles d’utilisateurs, en particulier ceux fonctionnant sur des appareils à ressources limitées tels que les smartphones, sont des nœuds SPV. La fonction de portefeuille est affichée dans Un nœud de réseau Bitcoin avec les quatre fonctions : portefeuille, mineur, base de données chaîne de blocs complète et routage réseau comme un cercle appelé "Wallet" ou la lettre "W."

En plus des principaux types de nœuds sur le protocole bitcoin P2P, il existe des serveurs et des nœuds exécutant d’autres protocoles, tels que des protocoles de groupe de minage spécialisés et des protocoles d’accès client légers.

Différents types de nœuds sur le réseau Bitcoin étendu montre les types de nœuds les plus courants sur le réseau Bitcoin étendu.

Le principal réseau Bitcoin, en cours d’exécution le protocole bitcoin P2P, se compose de 5 000 à 8 000 nœuds d’écoute exécutant différentes versions du client de référence bitcoin (Bitcoin Core) et de quelques centaines de nœuds exécutant diverses autres implémentations du protocole bitcoin P2P, telles que Bitcoin Classic, Bitcoin Unlimited, BitcoinJ, Libbitcoin, btcd et bcoin. Un petit pourcentage des nœuds du réseau bitcoin P2P sont également des nœuds de minage, en concurrence dans le processus de minage, en validant les transactions et en créant de nouveaux blocs. Diverses grandes entreprises s’interfacent avec le réseau Bitcoin en exécutant des clients à nœud complet basés sur le client Bitcoin Core, avec des copies complètes de la chaîne de blocs et un nœud de réseau, mais sans fonctions de minage ou de portefeuille. Ces nœuds agissent comme des routeurs de périphérie de réseau, permettant à divers autres services (échanges, portefeuilles, explorateurs de blocs, traitement des paiements marchands) d’être construits par-dessus.

Le réseau Bitcoin étendu comprend le réseau exécutant le protocole bitcoin P2P, décrit précédemment, ainsi que des nœuds exécutant des protocoles spécialisés. Un certain nombre de serveurs de groupe et de passerelles de protocole qui connectent des nœuds exécutant d’autres protocoles sont attachés au réseau principal bitcoin P2P. Ces autres nœuds de protocole sont principalement des nœuds de minage de groupe (voir Minage et Consensus) et les clients de portefeuille légers, qui ne portent pas une copie complète de la chaîne de blocs.

Le réseau Bitcoin étendu montrant divers types de nœuds, passerelles et protocoles montre le réseau Bitcoin étendu avec les différents types de nœuds, serveurs de passerelle, routeurs de périphérie et clients de portefeuille et les différents protocoles qu’ils utilisent pour se connecter les uns aux autres.

Alors que le réseau bitcoin P2P répond aux besoins généraux d’une grande variété de types de nœuds, il présente une latence de réseau trop élevée pour les besoins spécialisés des nœuds de minage de bitcoins.

Les mineurs de Bitcoin sont engagés dans une compétition urgente pour résoudre le problème de la preuve de travail et étendre la chaîne de blocs (voir Minage et Consensus). Tout en participant à cette compétition, les mineurs de bitcoins doivent minimiser le temps entre la propagation d’un bloc gagnant et le début du prochain tour de compétition. Dans le secteur minier, la latence du réseau est directement liée aux marges bénéficiaires.

Un Bitcoin Relay Network ou (réseau de relais Bitcoin) est un réseau qui tente de minimiser la latence dans la transmission des blocs entre les mineurs. Le https://www.bitcoinrelaynetwork.org [Bitcoin Relay Network] original a été créé par le développeur principal Matt Corallo en 2015 pour permettre une synchronisation rapide des blocs entre les mineurs avec une latence très faible. Le réseau se composait de plusieurs nœuds spécialisés hébergés sur l’infrastructure Amazon Web Services à travers le monde et servait à connecter la majorité des mineurs et des pools de minage.

Le réseau de relais Bitcoin d’origine a été remplacé en 2016 par l’introduction du Fast Internet Bitcoin Relay Engine ou https:/ /bitcoinfibre.org[FIBRE], également créé par le développeur principal Matt Corallo. FIBRE est un réseau de relais basé sur UDP qui relaie les blocs au sein d’un réseau de nœuds. FIBRE met en œuvre l’optimisation bloc compact pour réduire davantage la quantité de données transmises et la latence du réseau.

Les réseaux de relais ne remplacent pas le réseau P2P de Bitcoin. Au lieu de cela, ce sont des réseaux superposés qui fournissent une connectivité supplémentaire entre les nœuds ayant des besoins spécialisés. Comme les autoroutes ne remplacent pas les routes rurales, mais plutôt des raccourcis entre deux points à fort trafic, vous avez toujours besoin de petites routes pour vous connecter aux autoroutes.

Lorsqu’un nouveau nœud démarre, il doit découvrir d’autres nœuds Bitcoin sur le réseau afin de participer. Pour démarrer ce processus, un nouveau nœud doit découvrir au moins un nœud existant sur le réseau et s’y connecter. L’emplacement géographique des autres nœuds n’est pas pertinent ; la topologie du réseau Bitcoin n’est pas définie géographiquement. Par conséquent, tous les nœuds Bitcoin existants peuvent être sélectionnés au hasard.

Pour se connecter à un pair connu, les nœuds établissent une connexion TCP, généralement au port 8333 (le port généralement connu comme celui utilisé par bitcoin), ou un autre port s’il en existe un. Lors de l’établissement d’une connexion, le nœud commencera une "prise de contact" (voir La poignée de main initiale entre pairs) en transmettant un message version, qui contient des informations d’identification de base, notamment :

(Voir GitHub pour un exemple du message de version du réseau.)

Le message version est toujours le premier message envoyé par un pair à un autre pair. L’homologue local recevant un message version examinera la nVersion signalée par l’homologue distant et décidera si l’homologue distant est compatible. Si le pair distant est compatible, le pair local accusera réception du message version et établira une connexion en envoyant un message verack.

Comment un nouveau nœud trouve-t-il des pairs ? La première méthode consiste à interroger les DNS à l’aide d’un certain nombre de d'"indexes DNS", qui sont des serveurs DNS fournissant une liste d’adresses IP de nœuds Bitcoin. Certaines de ces indexes DNS fournissent une liste statique d’adresses IP de nœuds d’écoute bitcoin stables. Certaines des indexes DNS sont des implémentations personnalisées de BIND (Berkeley Internet Name Daemon) qui renvoient un sous-ensemble aléatoire à partir d’une liste d’adresses de nœuds Bitcoin collectées par un robot ou un nœud Bitcoin de longue durée. Le client Bitcoin Core contient les noms de neuf sources DNS différentes. La diversité de propriété et la diversité de mise en œuvre des différentes sources DNS offrent un haut niveau de fiabilité pour le processus d’amorçage initial. Dans le client Bitcoin Core, l’option d’utilisation des indexes DNS est contrôlée par le commutateur d’option -dnsseed (réglé sur 1 par défaut, pour utiliser la source DNS).

Alternativement, un nœud d’amorçage qui ne sait rien du réseau doit recevoir l’adresse IP d’au moins un nœud Bitcoin, après quoi il peut établir des connexions via d’autres introductions. L’argument de ligne de commande -seednode peut être utilisé pour se connecter à un nœud uniquement pour les introductions en l’utilisant comme source. Une fois que le nœud de départ initial a été utilisé pour former des présentations, le client s’en déconnecte et utilise les pairs nouvellement découverts.

Une fois qu’une ou plusieurs connexions sont établies, le nouveau nœud enverra un message addr contenant sa propre adresse IP à ses voisins. Les voisins transmettront à leur tour le message addr à leurs voisins, garantissant que le nœud nouvellement connecté devient bien connu et mieux connecté. De plus, le nœud nouvellement connecté peut envoyer getaddr aux voisins, leur demandant de renvoyer une liste d’adresses IP d’autres pairs. De cette façon, un nœud peut trouver des pairs auxquels se connecter et annoncer son existence sur le réseau pour que d’autres nœuds le trouvent. Propagation et découverte d’adresses montre le protocole de découverte d’adresse.

Un nœud doit se connecter à quelques pairs différents afin d’établir divers chemins dans le réseau Bitcoin. Les chemins ne sont pas persistants, les nœuds vont et viennent, et le nœud doit donc continuer à découvrir de nouveaux nœuds à mesure qu’il perd d’anciennes connexions et à aider les autres nœuds lors de leur démarrage. Une seule connexion est nécessaire pour démarrer, car le premier nœud peut proposer des introductions à ses nœuds pairs et ces pairs peuvent proposer d’autres introductions. Il est également inutile et gaspilleur de se connecter à plus d’une poignée de nœuds. Après le démarrage, un nœud se souviendra de ses dernières connexions homologues réussies, de sorte que s’il est redémarré, il peut rapidement rétablir les connexions avec son ancien réseau homologue. Si aucun des anciens pairs ne répond à sa demande de connexion, le nœud peut utiliser les nœuds de départ pour redémarrer.

Sur un nœud exécutant le client Bitcoin Core, vous pouvez lister les connexions homologues avec la commande getpeerinfo :

Pour outrepasser la gestion automatique des pairs et spécifier une liste d’adresses IP, les utilisateurs peuvent fournir l’option -connect=<IPAddress> et spécifiez une ou plusieurs adresses IP. Si cette option est utilisée, le nœud se connectera uniquement aux adresses IP sélectionnées, au lieu de découvrir et de maintenir automatiquement les connexions homologues.

S’il n’y a pas de trafic sur une connexion, les nœuds enverront périodiquement un message pour maintenir la connexion. Si un nœud n’a pas communiqué sur une connexion pendant plus de 90 minutes, il est supposé être déconnecté et un nouveau pair sera recherché. Ainsi, le réseau s’adapte dynamiquement aux nœuds transitoires et aux problèmes de réseau, et peut croître et rétrécir de manière organique selon les besoins sans aucun contrôle central.

Les nœuds complets sont des nœuds qui maintiennent une chaîne de blocs complète avec toutes les transactions. Plus précisément, ils devraient probablement être appelés "nœuds de chaîne de blocs complets". Dans les premières années de bitcoin, tous les nœuds étaient des nœuds complets et actuellement, le client Bitcoin Core est un nœud de chaîne de blocs complet. Au cours des deux dernières années, cependant, de nouvelles formes de clients Bitcoin ont été introduites qui ne maintiennent pas une chaîne de blocs complète mais fonctionnent comme des clients légers. Nous les examinerons plus en détail dans la section suivante.

Les nœuds de chaîne de blocs complets maintiennent un copie à jour de la chaîne de blocs Bitcoin avec toutes les transactions, qu’ils construisent et vérifient indépendamment, en commençant par le tout premier bloc (bloc de genèse) et en remontant jusqu’au dernier bloc connu du réseau. Un nœud de chaîne de blocs complet peut vérifier de manière indépendante et autoritaire toute transaction sans recours à aucun autre nœud ou source d’informations. Le nœud de la chaîne de blocs complète s’appuie sur le réseau pour recevoir des mises à jour sur les nouveaux blocs de transactions, qu’il vérifie ensuite et intègre dans sa copie locale de la chaîne de blocs.

L’exécution d’un nœud de chaîne de blocs complet vous offre l’expérience bitcoin pure : une vérification indépendante de toutes les transactions sans avoir besoin de s’appuyer sur, ou de faire confiance, à d’autres systèmes. Il est facile de savoir si vous exécutez un nœud complet car il nécessite plus de cent gigaoctets de stockage persistant (espace disque) pour stocker la chaîne de blocs complète. Si vous avez besoin de beaucoup de disque et que la synchronisation avec le réseau prend deux à trois jours, vous exécutez un nœud complet. C’est le prix d’une indépendance totale et de la liberté vis-à-vis de l’autorité centrale.

Il existe quelques implémentations alternatives de clients Bitcoin à chaîne complète, construites à l’aide de différents langages de programmation et architectures logicielles. Cependant, l’implémentation la plus courante est le client de référence Bitcoin Core, également connu sous le nom de client Satoshi. Plus de 75 % des nœuds du réseau Bitcoin exécutent différentes versions de Bitcoin Core. Il est identifié comme « Satoshi » dans la chaîne de sous-version envoyée dans le message version et affiché par la commande getpeerinfo comme nous l’avons vu précédemment ; par exemple, /Satoshi:0.8.6/.

La première chose qu’un nœud complet fera une fois qu’il se connecte à des pairs est d’essayer de construire une chaîne de blocs complète. S’il s’agit d’un tout nouveau nœud et qu’il n’a aucune chaîne de blocs, il ne connaît qu’un seul bloc, le bloc de genèse, qui est intégré de manière statique dans le logiciel client. En commençant par le bloc #0 (le bloc de genèse), le nouveau nœud devra télécharger des centaines de milliers de blocs pour se synchroniser avec le réseau et rétablir la chaîne de blocs complète.

Le processus de synchronisation de la chaîne de blocs commence par le message version, car il contient BestHeight, l’hauteur actuelle d’un nœud (nombre de blocs) de la chaîne de blocs. Un nœud verra les messages version de ses pairs, saura combien de blocs ils ont chacun et pourra comparer avec le nombre de blocs qu’il a dans sa propre chaîne de blocs. Les nœuds appairés échangeront un message getblocks contenant le hachage (empreinte digitale) du bloc supérieur sur leur chaîne de blocs locale. L’un des pairs pourra identifier le résultat d’hachage reçu comme appartenant à un bloc qui n’est pas au sommet, mais appartient plutôt à un bloc plus ancien, en déduisant ainsi que sa propre chaîne de blocs locale est plus longue que celle de son pair.

Le pair qui a la chaîne de blocs la plus longue a plus de blocs que l’autre nœud et peut identifier les blocs dont l’autre nœud a besoin pour "rattraper son retard". Il identifiera les 500 premiers blocs à partager et transmettra leurs hachages à l’aide d’un message inv (inventaire). Le nœud manquant ces blocs les récupérera ensuite, en émettant une série de messages getdata demandant les données complètes du bloc et en identifiant les blocs demandés à l’aide des hachages du message inv.

Supposons, par exemple, qu’un nœud n’ait que le bloc de genèse. Il recevra alors un message inv de ses pairs contenant les hachages des 500 prochains blocs de la chaîne. Il commencera à demander des blocs à tous ses pairs connectés, répartissant la charge et s’assurant qu’il ne submerge aucun pair de demandes. Le nœud garde une trace du nombre de blocs "en transit" par connexion homologue, c’est-à-dire des blocs qu’il a demandés mais non reçus, en vérifiant qu’il ne dépasse pas une limite (MAX_BLOCKS_IN_TRANSIT_PER_PEER). De cette façon, s’il a besoin de beaucoup de blocs, il n’en demandera de nouveaux que lorsque les demandes précédentes seront satisfaites, permettant aux pairs de contrôler le rythme des mises à jour et de ne pas submerger le réseau. Au fur et à mesure que chaque bloc est reçu, il est ajouté à la chaîne de blocs, comme nous le verrons dans La chaîne de blocs (La blockchain). Au fur et à mesure que la chaîne de blocs locale se construit, davantage de blocs sont demandés et reçus, et le processus se poursuit jusqu’à ce que le nœud rattrape le reste du réseau.

Ce processus de comparaison de la chaîne de blocs locale avec les pairs et de récupération des blocs manquants se produit chaque fois qu’un nœud se déconnecte pendant une période donnée. Qu’un nœud soit hors ligne depuis quelques minutes et qu’il manque quelques blocs, ou un mois et qu’il manque quelques milliers de blocs, il commence par envoyer getblocks, reçoit une réponse inv et commence à télécharger les blocs manquants. Nœud synchronisant la chaîne de blocs en récupérant les blocs d’un pair affiche l’inventaire et le protocole de propagation des blocs.

Tous les nœuds n’ont pas la capacité de stocker la chaîne de blocs complète. De nombreux clients Bitcoin sont conçus pour fonctionner sur des appareils à espace et puissance limités, tels que les smartphones, les tablettes ou les systèmes embarqués. Pour ces appareils, une méthode de vérification de paiement simplifiée (SPV) est utilisée pour leur permettre de fonctionner sans stocker la chaîne de blocs complète. Ces types de clients sont appelés clients SPV ou clients légers. À mesure que l’adoption du bitcoin augmente, le nœud SPV devient la forme la plus courante de nœud Bitcoin, en particulier pour les portefeuilles bitcoin.

Les nœuds SPV téléchargent uniquement les en-têtes de bloc et ne téléchargent pas les transactions incluses dans chaque bloc. La chaîne de blocs qui en résulte, sans transactions, est 1 000 fois plus petite que la chaîne de blocs complète. Les nœuds SPV ne peuvent pas construire une image complète de tous les UTXO disponibles pour les dépenses car ils ne connaissent pas toutes les transactions sur le réseau. Les nœuds SPV vérifient les transactions en utilisant une méthode légèrement différente qui s’appuie sur des pairs pour fournir des vues partielles des parties pertinentes de la chaîne de blocs à la demande.

Par analogie, un nœud complet est comme un touriste dans une ville étrange, équipé d’une carte détaillée de chaque rue et de chaque adresse. En comparaison, un nœud SPV est comme un touriste dans une ville étrange demandant à des inconnus au hasard des indications détaillées tout en ne connaissant qu’une seule avenue principale. Bien que les deux touristes puissent vérifier l’existence d’une rue en la visitant, le touriste sans carte ne sait pas ce qui se trouve dans les rues latérales et ne sait pas quelles autres rues existent. Positionné en face du 23 Church Street, le touriste sans carte ne peut pas savoir s’il existe une dizaine d’autres adresses « 23 Church Street » dans la ville et si celle-ci est la bonne. La meilleure chance pour le touriste sans carte est de demander à suffisamment de gens et d’espérer que certains d’entre eux n’essaient pas de l’agresser.

SPV vérifie les transactions en se référant à leur profondeur dans la chaîne de blocs au lieu de leur hauteur. Alors qu’un nœud de chaîne de blocs complet construira une chaîne entièrement vérifiée de milliers de blocs et de transactions descendant dans la chaîne de blocs (remontant dans le temps) jusqu’au bloc de genèse, un nœud SPV vérifiera la chaîne de tous les blocs (mais pas toutes les transactions) et lier cette chaîne à la transaction d’intérêt.

Par exemple, lors de l’examen d’une transaction dans le bloc 300 000, un nœud complet relie les 300 000 blocs au bloc de genèse et crée une base de données complète d’UTXO, établissant la validité de la transaction en confirmant que l’UTXO reste non dépensé. Un nœud SPV ne peut pas valider si l’UTXO n’est pas dépensé. Au lieu de cela, le nœud SPV établira un lien entre la transaction et le bloc qui la contient, en utilisant un chemin de Merkle (voir Arbres de Merkle). Ensuite, le nœud SPV attend de voir les six blocs 300 001 à 300 006 empilés au-dessus du bloc contenant la transaction et le vérifie en établissant sa profondeur sous les blocs 300 006 à 300 001. Le fait que d’autres nœuds du réseau aient accepté le bloc 300 000 et aient ensuite effectué le travail nécessaire pour produire six autres blocs en plus est la preuve, par procuration, que la transaction n’était pas une double dépense.

Un nœud SPV ne peut pas être persuadé qu’une transaction existe dans un bloc alors que la transaction n’existe pas en fait. Le nœud SPV établit l’existence d’une transaction dans un bloc en demandant une preuve de chemin Merkle et en validant la preuve de travail dans la chaîne de blocs. Cependant, l’existence d’une transaction peut être "masquée" à un nœud SPV. Un nœud SPV peut certainement prouver qu’une transaction existe mais ne peut pas vérifier qu’une transaction, telle qu’une double dépense du même UTXO, n’existe pas car il n’a pas d’enregistrement de toutes les transactions. Cette vulnérabilité peut être utilisée dans une attaque par déni de service ou pour une attaque à double dépense contre les nœuds SPV. Pour se défendre contre cela, un nœud SPV doit se connecter de manière aléatoire à plusieurs nœuds, pour augmenter la probabilité qu’il soit en contact avec au moins un nœud honnête. Ce besoin de se connecter de manière aléatoire signifie que les nœuds SPV sont également vulnérables aux attaques de partitionnement de réseau ou aux attaques Sybil, où ils sont connectés à de faux nœuds ou à de faux réseaux et n’ont pas accès à des nœuds honnêtes ou au vrai réseau Bitcoin.

Dans la plupart des cas pratiques, les nœuds SPV bien connectés sont suffisamment sécurisés, trouvant un équilibre entre les besoins en ressources, l’aspect pratique et la sécurité. Pour une sécurité infaillible, cependant, rien ne vaut l’exécution d’un nœud de chaîne de blocs complet.

Pour obtenir les en-têtes de bloc, les nœuds SPV utilisent un message getheaders au lieu de getblocks. L’homologue qui répond enverra jusqu’à 2 000 en-têtes de bloc à l’aide d’un seul message headers. Le processus est par ailleurs le même que celui utilisé par un nœud complet pour récupérer des blocs complets. Les nœuds SPV définissent également un filtre sur la connexion aux pairs, pour filtrer le flux des futurs blocs et transactions envoyés par les pairs. Toutes les transactions intéressantes sont récupérées à l’aide d’une requête getdata. Le pair génère un message tx contenant les transactions, en réponse. Nœud SPV synchronisant les en-têtes de bloc montre la synchronisation des en-têtes de bloc.

Étant donné que les nœuds SPV doivent récupérer des transactions spécifiques afin de les vérifier de manière sélective, ils créent également un risque pour la confidentialité. Contrairement aux nœuds de chaîne de blocs complets, qui collectent toutes les transactions au sein de chaque bloc, les demandes de données spécifiques du nœud SPV peuvent révéler par inadvertance les adresses de leur portefeuille. Par exemple, un tiers surveillant un réseau pourrait suivre toutes les transactions demandées par un portefeuille sur un nœud SPV et les utiliser pour associer des adresses Bitcoin à l’utilisateur de ce portefeuille, détruisant ainsi la vie privée de l’utilisateur.

Peu de temps après l’introduction des nœuds SPV/légers, les développeurs de bitcoins ont ajouté une fonctionnalité appelée filtres de Bloom pour faire face aux risques de confidentialité des nœuds SPV. Les filtres de Bloom permettent aux nœuds SPV de recevoir un sous-ensemble des transactions sans révéler précisément les adresses qui les intéressent, grâce à un mécanisme de filtrage qui utilise des probabilités plutôt que des modèles fixes.

Un filtre de Bloom est un filtre de recherche probabiliste qui offre un moyen efficace d’exprimer un modèle de recherche tout en protégeant la confidentialité. Ils sont utilisés par les nœuds SPV pour demander à leurs pairs des transactions correspondant à un modèle spécifique, sans révéler exactement quelles adresses, clés ou transactions ils recherchent.

Dans notre analogie précédente, un touriste sans carte demande son chemin vers une adresse spécifique, "23 Church St." Si elle demande à des inconnus son chemin vers cette rue, elle révèle par inadvertance sa destination. Un filtre de Bloom revient à demander : "Y a-t-il des rues dans ce quartier dont le nom se termine par RCH ?" Une question comme celle-là en dit un peu moins sur la destination souhaitée que de demander "23 Church St." En utilisant cette technique, un touriste pourrait spécifier l’adresse souhaitée plus en détail comme "se terminant par URCH" ou moins en détail comme "se terminant par H". En faisant varier la précision de la recherche, le touriste révèle plus ou moins d’informations, au détriment d’obtenir des résultats plus ou moins précis. Si elle demande un modèle moins spécifique, elle obtient beaucoup plus d’adresses possibles et une meilleure confidentialité, mais de nombreux résultats ne sont pas pertinents. Si elle demande un modèle très spécifique, elle obtient moins de résultats mais perd sa confidentialité.

Les filtres de Bloom remplissent cette fonction en permettant à un nœud SPV de spécifier un modèle de recherche pour les transactions qui peuvent être réglés vers la précision ou la confidentialité. Un filtre de Bloom plus spécifique produira des résultats précis, mais au détriment de la révélation des modèles qui intéressent le nœud SPV, révélant ainsi les adresses détenues par le portefeuille de l’utilisateur. Un filtre bloom moins spécifique produira plus de données sur plus de transactions, dont beaucoup ne sont pas pertinentes pour le nœud, mais permettra au nœud de maintenir une meilleure confidentialité.

Les filtres de Bloom sont utilisés pour filtrer les transactions (et les blocs les contenant) qu’un nœud SPV reçoit de ses pairs, en sélectionnant uniquement les transactions qui intéressent le nœud SPV sans révéler les adresses ou les clés qui l’intéressent.

Un nœud SPV initialisera un filtre de Bloom comme "vide" ; dans cet état, le filtre de Bloom ne correspondra à aucun motif. Le nœud SPV établira ensuite une liste de toutes les adresses, clés et hachages qui l’intéressent. Il le fera en extrayant le hachage de clé publique et le hachage de script et les ID de transaction de tout UTXO contrôlé par son portefeuille. Le nœud SPV ajoute ensuite chacun d’entre eux au filtre de Bloom, de sorte que le filtre de Bloom "correspondra" si ces modèles sont présents dans une transaction, sans révéler les modèles eux-mêmes.

Le nœud SPV enverra alors un message filterload au pair, contenant le filtres de Bloom à utiliser sur la connexion. Sur le pair, les filtres de Bloom sont vérifiés par rapport à chaque transaction entrante. Le nœud complet vérifie plusieurs parties de la transaction par rapport au filtre de Bloom, à la recherche d’une correspondance, notamment :

En comparant tous ces composants, les filtres Bloom peuvent être utilisés pour faire correspondre les hachages de clés publiques, les scripts, les valeurs OP_RETURN, les clés publiques dans les signatures ou tout futur composant d’un contrat intelligent ou d’un script complexe.

Une fois qu’un filtre est établi, le pair teste ensuite la sortie de chaque transaction par rapport au filtre Bloom. Seules les transactions qui correspondent au filtre sont envoyées au nœud.

En réponse à un message getdata du nœud, les pairs enverront un message merkleblock qui ne contient que des en-têtes de bloc pour les blocs correspondant au filtre et un chemin Merkle (voir Arbres de Merkle) pour chaque transaction correspondante. Le pair enverra alors également des messages tx contenant les transactions mises en correspondance par le filtre.

Lorsque le nœud complet envoie des transactions au nœud SPV, le nœud SPV rejette tous les faux positifs et utilise les transactions correctement appariées pour mettre à jour son ensemble UTXO et le solde de son portefeuille. Au fur et à mesure qu’il met à jour sa propre vue de l’ensemble UTXO, il modifie également le filtre de Bloom pour correspondre à toutes les transactions futures faisant référence à l’UTXO qu’il vient de trouver. Le nœud complet utilise ensuite le nouveau filtre de Bloom pour faire correspondre les nouvelles transactions et l’ensemble du processus se répète.

Le nœud définissant le filtre de Bloom peut ajouter de manière interactive des motifs au filtre en envoyant un message filteradd. Pour effacer le filtre de Bloom, le nœud peut envoyer un message filterclear. Puisqu’il n’est pas possible de supprimer un modèle d’un filtre de Bloom, un nœud doit effacer et renvoyer un nouveau filtre de Bloom si un modèle n’est plus souhaité.

Le protocole réseau et le mécanisme de filtre de Bloom pour les nœuds SPV sont définis dans BIP-37 (Peer Services).

Les nœuds qui implémentent SPV ont une confidentialité plus faible qu’un nœud complet. Un nœud complet reçoit toutes les transactions et ne révèle donc aucune information indiquant s’il utilise une adresse dans son portefeuille. Un nœud SPV reçoit une liste filtrée des transactions liées aux adresses qui se trouvent dans son portefeuille. En conséquence, cela réduit la vie privée du propriétaire.

Les filtres de Bloom sont un moyen de réduire la perte de confidentialité. Sans eux, un nœud SPV devrait répertorier explicitement les adresses qui l’intéressent, créant ainsi une grave violation de la vie privée. Cependant, même avec des filtres de Bloom, un adversaire surveillant le trafic d’un client SPV ou s’y connectant directement en tant que nœud du réseau P2P peut collecter suffisamment d’informations au fil du temps pour apprendre les adresses dans le portefeuille du client SPV.

La plupart des nouveaux utilisateurs de bitcoin supposent que les communications réseau d’un nœud Bitcoin sont cryptées. En fait, la mise en œuvre originale du bitcoin communique entièrement en clair. Bien que ce ne soit pas un problème majeur de confidentialité pour les nœuds complets, c’est un gros problème pour les nœuds SPV.

Afin d’augmenter la confidentialité et la sécurité du réseau bitcoin P2P, il existe deux solutions qui fournissent le cryptage des communications : Tor Transport et P2P Authentication and Encryption avec BIP-150/151.

Presque tous les nœuds du réseau Bitcoin maintiennent une liste temporaire de transactions non confirmées appelées bassin de mémoire, mempool ou bassin de transaction. Les nœuds utilisent ce bassin pour suivre les transactions connues du réseau mais qui ne sont pas encore incluses dans la chaîne de blocs. Par exemple, un nœud de portefeuille utilisera le bassin de transactions pour suivre les paiements entrants dans le portefeuille de l’utilisateur qui ont été reçus sur le réseau mais qui n’ont pas encore été confirmés.

Au fur et à mesure que les transactions sont reçues et vérifiées, elles sont ajoutées au bassin de transactions et relayées aux nœuds voisins pour se propager sur le réseau.

Certaines implémentations de nœuds maintiennent également un bassin séparé de transactions orphelines. Si les entrées d’une transaction font référence à une transaction qui n’est pas encore connue, comme un parent manquant, la transaction orpheline sera stockée temporairement dans le bassin orphelin jusqu’à ce que la transaction parent arrive.

Lorsqu’une transaction est ajoutée au bassin de transactions, le bassin orphelin est vérifié pour tous les orphelins qui référencent les sorties de cette transaction (ses enfants). Tous les orphelins correspondants sont ensuite validés. S’ils sont valides, ils sont supprimés du bassin orphelin et ajoutés au bassin de transactions, complétant ainsi la chaîne qui a commencé avec la transaction parent. À la lumière de la transaction nouvellement ajoutée, qui n’est plus orpheline, le processus est répété de manière récursive à la recherche de tout autre descendant, jusqu’à ce qu’aucun autre descendant ne soit trouvé. Grâce à ce processus, l’arrivée d’une transaction parente déclenche une reconstruction en cascade de toute une chaîne de transactions interdépendantes en réunissant les orphelins avec leurs parents tout au long de la chaîne.

Le bassin de transactions et le bassin orphelin (le cas échéant) sont stockés dans la mémoire locale et ne sont pas enregistrés sur le stockage persistant ; ils sont plutôt renseignés dynamiquement à partir des messages réseau entrants. Lorsqu’un nœud démarre, les deux bassins sont vides et se remplissent progressivement avec les nouvelles transactions reçues sur le réseau.

Certaines implémentations du client Bitcoin maintiennent également une base de données ou un bassin UTXO, qui est l’ensemble de toutes les sorties non dépensées sur la chaîne de blocs. Les utilisateurs de Bitcoin Core le trouveront dans le dossier chainstate/ du répertoire de données de leur client. Bien que le nom "bassin UTXO" ressemble au bassin de transactions, il représente un ensemble de données différent. Contrairement aux bassins de transactions et orphelins, le bassin UTXO n’est pas initialisé vide mais contient à la place des millions d’entrées de sorties de transactions non dépensées, tout ce qui n’est pas dépensé depuis le bloc de genèse. Le bassin UTXO peut être hébergé dans la mémoire locale ou sous la forme d’une table de base de données indexée sur un stockage persistant.

Alors que les bassins de transactions et orphelins représentent la perspective locale d’un seul nœud et peuvent varier considérablement d’un nœud à l’autre en fonction du moment où le nœud a été démarré ou redémarré, le bassin UTXO représente le consensus émergent du réseau et variera donc peu entre les nœuds. De plus, les bassins de transactions et orphelins ne contiennent que des transactions non confirmées, tandis que le pool UTXO ne contient que des sorties confirmées.

La structure de données de la chaîne de blocs est une liste ordonnée et rétro-liée aux blocs de transactions. La chaîne de blocs peut être stockée sous forme de fichier plat ou dans une simple base de données. Le client Bitcoin Core stocke les métadonnées de la chaîne de blocs à l’aide de la base de données LevelDB de Google. Les blocs sont "rétro-liés", chacun se référant au bloc précédent dans la chaîne. La chaîne de blocs est souvent visualisée comme une pile verticale, avec des blocs superposés les uns sur les autres et le premier bloc servant de base à la pile. La visualisation de blocs empilés les uns sur les autres entraîne l’utilisation de termes tels que "hauteur" pour désigner la distance par rapport au premier bloc, et "sommet" ou "pointe" pour désigner le bloc le plus récemment ajouté.

Chaque bloc de la chaîne de blocs est identifié par un hachage, généré à l’aide de l’algorithme de hachage cryptographique SHA256 sur l’en-tête du bloc. Chaque bloc fait également référence à un bloc précédent, connu sous le nom de bloc parent, via le champ "hachage de bloc précédent" dans l’en-tête de bloc. En d’autres termes, chaque bloc contient le hachage de son parent dans sa propre en-tête. La séquence de hachages reliant chaque bloc à son parent crée une chaîne remontant jusqu’au premier bloc jamais créé, connu sous le nom de bloc de genèse.

Bien qu’un bloc n’ait qu’un seul parent, il peut temporairement avoir plusieurs enfants. Chacun des enfants fait référence au même bloc que son parent et contient le même hachage (parent) dans le champ "hachage du bloc précédent". Plusieurs enfants apparaissent lors d’une "fourche" de chaîne de blocs, une situation temporaire qui se produit lorsque différents blocs sont découverts presque simultanément par différents mineurs (voir Fourches de chaîne de blocs). Finalement, un seul bloc enfant devient une partie de la chaîne de blocs et la "fourche" est résolu. Même si un bloc peut avoir plusieurs enfants, chaque bloc ne peut avoir qu’un seul parent. En effet, un bloc a un seul champ "hachage de bloc précédent" faisant référence à son parent unique.

Le champ "hachage du bloc précédent" se trouve à l’intérieur de l’en-tête du bloc et affecte ainsi le hachage du bloc courant. La propre identité de l’enfant change si l’identité du parent change. Lorsque le parent est modifié de quelque manière que ce soit, le hachage du parent change. Le hachage modifié du parent nécessite une modification du pointeur "hachage de bloc précédent" de l’enfant. Cela entraîne à son tour la modification du hachage de l’enfant, ce qui nécessite une modification du pointeur du petit-enfant, qui à son tour modifie le petit-enfant, et ainsi de suite. Cet effet de cascade garantit qu’une fois qu’un bloc est suivi de plusieurs générations, il ne peut pas être modifié sans forcer un recalcul de tous les blocs suivants. Parce qu’un tel recalcul nécessiterait un calcul énorme (et donc une consommation d’énergie), l’existence d’une longue chaîne de blocs rend immuable l’historique profond de la chaîne de blocs, ce qui est une caractéristique clé de la sécurité du bitcoin.

Une façon de penser à la chaîne de blocs est comme des couches dans une formation géologique ou un échantillon de carotte de glacier. Les couches de surface peuvent changer avec les saisons, voire être soufflées avant d’avoir le temps de s’installer. Mais dès que l’on descend à quelques centimètres de profondeur, les couches géologiques deviennent de plus en plus stables. Au moment où vous regardez quelques centaines de mètres plus bas, vous regardez un instantané du passé qui est resté intact pendant des millions d’années. Dans la chaîne de blocs, les quelques blocs les plus récents peuvent être révisés s’il y a un recalcul en chaîne dû à une fourche. Les six premiers blocs sont comme quelques centimètres de terre arable. Mais une fois que vous allez plus profondément dans la chaîne de blocs, au-delà de six blocs, les blocs sont de moins en moins susceptibles de changer. Après 100 blocs de retour, il y a tellement de stabilité que la transaction coinbase - la transaction contenant le bitcoin nouvellement extrait - peut être dépensée. Quelques milliers de blocs en arrière (un mois) et la chaîne de blocs est une histoire établie, à toutes fins pratiques. Alors que le protocole permet toujours à une chaîne d’être annulée par une chaîne plus longue et alors que la possibilité qu’un bloc soit inversé existe toujours, la probabilité d’un tel événement diminue au fil du temps jusqu’à ce qu’elle devienne infinitésimale.

Un bloc est une structure de données de conteneur qui agrège les transactions pour les inclure dans le grand livre public, la chaîne de blocs. Le bloc est composé d’un en-tête, contenant des métadonnées, suivi d’une longue liste de transactions qui constituent l’essentiel de sa taille. L’en-tête de bloc est de 80 octets, alors que la transaction moyenne est d’au moins 400 octets et que le bloc moyen contient plus de 1900 transactions. Un bloc complet, avec toutes les transactions, est donc 10 000 fois plus grand que l’en-tête du bloc. La structure d’un bloc décrit la structure d’un bloc.

L’en-tête de bloc se compose de trois ensembles de métadonnées de bloc. Tout d’abord, il y a une référence à un hachage de bloc précédent, qui connecte ce bloc au bloc précédent dans la chaîne de blocs. Le deuxième ensemble de métadonnées, à savoir difficulty, timestamp et nonce, concerne la concurrence minière, comme détaillé dans Minage et Consensus. La troisième métadonnée est la racine de l’arbre Merkle, une structure de données utilisée pour résumer efficacement toutes les transactions du bloc. La structure de l’entête du bloc décrit la structure d’un en-tête de bloc.

Le nonce, la cible de difficulté et l’horodatage sont utilisés dans le processus d’extraction et seront discutés plus en détail dans Minage et Consensus.

L’identifiant primaire d’un bloc est son hachage cryptographique, une empreinte digitale, réalisée en hachant deux fois l’en-tête du bloc via l’algorithme SHA256. Le hachage de 32 octets résultant est appelé hachage de bloc mais est plus précisément le hachage d’en-tête de bloc, car seul l'en-tête de bloc est utilisé pour le calculer. Par exemple, 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f est le hachage de bloc du premier bloc bitcoin jamais créé. Le hachage de bloc identifie un bloc de manière unique et sans ambiguïté et peut être dérivé indépendamment par n’importe quel nœud en double hachant simplement l’en-tête de bloc avec l’algorithme SHA256.

Notez que le hachage de bloc n’est pas réellement inclus dans la structure de données du bloc, ni lorsque le bloc est transmis sur le réseau, ni lorsqu’il est stocké sur le stockage de persistance d’un nœud dans le cadre de la chaîne de blocs. Au lieu de cela, le hachage du bloc est calculé par chaque nœud lorsque le bloc est reçu du réseau. Le hachage de bloc peut être stocké dans une table de base de données distincte dans le cadre des métadonnées du bloc, pour faciliter l’indexation et une récupération plus rapide des blocs à partir du disque.

Une deuxième façon d’identifier un bloc est par sa position dans la chaîne de blocs, appelée le hauteur de bloc. Le premier bloc jamais créé est à la hauteur de bloc 0 (zéro) et est le même bloc qui était précédemment référencé par le hachage de bloc suivant 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f. Un bloc peut ainsi être identifié de deux manières : en référençant le hachage du bloc ou en référençant la hauteur du bloc. Chaque bloc suivant ajouté "au-dessus" de ce premier bloc est une position "plus élevée" dans la chaîne de blocs, comme des boîtes empilées les unes sur les autres.

De plus, le terme hauteur de bloc actuelle indique la taille de la chaîne de blocs en blocs à un moment donné. Par exemple, la hauteur actuelle du bloc au 1er mars 2021 était d’environ 672 722, ce qui signifie qu’il y avait 672 722 blocs empilés au-dessus du premier bloc créé en janvier 2009.

Contrairement au hachage de bloc, la hauteur de bloc n’est pas un identifiant unique. Bien qu’un seul bloc ait toujours une hauteur de bloc spécifique et invariante, l’inverse n’est pas vrai : la hauteur de bloc n’identifie pas toujours un seul bloc. Deux ou plusieurs blocs peuvent avoir la même hauteur de bloc, en concurrence pour la même position dans la chaîne de blocs. Ce scénario est décrit en détail dans la section Fourches de chaîne de blocs. La hauteur de bloc ne fait pas non plus partie de la structure de données du bloc ; il n’est pas stocké dans le bloc. Chaque nœud identifie dynamiquement la position (hauteur) d’un bloc dans la chaîne de blocs lorsqu’il est reçu du réseau Bitcoin. La hauteur de bloc peut également être stockée sous forme de métadonnées dans une table de base de données indexée pour une récupération plus rapide.

Le premier bloc de la chaîne de blocs est appelé le bloc d’origine (ou de genèse) et a été créé en 2009. Il est l’ancêtre commun de tous les blocs de la chaîne de blocs, ce qui signifie que si vous commencez à n’importe quel bloc et suivez la chaîne en arrière dans le temps, vous finirez par arriver au bloc de genèse.

Chaque nœud commence toujours par une chaîne de blocs d’au moins un bloc car le bloc de genèse est encodé de manière statique dans le logiciel client Bitcoin, de sorte qu’il ne peut pas être modifié. Chaque nœud "connaît" toujours le hachage et la structure du bloc de genèse, l’heure fixe à laquelle il a été créé et même la transaction unique qu’il contient. Ainsi, chaque nœud a le point de départ de la chaîne de blocs, une "racine" sécurisée à partir de laquelle construire une chaîne de blocs de confiance.

Voir le bloc de genèse encodé statiquement à l’intérieur du client Bitcoin Core, dans chainparams.cpp.

Le hachage d’identifiant suivant appartient au bloc genesis :

Vous pouvez rechercher ce hachage de bloc sur n’importe quel site web d’explorateur de blocs, tel que Blockchain.com, et vous trouverez une page décrivant le contenu de ce bloc, avec une URL contenant ce hachage :

https://www.blockchain.com/btc/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

Utilisation du client de référence Bitcoin Core sur la ligne de commande :

Le bloc de genèse contient un message caché en son sein. L’entrée de transaction coinbase contient le texte "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.". Ce message était destiné à offrir une preuve de la date la plus ancienne de création de ce bloc, en faisant référence au titre du journal britannique The Times. Il sert également de rappel ironique de l’importance d’un système monétaire indépendant, le lancement du bitcoin se produisant en même temps qu’une crise monétaire mondiale sans précédent. Le message a été intégré dans le premier bloc par Satoshi Nakamoto, le créateur de Bitcoin.

Les nœuds complets Bitcoin conservent une copie locale de la chaîne de blocs, à partir du bloc de genèse. La copie locale de la chaîne de blocs est constamment mise à jour au fur et à mesure que de nouveaux blocs sont trouvés et utilisés pour étendre la chaîne. Lorsqu’un nœud reçoit des blocs entrants du réseau, il validera ces blocs, puis les reliera à la chaîne de blocs existante. Pour établir un lien, un nœud examinera l’en-tête de bloc entrant et recherchera le "hachage de bloc précédent".

Supposons, par exemple, qu’un nœud ait 277 314 blocs dans la copie locale de la chaîne de blocs. Le dernier bloc dont le nœud a connaissance est le bloc 277 314, avec un hachage d’en-tête de bloc :

Le nœud Bitcoin reçoit alors un nouveau bloc du réseau, qu’il analyse comme suit :

En regardant ce nouveau bloc, le nœud trouve le champ previousblockhash, qui contient le hachage de son bloc parent. Il s’agit d’un hachage connu du nœud, celui du dernier bloc de la chaîne à la hauteur 277,314. Par conséquent, ce nouveau bloc est un enfant du dernier bloc de la chaîne et étend la chaîne de blocs existante. Le nœud ajoute ce nouveau bloc à la fin de la chaîne, rendant la chaîne de blocs plus longue avec une nouvelle hauteur de 277 315. Blocs liés dans une chaîne par référence au hachage d’en-tête de bloc précédent montre la chaîne de trois blocs, liés par des références dans le champ previousblockhash.

Chaque bloc de la chaîne de blocs Bitcoin contient un résumé de tous les transactions dans le bloc à l’aide d’un arbre de Merkle.

Un arbre de Merkle, également appelé arbre de hachage binaire, est une structure de données utilisée pour résumer et vérifier efficacement l’intégrité de grands ensembles de données. Les arbres de Merkle sont des arbres binaires contenant des hachages cryptographiques. Le terme "arbre" est utilisé en informatique pour décrire une structure de données ramifiée, mais ces arbres sont généralement affichés à l’envers avec la "racine" en haut et les "feuilles" en bas d’un diagramme, comme vous le verrez dans les exemples qui suivent.

Les arbres de Merkle sont utilisés dans Bitcoin pour résumer toutes les transactions d’un bloc, produisant une empreinte numérique globale de l’ensemble des transactions, fournissant un processus très efficace pour vérifier si une transaction est incluse dans un bloc. Un arbre Merkle est construit en hachant récursivement des paires de nœuds jusqu’à ce qu’il n’y ait qu’un seul hachage, appelé racine, ou racine de Merkle. L’algorithme de hachage cryptographique utilisé dans les arbres de Merkle de Bitcoin est SHA256 appliqué deux fois, également connu sous le nom de double-SHA256.

Lorsque N éléments de données sont hachés et résumés dans un arbre de Merkle, vous pouvez vérifier si un élément de données est inclus dans l’arbre avec au plus 2*log2(N) calculs, ce qui en fait une donnée très efficace structure.

L’arbre de Merkle est construit de bas en haut. Dans l’exemple suivant, nous commençons avec quatre transactions, A, B, C et D, qui forment les feuilles de l’arbre de Merkle, comme indiqué dans Calcul des nœuds dans un arbre de Merkle. Les transactions ne sont pas stockées dans l’arborescence de Merkle ; à la place, leurs données sont hachées et le hachage résultant est stocké dans chaque nœud feuille sous la forme H_A, H_B, H_C et H_D :

Des paires consécutives de nœuds feuilles sont ensuite résumées dans un nœud parent, en concaténant les deux hachages et en les hachant ensemble. Par exemple, pour construire le nœud parent H_AB, les deux hachages de 32 octets des enfants sont concaténés pour créer une chaîne de 64 octets. Cette chaîne est ensuite doublement hachée pour produire le hachage du nœud parent :

Le processus se poursuit jusqu’à ce qu’il n’y ait qu’un seul nœud au sommet, le nœud connu sous le nom de racine de Merkle. Ce hachage de 32 octets est stocké dans l’en-tête du bloc et résume toutes les données des quatre transactions. Calcul des nœuds dans un arbre de Merkle montre comment la racine est calculée par hachages par paires des nœuds.

Parce que l’arbre de Merkle est un arbre binaire, il a besoin d’un nombre pair de nœuds feuilles. S’il y a un nombre impair de transactions à résumer, le dernier hachage de transaction sera dupliqué pour créer un nombre pair de nœuds feuilles, également appelés arbre équilibré. Ceci est montré dans La duplication d’un élément de données permet d’obtenir un nombre pair d’éléments de données, où la transaction C est dupliquée.

La même méthode de construction d’un arbre à partir de quatre transactions peut être généralisée pour construire des arbres de n’importe quelle taille. Dans le Bitcoin, il est courant d’avoir plusieurs centaines à plus d’un millier de transactions dans un seul bloc, qui sont résumées exactement de la même manière, produisant seulement 32 octets de données en tant que racine de Merkle unique. Dans Un arbre Merkle résumant de nombreux éléments de données, vous verrez un arbre construit à partir de 16 transactions. Notez que bien que la racine semble plus grande que les nœuds feuilles dans le diagramme, elle a exactement la même taille, seulement 32 octets. Qu’il y ait une transaction ou cent mille transactions dans le bloc, la racine de Merkle les résume toujours en 32 octets.

Pour prouver qu’une transaction spécifique est incluse dans un bloc, un nœud n’a besoin que de produire log2(N) hachages de 32 octets, constituant un chemin d’authentification ou chemin de Merkle se connectant la transaction spécifique à la racine de l’arborescence. Ceci est particulièrement important lorsque le nombre de transactions augmente, car le logarithme en base 2 du nombre de transactions augmente beaucoup plus lentement. Cela permet aux nœuds Bitcoin de produire efficacement des chemins de 10 ou 12 hachages (320 à 384 octets), qui peuvent fournir la preuve d’une seule transaction parmi plus de mille transactions dans un bloc de la taille d’un mégaoctet.

Dans Un chemin (ou trajet) de Merkle utilisé pour prouver l’inclusion d’un élément de données, un nœud peut prouver qu’une transaction K est incluse dans le bloc en produisant un chemin de Merkle qui ne fait que quatre hachages de 32 octets (128 octets au total). Le chemin se compose des quatre hachages (affichés avec un arrière-plan ombré dans Un chemin (ou trajet) de Merkle utilisé pour prouver l’inclusion d’un élément de données) H_L, H_IJ, H_MNOP et H_ABCDEFGH. Avec ces quatre hachages fournis comme chemin d’authentification, n’importe quel nœud peut prouver que H_K (avec un fond noir au bas du diagramme) est inclus dans la racine de Merkle en calculant quatre hachages supplémentaires par paires H_KL, H_IJKL, H_IJKLMNOP et la racine de l’arbre de Merkle (indiquée par une ligne pointillée dans le diagramme).

Le code dans Construire un arbre de Merkle illustre le processus de création d’un arbre de Merkle depuis les hachages de nœud feuille jusqu’à la racine, en utilisant la bibliothèque libbitcoin pour certaines fonctions d’assistance.

Compilation et exécution de l’exemple de code de Merkle montre le résultat de la compilation et de l’exécution du code de Merkle.

L’efficacité des arbres de Merkle devient évidente à mesure que l’échelle augmente. Efficacité de l’arbre de Merkle montre la quantité de données qui doit être échangée sous forme de chemin de Merkle pour prouver qu’une transaction fait partie d’un bloc.

Comme vous pouvez le voir dans le tableau, alors que la taille de bloc augmente rapidement, de 4 Ko avec 16 transactions à une taille de bloc de 16 Mo pour 65 535 transactions, le chemin de Merkle requis pour prouver l’inclusion d’une transaction augmente beaucoup plus lentement, de 128 octets à seulement 512 octets. Avec les arbres de Merkle, un nœud peut télécharger uniquement les en-têtes de bloc (80 octets par bloc) et être toujours en mesure d’identifier l’inclusion d’une transaction dans un bloc en récupérant un petit chemin Merkle à partir d’un nœud complet, sans stocker ni transmettre la grande majorité des chaînes de blocs, qui peut avoir une taille de plusieurs gigaoctets. Les nœuds qui ne maintiennent pas une chaîne de blocs complète, appelés nœuds de vérification simplifiée des paiements (SPV), utilisent des chemins de Merkle pour vérifier les transactions sans télécharger des blocs complets.

Les arbres Merkle sont largement utilisés par les nœuds SPV. Les nœuds SPV n’ont pas toutes les transactions et ne téléchargent pas les blocs complets, juste les en-têtes de bloc. Afin de vérifier qu’une transaction est incluse dans un bloc, sans avoir à télécharger toutes les transactions du bloc, ils utilisent un chemin d’authentification, ou chemin de Merkle.

Considérons, par exemple, un nœud SPV qui est intéressé par les paiements entrants à une adresse contenue dans son portefeuille. Le nœud SPV établira un filtre de Bloom (voir Filtres de Bloom) sur ses connexions à des pairs pour limiter les transactions reçues uniquement à celles contenant des adresses d’intérêt. Lorsqu’un pair voit une transaction qui correspond au filtre de Bloom, il enverra ce bloc à l’aide d’un message merkleblock. Le message merkleblock contient l’en-tête du bloc ainsi qu’un chemin de Merkle qui relie la transaction d’intérêt à la racine de Merkle dans le bloc. Le nœud SPV peut utiliser ce chemin de Merkle pour connecter la transaction au bloc et vérifier que la transaction est incluse dans le bloc. Le nœud SPV utilise également l’en-tête de bloc pour lier le bloc au reste de la chaîne de blocs. La combinaison de ces deux liens, entre la transaction et le bloc, et entre le bloc et la chaîne de blocs, prouve que la transaction est enregistrée dans la chaîne de blocs. Au total, le nœud SPV aura reçu moins d’un kilo-octet de données pour l’en-tête de bloc et le chemin de Merkle, une quantité de données plus de mille fois inférieure à un bloc complet (environ 1 mégaoctet actuellement).

Vous pourriez être surpris d’apprendre qu’il existe plus d’une chaîne de blocs Bitcoin. La chaîne de blocs Bitcoin "principale", celle créée par Satoshi Nakamoto le 3 janvier 2009, celle avec le bloc de genèse que nous avons étudié dans ce chapitre, s’appelle mainnet. Il existe d’autres chaînes de blocs Bitcoin qui sont utilisées à des fins de test : actuellement testnet, segnet et regtest. Regardons chacun à son tour.

Les différentes chaînes de blocs de Bitcoin (regtest, segnet, testnet3, mainnet) offrent une gamme d’environnements de test pour le développement de bitcoin. Utilisez les chaînes de blocs de test, que vous développiez pour Bitcoin Core ou un autre client de consensus à nœud complet ; une application telle qu’un portefeuille, un échange, un site de commerce électronique ; ou même développer de nouveaux contrats intelligents et des scripts complexes.

Vous pouvez utiliser les chaînes de blocs de test pour établir un pipeline de développement. Testez votre code localement sur un regtest au fur et à mesure que vous le développez. Une fois que vous êtes prêt à l’essayer sur un réseau public, passez à testnet pour exposer votre code à un environnement plus dynamique avec plus de diversité de code et d’applications. Enfin, une fois que vous êtes sûr que votre code fonctionne comme prévu, passez à mainnet pour le déployer en production. Au fur et à mesure que vous apportez des modifications, des améliorations, des corrections de bogues, etc., redémarrez le pipeline, en déployant d’abord chaque modification sur regtest, puis sur testnet, et enfin en production.

Le mot "exploitation minière" ou "minage" est quelque peu trompeur. En évoquant l’extraction de métaux précieux, il focalise notre attention sur la récompense du minage, le nouveau bitcoin créé dans chaque bloc. Bien que l’exploitation minière soit incitée par cette récompense, l’objectif principal de l’exploitation minière n’est pas la récompense ou la génération de nouvelles pièces. Si vous considérez l’exploitation minière uniquement comme le processus par lequel les pièces sont créées, vous confondez les moyens (incitations) avec le but du processus. Le minage est le mécanisme qui sous-tend la chambre de compensation décentralisée, par laquelle les transactions sont validées et compensées. Le minage est l’invention qui rend le bitcoin spécial, un mécanisme de sécurité décentralisé qui est à la base de l’argent numérique P2P.

L’exploitation minière sécurise le système Bitcoin et permet l’émergence d’un consensus à l’échelle du réseau sans autorité centrale. La récompense des pièces nouvellement frappées et des frais de transaction est un système d’incitation qui aligne les actions des mineurs sur la sécurité du réseau, tout en mettant en œuvre simultanément l’offre monétaire.

Les mineurs valident les nouvelles transactions et les enregistrent dans le grand livre mondial. Un nouveau bloc, contenant les transactions qui se sont produites depuis le dernier bloc, est "miné" toutes les 10 minutes en moyenne, ajoutant ainsi ces transactions à la chaîne de blocs. Les transactions qui font partie d’un bloc et ajoutées à la chaîne de blocs sont considérées comme "confirmées", ce qui permet aux nouveaux propriétaires de bitcoin de dépenser le bitcoin qu’ils ont reçu dans ces transactions.

Les mineurs reçoivent deux types de récompenses en échange de la sécurité fournie par le minage : de nouvelles pièces créées avec chaque nouveau bloc, également appelées récompense de bloc ou récompense de coinbase, et les frais de transaction de toutes les transactions incluses dans le bloc. Pour gagner cette récompense, les mineurs s’affrontent pour résoudre un problème mathématique difficile basé sur un algorithme de hachage cryptographique. La solution au problème, appelée Proof-of-Work (ou preuve de travail), est incluse dans le nouveau bloc et agit comme preuve que le mineur a déployé des efforts informatiques importants. La compétition pour résoudre l’algorithme de preuve de travail pour gagner la récompense et le droit d’enregistrer les transactions sur la chaîne de blocs est la base du modèle de sécurité de Bitcoin.

Le processus est appelé minage parce que la récompense (nouvelle génération de pièces) est conçue pour simuler des rendements décroissants, tout comme le minage de métaux précieux. La masse monétaire de Bitcoin est créée par l’exploitation minière, de la même manière qu’une banque centrale émet de la nouvelle monnaie en imprimant des billets de banque. La quantité maximale de bitcoins nouvellement créés qu’un mineur peut ajouter à un bloc diminue environ tous les quatre ans (ou précisément tous les 210 000 blocs). Il a commencé à 50 bitcoins par bloc en janvier 2009 et a été réduit de moitié à 25 bitcoins par bloc en novembre 2012. Il a été réduit de moitié à 12,5 bitcoins en juillet 2016 et de nouveau à 6,25 bitcoins en mai 2020. Sur la base de cette formule, les récompenses de minage de bitcoins diminuent de façon exponentielle. jusqu’à environ l’an 2140, lorsque tous les bitcoins (20,99999998 millions) auront été émis. Après 2140, aucun nouveau bitcoin ne sera émis.

Les mineurs de Bitcoin gagnent également des frais sur les transactions. Chaque transaction comprend généralement des frais de transaction, sous la forme d’un surplus de bitcoin entre les entrées et les sorties de la transaction. Le mineur de bitcoin gagnant peut "garder la monnaie" sur les transactions incluses dans le bloc gagnant. Aujourd’hui, les frais représentent 0,5 % ou moins des revenus d’un mineur de bitcoin, la grande majorité provenant du bitcoin nouvellement créé. Cependant, à mesure que la récompense de bloc diminue avec le temps et que le nombre de transactions par bloc augmente, une plus grande proportion des revenus de minage de bitcoins proviendra des frais. Progressivement, la récompense minière sera dominée par les frais de transaction, qui constitueront la principale incitation pour les mineurs. Après 2140, la quantité de nouveaux bitcoins dans chaque bloc tombe à zéro et l’extraction de bitcoins ne sera encouragée que par les frais de transaction.

Dans ce chapitre, nous examinerons d’abord l’exploitation minière en tant que mécanisme d’approvisionnement monétaire, puis nous examinerons la fonction la plus importante de l’exploitation minière : le mécanisme de consensus décentralisé qui sous-tend la sécurité du bitcoin.

Pour comprendre l’exploitation minière et le consensus, nous suivrons la transaction d’Alice telle qu’elle est reçue et ajoutée à un bloc par l’équipement minier de Jing. Ensuite, nous suivrons le bloc tel qu’il est extrait, ajouté à la chaîne de blocs et accepté par le réseau Bitcoin à travers le processus de consensus émergent.

Dans le chapitre précédent, nous avons examiné la chaîne de blocs, le registre public mondial (liste) de tous transactions, que tout le monde dans le réseau Bitcoin accepte comme enregistrement de propriété faisant autorité.

Mais comment tout le monde dans le réseau peut-il s’entendre sur une seule « vérité » universelle sur qui possède quoi, sans avoir à faire confiance à personne ? Tous les systèmes de paiement traditionnels dépendent d’un modèle de confiance qui a une autorité centrale fournissant un service de chambre de compensation, vérifiant et compensant essentiellement toutes les transactions. Bitcoin n’a pas d’autorité centrale, mais d’une manière ou d’une autre, chaque nœud complet possède une copie complète d’un grand livre public auquel il peut faire confiance en tant qu’enregistrement faisant autorité. La chaîne de blocs n’est pas créée par une autorité centrale, mais est assemblée indépendamment par chaque nœud du réseau. D’une manière ou d’une autre, chaque nœud du réseau, agissant sur les informations transmises via des connexions réseau non sécurisées, peut arriver à la même conclusion et assembler une copie du même registre public que tout le monde. Ce chapitre examine le processus par lequel le réseau Bitcoin parvient à un consensus mondial sans autorité centrale.

La principale invention de Satoshi Nakamoto est le mécanisme décentralisé de consensus émergent. Emergent, parce que le consensus n’est pas atteint explicitement - il n’y a pas d’élection ou de moment fixe où le consensus se produit. Au lieu de cela, le consensus est un artefact émergent de l’interaction asynchrone de milliers de nœuds indépendants, qui suivent tous des règles simples. Toutes les propriétés du bitcoin, y compris la monnaie, les transactions, les paiements et le modèle de sécurité qui ne dépend pas de l’autorité centrale ou de la confiance, découlent de cette invention.

Le consensus décentralisé de Bitcoin émerge de l’interaction de quatre processus qui se produisent indépendamment sur les nœuds du réseau :

Dans les prochaines sections, nous examinerons ces processus et la manière dont ils interagissent pour créer la propriété émergente du consensus à l’échelle du réseau qui permet à n’importe quel nœud Bitcoin d’assembler sa propre copie du grand livre public mondial faisant autorité.

Dans Opérations, nous avons vu comment un logiciel de portefeuille crée des transactions en collectant des UTXO, en fournissant les scripts de déverrouillage appropriés, puis en construisant de nouvelles sorties attribuées à un nouveau propriétaire. La transaction résultante est ensuite envoyée aux nœuds voisins du réseau Bitcoin afin qu’elle puisse être propagée sur l’ensemble du réseau Bitcoin.

Cependant, avant de transmettre les transactions à ses voisins, chaque nœud Bitcoin qui reçoit une transaction vérifiera d’abord la transaction. Cela garantit que seules les transactions valides sont propagées sur le réseau, tandis que les transactions non valides sont rejetées au premier nœud qui les rencontre.

Chaque nœud vérifie chaque transaction par rapport à une longue liste de critères :

Ces conditions peuvent être vues en détail dans les fonctions AcceptToMemoryPool, CheckTransaction et CheckInputs dans Bitcoin Core. Notez que les conditions changent avec le temps, pour faire face à de nouveaux types d’attaques par déni de service ou parfois pour assouplir les règles afin d’inclure davantage de types de transactions.

En vérifiant indépendamment chaque transaction lors de sa réception et avant de la propager, chaque nœud crée un bassin de transactions valides (mais non confirmées) connu sous le nom de bassin de transaction, bassin de mémoire ou mempool.

Certains des nœuds du réseau Bitcoin sont des nœuds spécialisés appelés mineurs. Dans Présentation nous avons présenté Jing, un étudiant en génie informatique à Shanghai, en Chine, est un mineur de bitcoin. Jing gagne du bitcoin en exécutant une "plate-forme minière", qui est un système informatique spécialisé conçu pour exploiter le bitcoin. Le matériel minier spécialisé de Jing est connecté à un serveur exécutant un nœud Bitcoin complet. Contrairement à Jing, certains mineurs minent sans nœud complet, comme nous le verrons dans Groupes miniers. Comme tous les autres nœuds complets, le nœud de Jing reçoit et propage les transactions non confirmées sur le réseau Bitcoin. Le nœud de Jing, cependant, agrège également ces transactions dans de nouveaux blocs.

Le nœud de Jing est à l’écoute de nouveaux blocs, propagés sur le réseau Bitcoin, comme tous les nœuds. Cependant, l’arrivée d’un nouveau bloc a une signification particulière pour un nœud minier. La compétition entre mineurs se termine effectivement par la propagation d’un nouveau bloc qui fait office d’annonce d’un gagnant. Pour les mineurs, recevoir un nouveau bloc valide signifie que quelqu’un d’autre a gagné la compétition et qu’il (on) a perdu. Cependant, la fin d’un tour d’une compétition est aussi le début du tour suivant. Le nouveau bloc n’est pas seulement un drapeau à damier, marquant la fin de la course; c’est aussi le pistolet de départ dans la course pour le bloc suivant.

Après avoir validé les transactions, un nœud Bitcoin les ajoutera au bassin de mémoire, ou bassin de transaction, où les transactions attendent jusqu’à ce qu’elles puissent être incluses (exploitées) dans un bloc. Le nœud de Jing collecte, valide et relaie les nouvelles transactions comme n’importe quel autre nœud. Contrairement aux autres nœuds, cependant, le nœud de Jing regroupera ensuite ces transactions dans un bloc candidat.

Suivons les blocs qui ont été créés à l’époque où Alice achetait une tasse de café au Bob’s Cafe (voir Acheter une tasse de café). La transaction d’Alice a été incluse dans le bloc 277 316. Dans le but de démontrer les concepts de ce chapitre, supposons que ce bloc a été miné par le système de minage de Jing et suivons la transaction d’Alice au fur et à mesure qu’elle fait partie de ce nouveau bloc.

Le nœud minier de Jing maintient une copie locale de la chaîne de blocs. Au moment où Alice achète la tasse de café, le nœud de Jing a assemblé une chaîne jusqu’au bloc 277 314. Le nœud de Jing écoute les transactions, essaie d’extraire un nouveau bloc et écoute également les blocs découverts par d’autres nœuds. Comme le nœud de Jing est en train d’exploiter, il reçoit le bloc 277 315 via le réseau Bitcoin. L’arrivée de ce bloc signifie la fin de la compétition pour le bloc 277 315 et le début de la compétition pour créer le bloc 277 316.

Au cours des 10 minutes précédentes, alors que le nœud de Jing cherchait une solution au bloc 277 315, il collectait également des transactions en vue du bloc suivant. À ce jour, il a collecté quelques centaines de transactions dans le bassin de mémoire. Lors de la réception du bloc 277 315 et de sa validation, le nœud de Jing le comparera également à toutes les transactions du pool de mémoire et supprimera celles qui étaient incluses dans le bloc 277 315. Quelles que soient les transactions restantes dans le bassin de mémoire, elles ne sont pas confirmées et attendent d’être enregistrées dans un nouveau bloc.

Le nœud de Jing construit immédiatement un nouveau bloc vide, un candidat pour le bloc 277 316. Ce bloc est appelé bloc candidat car ce n’est pas encore un bloc valide, car il ne contient pas de preuve de travail valide. Le bloc ne devient valide que si le mineur réussit à trouver une solution à l’algorithme de preuve de travail.

Lorsque le nœud de Jing regroupe toutes les transactions du bassin de mémoire, le nouveau bloc candidat contient 418 transactions avec des frais de transaction totaux de 0,09094928 bitcoin. Vous pouvez voir ce bloc dans la chaîne de blocs à l’aide de l’interface de ligne de commande du client Bitcoin Core, comme indiqué dans Utiliser la ligne de commande pour récupérer le bloc 277,316.