Hashcash est un système de timbres informatiques fondé sur Proof of Work, la preuve d’un travail effectué. Le timbre montre qu’un résultat répondant à une condition a été trouvé. Ce n’est ni un bitcoin ni un solde de compte transférable.
Anna veut envoyer un courriel à Pavel. Une copie supplémentaire ne lui coûte presque rien, mais l’expéditeur de millions de publicités bénéficie du même avantage. Hashcash ajoute un petit obstacle : l’ordinateur de l’expéditeur doit d’abord produire un timbre informatique. Le coût est du temps et de l’énergie, pas un paiement à la poste. Adam Back a annoncé son implémentation le 28 mars 1997, puis publié une description technique en 2002. Cynthia Dwork et Moni Naor avaient étudié une idée similaire dès 1992. Hashcash s’inscrit dans cette recherche de moyens de limiter les abus du réseau. [1] [12]
Un hash est une empreinte de longueur fixe calculée à partir de données. Le programme d’Anna modifie une valeur du timbre et recalcule son empreinte jusqu’à obtenir assez de bits nuls au début. Un bit est un chiffre binaire : zéro ou un. Exiger b zéros donne à chaque essai une probabilité de réussite d’environ 2^-b, soit 2^b essais en moyenne. Pour b = 20, cela représente 1048576 calculs en moyenne, pas un nombre exact obligatoire. Parfois la chance arrive vite, parfois il faut attendre. Pavel vérifie le timbre terminé avec un seul calcul de hash, auquel s’ajoutent les contrôles de ses données et des règles d’acceptation. [10] [11]
Si Anna pouvait joindre un timbre à un million de messages, l’obstacle perdrait son utilité. Le timbre indique donc un destinataire ou un service précis et une date. Le destinataire vérifie sa validité et conserve la trace des timbres acceptés pour rejeter leur réutilisation, appelée replay. Ni la date ni un lien avec le contenu ne suffisent à empêcher le renvoi du même message. Hashcash n’a pas de registre mondial partagé des dépenses : ce contrôle appartient au service destinataire. Un hash correct ne suffit donc pas à faire accepter à nouveau le timbre. [11] [12]
Le service destinataire fixe la difficulté. Chaque bit nul supplémentaire double approximativement le travail moyen. Une exigence faible freine peu le spammeur ; une exigence forte pénalise aussi l’utilisateur ordinaire. Le nombre 20 est donc un exemple, pas une norme de sécurité éternelle. De plus, un même nombre d’essais prend un temps différent sur un ancien téléphone et un ordinateur rapide. Le service doit considérer les appareils, la durée de validité et sa propre capacité. Hashcash n’impose pas à chacun un nombre universel de secondes. [10] [11]
Le calcul ne distingue pas une personne respectueuse d’un attaquant. Un spammeur doté de nombreux ordinateurs ou d’un botnet, un réseau d’appareils compromis, peut répartir le travail et faire payer une partie du coût à d’autres. Pendant ce temps, l’utilisateur normal consomme sa batterie. Hashcash cherche à modifier l’économie d’une attaque, pas à garantir la disparition du spam. Le timbre ne chiffre pas non plus le message, ne prouve pas l’identité civile et ne garantit pas la livraison. C’est une condition d’acceptation que le service peut associer à d’autres protections. [10]
La version 1 utilise le format 1:bits:date:resource:ext:rand:counter. Les champs désignent la version, la difficulté déclarée, la date, le destinataire ou service, les extensions, une valeur aléatoire et un compteur variable. Le champ bits indique le nombre de bits nuls au début de l’empreinte annoncé par l’expéditeur, et non le nombre d’essais réellement effectués par son ordinateur. Ces noms appartiennent au format technique et ne se traduisent pas. L’implémentation classique applique SHA-1 à la chaîne entière. L’empreinte réelle doit satisfaire la condition : écrire un nombre dans bits ne suffit pas. Il s’agit d’un format historique, pas d’une recommandation de SHA-1 pour de nouvelles conceptions de sécurité. Bitcoin utilise un autre format de données et une autre fonction de hachage. [11] [13]
On cherche ici une entrée dont l’empreinte possède un début déterminé. Une telle entrée est appelée partial preimage : son empreinte respecte la partie imposée, tandis que le reste peut être quelconque. Une collision correspond au contraire à deux entrées différentes donnant la même empreinte. Certains textes historiques emploient l’expression plus vague partial collision, mais la distinction est importante. Une attaque capable de trouver des collisions SHA-1 ne résout pas automatiquement la recherche du préfixe requis. Cela ne fait pas pour autant de SHA-1 un choix général adapté à la sécurité actuelle. [10] [11] [13]
En 2004, Hal Finney a présenté RPOW, Reusable Proofs of Work. L’utilisateur pouvait remettre une preuve de travail et recevoir un nouveau jeton ; lors d’un transfert ultérieur, l’ancien devenait invalide et était remplacé. Réutiliser ne signifiait donc pas copier librement le même timbre. Le système reposait sur un serveur équipé d’un module sécurisé IBM 4758 et sur la vérification à distance du programme exécuté. Cela réduisait la confiance nécessaire envers l’opérateur, mais conservait des hypothèses sur le matériel et son fabricant. RPOW était un précurseur expérimental, pas le consensus décentralisé de Bitcoin. [7] [15]
Bitcoin Whitepaper cite explicitement le Hashcash de Back. Satoshi a repris la même asymétrie : trouver un résultat demande des essais répétés, les autres peuvent le vérifier facilement. Les mineurs de Bitcoin cherchent ainsi un en-tête de bloc valide, qui résume un bloc de transactions et fait référence au bloc précédent. Ils utilisent double SHA-256, deux applications successives de SHA-256, puis comparent le résultat à une limite numérique appelée target. Ce n’est pas un timbre de courriel SHA-1 placé dans un portefeuille. Le principe est commun, pas le système entier. [8] [14]
L’affranchissement donne un coût à une demande. La monnaie doit aussi déterminer lequel de deux transferts incompatibles est valide. Bitcoin relie les blocs et ses nœuds choisissent, parmi les branches valides, la chaîne ayant le plus de travail cumulé. Les nœuds, ces ordinateurs qui vérifient les règles, contrôlent aussi les transactions et l’émission autorisée. Même un travail immense ne rend pas valide une transaction invalide. Hashcash a fourni une brique importante ; sa combinaison avec d’autres règles a permis une histoire monétaire commune sans administrateur central. [8] [9]
Pour une vision complète, lisez aussi Proof of Work, Cypherpunks, Adam Back, Bitcoin Whitepaper, Bitcoin, Hash. Cette entrée est également citée par Cypherpunks, b-money, Bit Gold, Reusable Proofs of Work.