Jeff Garzik est un développeur connu sous le nom de compte jgarzik. Il a travaillé sur des logiciels Bitcoin et des BIP, documents décrivant des changements ou des procédures précises. Ses contributions éclairent l’évolution de Bitcoin : écrire du code et proposer une règle ne permet pas d’ordonner à tout le réseau de l’accepter.
Sur GitHub, Jeff Garzik utilise le nom jgarzik. Son travail se consulte dans des dépôts précis, des espaces publics contenant le code et son historique. C’est plus utile que d’attribuer à une personne le rôle vague de « diriger Bitcoin ». Pour un programme, il faut savoir ce qu’il fait et de quelle version on parle ; pour une proposition, ce qu’elle voulait changer. Un profil de développeur ne décide pas, à lui seul, de la version que les autres exécutent. [1]
Le README, fichier de présentation du cpuminer de Garzik, le décrit comme un programme de minage de Bitcoin sur CPU, le processeur de l’ordinateur. Le fonctionnement multithread répartit les calculs entre plusieurs fils d’exécution pouvant travailler en même temps. pooler/cpuminer, destiné à Litecoin et Bitcoin, indique explicitement qu’il en dérive. Reprendre du code pour le développer séparément s’appelle créer un fork du projet. Cela ne divise pas, en soi, le réseau Bitcoin, et les fonctions ajoutées dans un dérivé n’existaient pas nécessairement dans l’original de Garzik. [2] [3]
Picocoin fournit un autre exemple. Il comprend libccoin, une bibliothèque en langage C dont les fonctions peuvent servir à construire des applications Bitcoin. Son README marque toutefois le portefeuille HD et le nœud brd associés comme WIP, c’est-à-dire en cours de développement. Un portefeuille HD dérive une famille de clés à partir d’une base commune ; le nœud est destiné à communiquer avec le réseau Bitcoin. Le dépôt a été archivé le 15 février 2024. Il reste utile pour étudier l’histoire, mais la disponibilité du code ne prouve pas qu’il s’agit d’un produit achevé, entretenu et sûr pour ses économies. [4]
Imaginons un nœud voulant savoir quelles transactions non confirmées connaît son correspondant. Le BIP 35 de Garzik répond à ce besoin : le message mempool demande une liste, la réponse inv contient les identifiants des transactions, leurs empreintes cryptographiques, et getdata permet ensuite de demander les données elles-mêmes. Le mempool est une « salle d’attente » locale avant confirmation, pas une liste unique pour le monde entier. La commande getrawmempool documentée par Bitcoin Core renvoie elle aussi le contenu d’un nœud précis. Y trouver une transaction ne signifie pas qu’elle est confirmée dans un bloc. [5] [8]
La taille des blocs détermine l’espace disponible pour les transactions ainsi que les ressources nécessaires pour les transmettre et les vérifier. Dans BIP 100, Garzik, Tom Harding et Dagur Valberg Johannsson proposaient de faire évoluer la limite selon des votes inscrits par les mineurs dans les blocs. Le calcul aurait lieu tous les 2016 blocs, avec 75% de soutien dans les blocs et des variations limitées. Il ne s’agissait donc pas de compter les personnes. Le registre indique Closed, soit un dossier fermé ; sa description ne prouve pas que tout le réseau Bitcoin a adopté le mécanisme. [6]
Prenons un nœud ordinaire qui vérifie toujours la limite initiale de 1 MB. Lorsqu’il reçoit un bloc plus grand, il le refuse, même si le mineur qui l’a produit soutient une limite supérieure. BIP 100 avertit précisément de cette séparation. Un vote inscrit dans un bloc est une donnée que le nouveau logiciel peut interpréter, pas une instruction réécrivant un ancien programme. Une modification autorisant des blocs rejetés par les anciennes règles constitue un Hard Fork. Ce sens de fork diffère de la simple création d’un projet dérivé sur GitHub. [6]
Le BIP 102 de Garzik proposait une autre méthode : porter la limite à 2 MB en une seule fois. L’activation devait réunir une condition de date et un soutien signalé dans 95% des 1000 derniers blocs. Cela n’aurait pas adapté automatiquement les anciens programmes de validation, qui auraient continué à rejeter les blocs plus grands. Cette proposition porte également le statut Closed. Elle décrit un changement envisagé, pas les règles de taille de bloc que Bitcoin applique aujourd’hui. [7]
Pour chaque BIP, il faut lire le contenu et le statut. BIP 35 est indiqué Deployed, donc déployé, dans la couche Peer Services, consacrée aux services et à la communication entre nœuds. BIP 100 et BIP 102 sont Closed dans Consensus (hard fork), car ils concernent les blocs que les nœuds reconnaissent comme valides. Un même auteur peut travailler dans ces deux domaines avec des résultats différents. Le déploiement réussi d’un message réseau n’implique pas celui de toutes ses propositions de changement des règles. [5] [6] [7]
Pour une vision complète, lisez aussi Cynthia Lummis, Mike Hearn, Guerre de la taille des blocs. Cette entrée est également citée par Mike Hearn.