Mike Hearn

Créer un portefeuille Bitcoin ne demande pas de réécrire toute sa communication à partir de rien. Une bibliothèque fournit des fonctions prêtes à l’emploi sur lesquelles bâtir une application. bitcoinj en est un exemple. Son fichier AUTHORS cite Mike Hearn parmi de nombreux contributeurs et renvoie à l’historique des modifications dans Git. On peut ainsi retrouver des contributions précises. Cela ne signifie pas que Hearn a écrit seul toutes les fonctions ni qu’il dirige aujourd’hui l’ensemble du projet. [1]

bitcoinj est une bibliothèque Java permettant de gérer un portefeuille et d’envoyer ou recevoir des transactions sans installation locale de Bitcoin Core. Pour un téléphone, le mode SPV, abréviation de Simplified Payment Verification, est intéressant : il utilise les en-têtes de blocs et les transactions utiles au portefeuille au lieu de vérifier intégralement toutes les transactions. Cela économise des données et des ressources. La documentation décrit aussi une vérification complète expérimentale. Ces modes diffèrent : fonctionner plus légèrement ne revient pas à effectuer les mêmes vérifications de toutes les règles, simplement plus vite. [2]

Imaginons un ordinateur portable qui sort de veille. Sa connexion à un autre nœud peut sembler ouverte alors qu’elle ne fonctionne plus. Le BIP 31 de Hearn permet d’envoyer un ping avec un nonce, ici un nombre qui identifie une demande précise. Le nœud distant renvoie ce nombre dans un message pong. Avec les versions du protocole supérieures à 60000, on peut ainsi associer les réponses aux demandes et mesurer leur délai. Cela vérifie la communication : une réponse ne prouve à elle seule ni l’honnêteté du nœud ni la validité d’un paiement. [3]

Pourquoi le téléphone devrait-il télécharger des transactions qui ne le concernent pas ? Le BIP 37, de Hearn et Matt Corallo, décrit un filtre de Bloom : un outil compact qui sélectionne des correspondances possibles. filterload définit le filtre, filteradd ajoute un élément et filterclear supprime le filtre. Une transaction sans rapport peut passer ; c’est un faux positif. Un filtre plus précis réduit le trafic, mais peut aider le nœud distant à relier les transactions à l’adresse IP du portefeuille. Économiser des données ne protège donc pas automatiquement la vie privée. [4]

Le téléphone doit savoir si une transaction reçue appartient à un bloc donné. Le message merkleblock du BIP 37 fournit les données d’une preuve de Merkle : quelques empreintes de données, ou hashes, permettent de vérifier le lien entre la transaction et l’empreinte commune inscrite dans l’en-tête du bloc. Inutile de télécharger tout le bloc. Mais cette preuve ne permet pas d’exclure que le nœud ait caché d’autres transactions. SPV ne remplace pas non plus une vérification complète de leur validité. La documentation de bitcoinj explique le danger d’un attaquant qui contrôle toutes les connexions du portefeuille et choisit ce qu’il lui montre. [4] [5]

Lors d’un achat, il faut connaître le montant et le destinataire. Le BIP 70, de Gavin Andresen et Hearn, introduit PaymentRequest à cet effet. Ce message contient les détails du paiement : les sorties qui précisent où la transaction doit affecter les fonds, le montant et une éventuelle date d’expiration. Des certificats X.509 peuvent authentifier le commerçant, comme pour les serveurs web. Mais le protocole autorise aussi pki_type none, une demande sans cette authentification. Le format d’une demande de paiement ne suffit donc pas à établir l’identité certifiée du commerçant. [6]

Si la demande indique un serveur de paiement, le portefeuille lui envoie un message Payment après votre autorisation. La réponse PaymentACK peut annoncer que le commerçant a accepté le paiement pour traitement. C’est utile au client, mais cela reste une déclaration de son serveur, pas une preuve de confirmation dans un bloc. De même, refund_to indique seulement où le commerçant peut envoyer un remboursement ; ce champ ne rend pas l’argent à lui seul. L’application doit distinguer les messages concernant le paiement du mouvement réel des fonds. [6]

Un ancien guide peut donner l’impression que la procédure décrite fonctionne partout. Le registre classe le BIP 70 comme Deployed, donc mis en œuvre. Pourtant, les notes de Bitcoin Core 0.20.0 indiquent la suppression complète de sa prise en charge dans ce programme. Il n’y a pas de contradiction : une spécification utilisée par le passé n’est pas nécessairement prise en charge par chaque logiciel actuel. Le travail de Hearn éclaire l’évolution des portefeuilles ; pour appliquer une procédure, il faut aussi vérifier les fonctions du programme et de sa version. [6] [7]