Bitcoin: A Work in Progress

On peut utiliser Bitcoin sans connaître son code. Cela ne veut pas dire qu’il n’y a plus rien à améliorer. Sjors Provoost, contributeur à Bitcoin Core, rend accessible le travail qui permet au réseau d’évoluer. Purple Dunes a publié la première édition papier en 2022. Le livre aborde des questions techniques de son époque ; une modification ultérieure des fichiers sources ne change pas la date de première publication. [1] [2]

Imaginez qu’un proche vous envoie une adresse et que vous la colliez dans votre portefeuille. Pour vous, un paiement commence. Pour le développeur, il faut aussi détecter une faute de saisie et indiquer sans ambiguïté où préparer le paiement. Cet exemple que nous proposons permet d’aborder le livre sans savoir programmer. Son contenu mène des adresses à la communication entre nœuds, puis aux changements de règles. Les chapitres plus exigeants deviennent plus clairs une fois ces bases comprises. [2]

L’adresse est une représentation à partir de laquelle le portefeuille construit les conditions permettant de dépenser une somme plus tard. Ces conditions sont inscrites dans une sortie de transaction, une nouvelle partie du paiement. Pour la dépenser ensuite, il faut prouver qu’elles sont remplies, généralement avec une signature numérique valide. Le réseau n’a donc pas besoin de tenir un compte bancaire à votre nom. Le chapitre de Provoost distingue l’adresse échangée entre personnes des règles vérifiées par les ordinateurs. [3]

L’adresse comporte une somme de contrôle qui aide le portefeuille à repérer une erreur de copie. Elle n’établit pas à qui appartient l’adresse. Dans notre exemple, vous pourriez coller par erreur l’adresse correctement écrite d’une autre personne et réussir le contrôle. Il faut donc aussi vérifier le destinataire prévu. Si le portefeuille signale une erreur, mieux vaut obtenir à nouveau l’adresse correcte que deviner quel caractère réparer. [3] [4]

Voici un détail plus technique : Bech32 et Bech32m sont des formats d’encodage d’adresses. BIP 350 prévoit Bech32 pour les adresses natives de version witness 0, et Bech32m pour les versions 1 à 16. La version witness est un numéro qui distingue les règles de validation de ce type de sortie. Le nouveau format corrige une faiblesse de la somme de contrôle lors de l’insertion de caractères. Cela n’invalide pas toutes les anciennes adresses et ne signifie pas qu’il faut les convertir à la main. [4]

Un nœud est un logiciel connecté au réseau Bitcoin ; un Full Node vérifie lui-même les règles des transactions et des blocs. Mais les nouvelles données doivent lui parvenir de quelque part. Lors d’un Eclipse Attack, l’attaquant contrôle toutes ses connexions et peut lui cacher une partie de l’activité du réseau. Le nœud rejette toujours les blocs invalides, mais son information est incomplète. Le livre souligne ainsi une distinction essentielle : vérifier les données reçues ne garantit pas l’accès à toutes les données nécessaires. [5]

L’attaquant ne peut pas simplement imposer un bloc quelconque au nœud isolé. Pour présenter une confirmation valide de son paiement, il lui faut aussi un bloc valide respectant Proof of Work, la preuve de travail informatique exigée. Une fois reconnecté, le nœud peut découvrir une autre branche valide ayant accumulé davantage de travail. Il adopte cette branche ; si le paiement initial en est absent, sa confirmation précédente ne tient plus. La sécurité repose donc sur la vérification des règles et sur des connexions réseau résistantes aux attaques. [5]

Partez d’une question familière, comme celle de l’adresse. Suivez ensuite ce que la solution permet et où sont ses limites. Cet aperçu s’appuie sur les mentions d’édition, le sommaire officiel, des passages publics choisis sur les adresses et Eclipse Attack, ainsi que sur BIP 350. Ce n’est pas une critique de l’ensemble du livre ni du podcast dont il est issu. Les chiffres historiques du réseau et l’état du développement de l’époque doivent être distingués du logiciel actuel. [1] [2] [3] [4] [5]