Gavin Andresen

Un logiciel ne s’entretient pas tout seul lorsque le créateur du projet se retire. Quelqu’un doit coordonner les corrections, les tests et les nouvelles versions. Gavin Andresen a assumé cette responsabilité après Satoshi dans les premières années de Bitcoin. Le profil du MIT pour une rencontre du 17 novembre 2015 rappelle ce rôle et nomme déjà Wladimir van der Laan comme responsable principal. Il s’agit d’une fonction dans le développement, pas de la propriété du réseau. Une biographie ancienne ne prouve pas non plus un accès actuel au dépôt, l’espace commun où se trouve le code source. [1]

Un débutant peut comprendre la monnaie numérique sans posséder de pièces pour apprendre à en recevoir et à en envoyer. Andresen a répondu à cet obstacle avec Bitcoin Faucet. Annoncé le 11 juin 2010, le service disposait au départ de 1 100 BTC et proposait cinq pièces à essayer. Le visiteur n’avait ni à attendre d’en miner ni à chercher un vendeur. Le faucet distribuait des fonds existants ; il ne créait ni nouveaux bitcoins ni récompense de bloc. Il facilitait une première expérience sans modifier les règles d’émission monétaire. [2]

Dans une réponse du 11 juin 2010, Andresen précisa la limite : cinq pièces par adresse IP, pas chaque jour. Une adresse IP identifie une connexion sur un réseau informatique ; ce n’est ni une adresse de portefeuille bitcoin ni un décompte fiable des personnes. Protéger le service ne revenait donc pas à vérifier leur identité. Un CAPTCHA, une tâche destinée à distinguer un humain d’un programme automatique, était alors envisagé comme mesure supplémentaire. Il faut séparer ce fonctionnement initial des changements ultérieurs, sans reconstruire le passé à partir des services actuels. [2]

Une autre contribution répondait à un problème pratique différent. Le destinataire peut souhaiter plusieurs signatures avant que l’argent soit dépensé. L’expéditeur doit-il traiter toute cette règle à chaque paiement ? BIP 16, daté de 2012, décrit Pay to Script Hash : le paiement renvoie à un hash, une courte empreinte numérique du script contenant les conditions. Un BIP est une proposition numérotée d’amélioration de Bitcoin. Le script lui-même, nommé ici redeemScript, est fourni par celui qui dépense les fonds. Les conditions restent les mêmes ; ce sont le moment et la responsabilité de leur présentation qui changent. [3]

Imaginez une caisse dont l’ouverture nécessite l’accord de plusieurs personnes. Montrer son règlement ne vous remet pas l’argent. De même, BIP 16 de 2012 exige de vérifier le hash du redeemScript fourni, puis d’exécuter ses conditions. Connaître le script ne remplace pas les signatures nécessaires. Ce script est aussi soumis à une limite technique de 520 octets ; l’octet mesure la taille des données. Pour un débutant, l’essentiel est de distinguer deux vérifications : présenter la bonne règle et disposer de ce qu’elle exige. [3]

En 2015, Andresen présenta BIP 101 pour augmenter progressivement la taille maximale des blocs. Le document décrit un Hard Fork : certaines nouvelles catégories de blocs autorisés seraient rejetées par les anciennes règles. Le registre classe cette proposition comme Closed, c’est-à-dire close. BIP 16 est, lui, marqué Deployed, donc déployé. Ce contraste montre qu’un numéro de BIP ou un auteur connu ne prouve pas l’activation. Lire une proposition demande aussi de vérifier si ses règles ont réellement commencé à s’appliquer. [4] [3]

Pourquoi l’augmentation faisait-elle débat ? Un bloc plus grand peut contenir davantage de transactions, mais ses données doivent être transmises, reçues et vérifiées. BIP 101 de 2015 examine donc les coûts de transmission et le risque de favoriser les grands opérateurs. Une connexion lente ne place pas son utilisateur dans la même situation qu’une grande entreprise de minage. Les attentes de l’auteur concernant le progrès technique constituent un argument pour sa proposition, pas un résultat mesuré pour toutes les situations futures. L’enjeu est de concilier capacité et possibilité de vérifier le réseau soi-même. [4]

Bitcoin.org explique que les développeurs ne peuvent imposer une modification des règles : chacun choisit le logiciel qu’il utilise. Pour fonctionner ensemble, les participants doivent conserver des règles compatibles. Andresen pouvait proposer, écrire du code et convaincre, mais pas modifier Bitcoin unilatéralement pour tous. Il est donc préférable d’évaluer ses contributions une à une : ce qu’un service permettait, ce que faisait le code et ce que le réseau a adopté. Les réalisations passées ne rendent pas automatiquement vraie chaque affirmation ultérieure. [5]