Pieter Wuille, connu sous le pseudonyme sipa, est développeur Bitcoin et auteur ou coauteur de BIP 32, SegWit, Bech32, Bech32m et Schnorr/Taproot. Un BIP est une proposition technique publique. Son apport tient à des solutions précises élaborées avec d’autres, pas au droit de décider pour tout le réseau.
Quand un portefeuille propose une nouvelle adresse ou prépare la signature d’un paiement, un simple bouton masque le travail de nombreux développeurs. Pieter Wuille est l’un d’eux. Sur GitHub, il utilise le nom sipa ; son profil relie ce pseudonyme à son activité. Mais attribuer une invention précise exige de consulter l’histoire et la documentation du projet, pas seulement un nom d’utilisateur. Les propositions suivantes montrent les problèmes qu’il a aidé à résoudre, et avec qui. [1]
Imaginez une boutique qui veut une adresse de paiement différente pour chaque commande. Le BIP 32 de Wuille décrit comment dériver un arbre de clés à partir d’une seed, les données secrètes de départ. Une clé publique étendue, ou xpub, permet de produire d’autres clés publiques de la branche concernée sans autoriser les dépenses. Une clé privée permet, elle, de signer. Attention à une exception : un xpub associé à une clé privée descendante divulguée, obtenue sans étape de dérivation renforcée, peut révéler la clé privée parente. La dérivation renforcée, dite hardened, coupe cette voie. Partager un xpub mérite donc de la prudence ; cela révèle aussi des liens entre paiements. [2]
D’autres paiements peuvent dépendre d’une transaction, d’où l’importance de son identifiant. Le BIP 141, signé par Eric Lombrozo, Johnson Lau et Pieter Wuille, sépare les données de vérification appelées witness, dont les signatures, de la partie déterminant l’identifiant initial txid. Le nouvel identifiant wtxid inclut également le witness. Une modification des données de signature ne change donc pas nécessairement le txid auquel une autre transaction fait référence. Les signatures restent vérifiées : le witness est protégé par un engagement cryptographique inscrit dans la transaction coinbase, la première du bloc. [3]
Une petite erreur arrive vite quand on recopie une adresse. Wuille et Greg Maxwell ont décrit Bech32 pour les adresses SegWit natives dans le BIP 173. Sa somme de contrôle comprend des caractères qui aident à détecter une adresse mal transcrite. Cette vérification porte sur le codage, pas sur l’identité du destinataire voulu. Si quelqu’un remplace l’adresse par une autre adresse valide, sa somme de contrôle ne signalera pas la fraude. [4]
Un format d’adresse peut encore être amélioré. Le BIP 350 de Wuille modifie la somme de contrôle pour corriger une faiblesse précise liée à l’insertion ou à la suppression de caractères. Le résultat s’appelle Bech32m. Le portefeuille doit vérifier la correspondance entre version de witness et codage : la version 0 conserve Bech32, tandis que les versions 1 à 16 utilisent Bech32m. L’utilisateur ne devrait pas choisir manuellement l’algorithme. C’est au logiciel de créer et de vérifier les adresses ; accepter n’importe quelle somme de contrôle valide ne suffit pas. [5]
Une signature numérique permet de vérifier l’autorisation d’un paiement sans que son propriétaire divulgue sa clé privée. Le BIP 340 de Pieter Wuille, Jonas Nick et Tim Ruffing spécifie Schnorr signatures : les signatures occupent 64 octets et les clés publiques 32 octets. L’octet est une unité de taille des données. Leurs propriétés mathématiques permettent de construire des systèmes où plusieurs personnes produisent une signature commune. Mais additionner des clés ne suffit pas : un protocole distinct doit coordonner les participants de façon sûre. [6]
Un portefeuille peut prévoir une manière habituelle de dépenser et des conditions de secours. Pieter Wuille, Jonas Nick et Anthony Towns décrivent Taproot dans le BIP 341. La voie par clé, ou key path, peut se contenter d’une signature sans révéler même l’existence de scripts alternatifs. Un script est un programme qui exprime des conditions de dépense. Si la voie par script, ou script path, est nécessaire, le script utilisé et sa preuve d’inclusion sont publiés ; les autres possibilités n’ont pas à être révélées intégralement. Cela économise de la place et protège certaines informations sur le portefeuille, sans rendre automatiquement tous les paiements anonymes. [7]
Ces changements répondent à des problèmes précis et permettent à chacun d’examiner leur conception et leur code. Bitcoin.org explique qu’un BIP fait l’objet de discussions publiques et que son adoption dépend des participants au réseau. Un nœud est un ordinateur qui vérifie transactions et blocs selon son logiciel. Être auteur ou responsable d’un dépôt de code ne donne pas le pouvoir de modifier seul les règles de consensus. L’importance de Wuille tient à ses contributions et à sa collaboration, pas à un rôle de patron de Bitcoin. [8]
Pour une vision complète, lisez aussi Craig Wright, Gregory Maxwell, Satoshi Nakamoto. Cette entrée est également citée par Craig Wright, Gregory Maxwell.