b-money est un projet de monnaie numérique présenté par Wei Dai en 1998. Il décrit deux façons de tenir des soldes communs et de gérer des contrats entre personnes utilisant des pseudonymes numériques. Ce n’était ni une monnaie lancée ni une ancienne version du logiciel Bitcoin. Le whitepaper de Bitcoin l’a ensuite cité en première référence.
Imaginons qu’Anna commande une illustration à Pierre sur internet. Ils ne connaissent que leurs pseudonymes. Ils veulent payer et prévoir les conséquences d’une promesse non tenue, sans d’abord révéler leur identité à une banque ou une autre autorité. Cette question intéressait les Cypherpunks, qui exploraient la protection de la vie privée par la cryptographie. Wei Dai y répondit avec b-money en 1998. Le pseudonyme numérique n’était pas un simple nom inventé : c’était une clé publique, une donnée qui n’a pas besoin de rester secrète et permet de vérifier la signature d’un message. Le secret de l’identité réelle dépendait aussi du réseau de communication anonyme supposé par le projet. [1] [2]
Dans notre exemple, Anna possède 10 unités et veut en envoyer 3 à Pierre. Elle publierait un message de transfert signé numériquement. Ce n’est pas une image de sa signature : le logiciel la calcule à partir du message et d’une clé privée, une donnée qu’Anna garde secrète. Les autres peuvent alors utiliser la clé publique pour vérifier que l’ordre a été signé par le détenteur de la clé privée correspondante. Les teneurs de comptes vérifieraient signature et provision, retireraient 3 du solde d’Anna et les ajouteraient à celui de Pierre ; il resterait 7 à Anna. Aucun fichier représentant une pièce ne voyage : les soldes enregistrés changent. La question décisive suit aussitôt : comment garder toutes les copies cohérentes si Anna diffuse des ordres incompatibles ? La signature seule ne produit pas cet accord. [1] [5]
Le premier protocole, c’est-à-dire l’ensemble de règles proposé, confie à chaque participant sa propre base de soldes. Pour que tous appliquent les mêmes mises à jour, il suppose un canal de diffusion anonyme, synchrone et impossible à bloquer. Autrement dit, les messages doivent parvenir à tous avec la coordination temporelle nécessaire, sans qu’on puisse empêcher leur diffusion ni identifier leur expéditeur. C’est une hypothèse bien plus forte qu’une connexion internet ordinaire, où des messages arrivent en retard ou se perdent. Dai qualifiait donc lui-même cette version d’impraticable. Elle servait de point de départ à la seconde, et non de réseau prêt à fonctionner. [1] [2]
Les soldes doivent avoir une origine. Dai proposait que chacun puisse publier la solution d’un nouveau problème exigeant du calcul et recevoir des unités monétaires. Les autres devaient pouvoir évaluer facilement le travail ; la solution ne devait pas avoir d’autre valeur pratique ou intellectuelle. La quantité créée dépendrait du coût du calcul exprimé dans un panier standard de matières premières, un ensemble convenu de biens servant à comparer les coûts. Cela rappelle Proof of Work, la preuve d’un effort de calcul, mais ce n’est pas encore le minage de blocs Bitcoin. Un bloc est un ensemble de transactions ajouté à l’historique partagé des paiements. Il faut aussi une estimation commune malgré des ordinateurs de performances et de coûts différents. [1] [2] [5]
Dans le second protocole, tout le monde ne conserve plus le registre complet. Un sous-ensemble de participants, appelés serveurs, reprendrait cette tâche. Anna et Pierre vérifieraient le traitement du paiement auprès d’un échantillon de ces serveurs choisi au hasard. Comme cela demande une certaine confiance envers les gestionnaires, chaque serveur devait déposer une garantie monétaire pouvant servir à sanctionner une faute prouvée. Les serveurs devaient aussi publier régulièrement l’état des soldes et de la création monétaire. Les utilisateurs vérifieraient leur propre solde et que le total ne dépasse pas l’argent créé. Ce sont des contrôles précis des gestionnaires, différents des nœuds et mineurs actuels de Bitcoin. [1]
La monnaie n’était qu’une partie de b-money. Pour la commande d’Anna et Pierre, un contrat fixerait les conditions et les indemnités maximales en cas de manquement. Les parties et un éventuel arbitre, chargé de juger le litige, signeraient et immobiliseraient les montants prévus sur un compte spécial. À l’issue convenue, l’argent serait réparti selon le résultat. Si même l’arbitrage échouait, le projet prévoyait la publication des arguments, puis l’évaluation des indemnités ou amendes par chaque teneur de comptes. Cela révèle une limite : une signature atteste l’accord, mais ne décide pas si l’illustration a été livrée et ne garantit pas un jugement identique de tous les gestionnaires. [1] [2]
Dai voyait la difficulté de convenir du coût réel d’un calcul. La technique évolue et certains participants peuvent disposer d’avantages inconnus des autres. L’annexe A proposait donc une alternative applicable aux deux protocoles. Les teneurs de comptes planifieraient d’abord le nombre de nouvelles unités. Des candidats proposeraient ensuite le problème à résoudre pour la quantité de monnaie demandée, effectueraient le calcul et publieraient la solution. La création suivrait les offres acceptées. Ces quatre phases — planification, offres, calcul et création — devaient remplacer une simple estimation des coûts. Ce n’est ni la limite prédéfinie de 21 millions de Bitcoin ni son Halving, la division régulière par deux du nombre de nouveaux bitcoins créés par bloc. [1] [3]
Adam Back analysait le projet en décembre 1998. Il signalait notamment les différences de coût du calcul et la possibilité de relier des paiements effectués sous des pseudonymes persistants. Cacher son nom civil ne rend donc pas les paiements impossibles à relier. Le texte original prévoit des contrôles des serveurs : dire qu’il ignore toute malhonnêteté serait inexact. Il ne fournit cependant pas de méthode complète et éprouvée pour maintenir toutes les bases en accord malgré pannes et litiges. Ces situations expliquent une partie de la distance entre proposition et système fonctionnel. La discussion conservée complète donc utilement la lecture du projet. [1] [3] [7]
Le 22 août 2008, Satoshi Nakamoto écrivit à Wei Dai qu’Adam Back lui avait signalé b-money et demanda son année de publication pour le citer. Dai répondit qu’il l’avait annoncé en 1998. Le whitepaper de Bitcoin plaça ensuite b-money en tête de ses références. Dans un autre courriel, le 10 janvier 2009, Satoshi annonça Bitcoin v0.1 et estima qu’il réalisait presque tous les objectifs de b-money. Ces échanges attestent un contact et la reconnaissance d’une idée antérieure. Ils ne prouvent ni que Wei Dai a écrit Bitcoin, ni que les deux projets fonctionnent de la même façon, ni combien de solutions techniques ont été reprises directement. [4] [5] [6]
b-money est une étape importante de l’histoire des idées, pas une monnaie que ce projet permet aujourd’hui de placer dans un portefeuille. Il n’a pas été mis en œuvre comme le système de paiement opérationnel décrit ici. Il n’avait ni la chaîne de blocs de Bitcoin ni sa règle choisissant la chaîne valide avec le plus de travail accumulé. Mais il posait une question claire : comment réunir signatures numériques, création monétaire et comptabilité partagée sans tout confier à une banque ? Bitcoin a ensuite réuni ses propres réponses dans un réseau fonctionnel. Lire b-money sépare l’idée de monnaie numérique de la tâche plus difficile de conserver un état commun et vérifiable entre personnes qui ne se font pas nécessairement confiance. [1] [4] [5]
Pour une vision complète, lisez aussi Wei Dai, Cypherpunks, Reusable Proofs of Work, Proof of Work, Hashcash, Bit Gold. Cette entrée est également citée par Cypherpunks, Bit Gold, Wei Dai, The Genesis Book.