Jeff Garzik est un développeur connu publiquement sous jgarzik. Code précis et paternité BIP prouvent des contributions, pas un contrôle personnel du consensus Bitcoin.
GitHub associe Jeff Garzik à jgarzik. Pour le code historique, examiner dépôt et version précis ; le profil actuel ne prouve pas une autorité passée ou présente sur toutes les versions Bitcoin. [Garzik — public developer profile]
Le README du cpuminer de Garzik décrit un mineur CPU Bitcoin multithread. pooler/cpuminer se déclare dérivé pour Litecoin et Bitcoin ; ses fonctions ultérieures ne sont pas automatiquement celles de l’original. [Garzik — reference cpuminer README][Pooler — cpuminer ancestry]
Picocoin contient la bibliothèque C libccoin et marque son portefeuille HD et son nœud brd WIP. Le dépôt est archivé depuis le 15 février 2024. Le code disponible ne prouve pas un produit fini, entretenu et sûr. [Garzik — Picocoin archive and README]
BIP 35 de Garzik décrit la requête mempool et la réponse inv avec les hachages des transactions du nœud ; getdata demande les données. C’est un ensemble local non confirmé, pas une liste mondiale complète ni une preuve d’inclusion dans un bloc. [BIP 35 — mempool message][Bitcoin Core 29.0 — local mempool RPC]
BIP 100 nomme Garzik, Tom Harding et Dagur Valberg Johannsson. Le recalcul proposé tous les 2016 blocs utilise une majorité minière de 75% et des variations limitées. Son statut Closed ne prouve pas une adoption par tout le réseau. [BIP 100 — dynamic block-size proposal]
BIP 100 indique que le premier bloc dépassant l’ancienne limite de 1 MB sépare les nœuds qui l’appliquent toujours. Les votes miniers seuls ne changent pas les règles des nœuds non mis à jour. [BIP 100 — dynamic block-size proposal]
BIP 102 de Garzik proposait une limite unique de 2 MB, conditionnée par le temps et 95% des 1000 derniers blocs. Également Closed, il avertit de l’incompatibilité des anciens clients validateurs ; ce n’est pas la définition actuelle de taille des blocs. [BIP 102 — two-megabyte proposal]
Le registre marque BIP 35 Deployed dans Peer Services, mais BIP 100 et BIP 102 Closed dans Consensus (hard fork). Le déploiement d’un message ne prouve pas celui d’une autre proposition du même auteur. [BIP 35 — mempool message][BIP 100 — dynamic block-size proposal][BIP 102 — two-megabyte proposal]
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.