Wei Dai est cryptographe et auteur initial de la bibliothèque Crypto++. Sa proposition b-money de 1998 décrit comment des personnes utilisant des pseudonymes numériques pourraient tenir des comptes et conclure des contrats. Bitcoin cite ce travail, mais possède sa propre organisation et ses propres règles.
Pour chiffrer un message ou vérifier une signature numérique, un développeur n’a pas à réécrire toutes les procédures. Il peut utiliser une bibliothèque cryptographique, un ensemble de fonctions destinées au traitement de données protégées. Wei Dai a initialement écrit une telle bibliothèque, Crypto++, en C++. C’est un logiciel que l’on peut intégrer à une application. b-money est une contribution d’une autre nature : une proposition écrite de système monétaire. L’existence d’une bibliothèque fonctionnelle ne démontre pas qu’un réseau réalisant cette proposition a également fonctionné. Comprendre son apport suppose de distinguer ces deux démarches. [3]
En novembre 1998, Wei Dai posait une question familière jusque dans les achats en ligne : comment coopérer sans dévoiler son identité ? b-money propose deux protocoles, autrement dit deux ensembles de règles pour la comptabilité commune et les contrats. Les clés publiques serviraient de pseudonymes et les messages seraient signés numériquement. Un réseau empêchant de retrouver les participants était toutefois une hypothèse de départ, pas une propriété que la proposition assurait elle-même. Dai jugeait la première variante impraticable en raison de ses exigences de diffusion des messages. Il s’agit d’une conception réfléchie, pas du mode d’emploi d’un service anonyme déjà opérationnel. [1]
Imaginons qu’Anna possède 5 unités de b-money et en envoie 2 à Thomas. Dans la première variante, chaque participant conserve une copie des comptes. Le message signé d’Anna demande de débiter son compte et de créditer celui de Thomas ; il lui reste 3 unités. Un message qui produirait un solde négatif est ignoré. La signature permet de vérifier l’autorisation, mais une comptabilité commune exige aussi des règles de transmission des messages. Bitcoin utilise quant à lui le modèle UTXO : il suit les sorties précises de transactions encore disponibles à la dépense. Un objectif comparable n’impose donc pas une comptabilité identique. [1]
La seconde variante de b-money confie les comptes à une partie des participants, appelés serveurs. Cela allège le travail des autres, mais oblige à surveiller les gestionnaires. Les serveurs doivent constituer des dépôts pouvant servir à payer des sanctions, publier régulièrement leurs bases de données et s’engager publiquement sur leur contenu. Les utilisateurs vérifient leur propre solde et que la somme des comptes ne dépasse pas l’argent émis. Les bénéficiaires contrôlent aussi le traitement des paiements auprès de serveurs choisis au hasard. Un dépôt ne supprime donc pas la confiance par magie : il contribue au dispositif proposé pour surveiller ceux qui tiennent les comptes. [1]
Dans le b-money initial, résoudre un problème de calcul permet de créer des unités. Leur quantité dépendrait du coût du calcul, mesuré à l’aide d’un panier standard de biens. Ce panier fournit une mesure commune des coûts ; il ne fixe pas le prix auquel une unité se vendra sur le marché. Or les ordinateurs progressent et leurs coûts réels ne sont pas connus de tous. Dai reconnaît cette difficulté et propose en annexe une enchère : les teneurs de comptes négocient la quantité à créer et les candidats rivalisent par des offres de calcul. Ce n’est pas le calendrier d’émission des BTC. Reconnaître le problème et explorer une autre voie fait aussi l’intérêt du texte. [1]
La proposition dépasse les paiements. Pour une commande de traduction, une signature peut établir l’accord sur le contrat, mais pas la qualité du texte livré. Les contrats b-money prévoient donc des dépôts, des indemnisations convenues en cas de manquement et un arbitre. Si les parties ne s’entendent toujours pas avec son aide, elles présentent leurs arguments et chaque teneur de comptes tranche individuellement. Cela révèle la difficulté d’intégrer des litiges humains à un système numérique. Bitcoin Script, le langage des conditions de dépense d’une sortie, évalue plutôt des conditions techniques précises. Il ne peut pas, à lui seul, juger la qualité d’une traduction. [1]
Satoshi Nakamoto cite b-money, daté de 1998, en référence 1 du whitepaper de Bitcoin, le document expliquant sa conception. On peut ainsi suivre une filiation intellectuelle précise : l’argent numérique sans administrateur commun était étudié avant Bitcoin. La citation ne signifie pas que Bitcoin a repris tous les mécanismes proposés. Les comptes, l’émission et le règlement des différends de b-money sont différents. Elle ne révèle pas non plus qui se cachait derrière le nom Satoshi Nakamoto. Pour comprendre cette histoire, mieux vaut comparer les textes documentés que déduire l’identité d’un auteur d’une référence bibliographique. [2]
L’histoire de Crypto++ se poursuit à travers les corrections, les tests et le travail d’autres développeurs. L’historique du projet indique qu’en juin 2015 Wei Dai a confié la gestion quotidienne à la communauté. Pour les utilisateurs, l’auteur initial compte, mais aussi la version précise et l’utilisation correcte des fonctions. Une bibliothèque fournit des outils de signature ou de chiffrement ; elle ne résout pas à elle seule le stockage sûr des clés ni la conception complète d’un portefeuille. Les développeurs doivent lire la documentation, suivre les correctifs et vérifier leur propre usage. Reconnaître l’apport de l’auteur va de pair avec l’examen du logiciel actuel. [3]
Pour une vision complète, lisez aussi Adam Back, Nick Szabo, b-money, Satoshi Nakamoto. Cette entrée est également citée par b-money, Bit Gold, Adam Back, Nick Szabo.