Luke Dashjr, connu sous le pseudonyme luke-jr, est un développeur Bitcoin. Ses contributions concernent les interfaces de minage, Bitcoin Knots et les BIP, des propositions et standards décrits publiquement. Elles montrent comment une personne peut peser sur le développement sans décider à la place de tout le réseau.
Luke Dashjr utilise le compte luke-jr sur GitHub, qui conserve du code source, des propositions de modification et leur historique. Son profil renvoie notamment à Bitcoin Knots et au logiciel de minage BFGMiner. Un profil n’est toutefois ni l’histoire complète de tous les contributeurs ni la liste des travaux d’une seule personne. Les modifications précises et les auteurs des spécifications apportent des preuves plus solides. Les exemples suivants traitent de questions pratiques : comment confier du travail au mineur, détecter tôt une erreur et savoir si une proposition est réellement utilisée. [1]
Miner consiste à répéter des calculs sur un bloc préparé jusqu’à obtenir un résultat conforme à la difficulté requise. Encore faut-il en assembler le contenu. Le BIP 22 de Dashjr décrit getblocktemplate, une interface qui fournit à un logiciel la structure du bloc envisagé, transactions comprises. Le logiciel ne reçoit donc pas nécessairement un simple en-tête à hacher : il peut assembler le bloc et effectuer les modifications autorisées. C’est comme recevoir le dossier d’un chantier entier plutôt qu’une tâche isolée. Les règles de validité du bloc restent néanmoins obligatoires. [2]
Imaginez une transaction qui dépense une sortie créée par une autre transaction du même bloc envisagé. Cette transaction précédente doit aussi y figurer. Le champ depends du BIP 22 indique ces dépendances. S’il manque, elles sont inconnues ; le logiciel ne doit pas en conclure qu’il n’y en a aucune. Il en va de même pour des frais non indiqués ou pour sigops, le nombre d’opérations de vérification de signatures comptées dans les limites du bloc. Une information absente n’est pas une valeur nulle. Ce détail évite de construire un bloc invalide en interprétant mal les données reçues. [2]
Le BIP 23 de Dashjr étend cette interface aux pools, qui regroupent le travail de plusieurs mineurs. Son mode facultatif proposal permet de soumettre un bloc préparé au serveur pour vérification, à l’exception de la preuve de travail. Une erreur de contenu peut ainsi être repérée avant la coûteuse recherche du résultat de calcul. Une réponse favorable signifie seulement que la proposition respecte les règles de ce serveur. Il manque encore la preuve de travail exigée et l’évaluation des autres nœuds. Ce contrôle préalable ne signifie pas qu’un nouveau bloc a déjà été miné. [3]
L’introduction de nouvelles règles constitue un autre sujet. Le BIP 8, rédigé par Shaolin Fry et Luke Dashjr, définit les étapes selon la hauteur de bloc, sa position dans la chaîne. L’option lockinontimeout détermine si la dernière période impose, dans les conditions prévues, une signalisation des mineurs pour verrouiller l’activation future. LOCKED_IN n’est pas ACTIVE : le premier état assure une transition ultérieure dans ce mécanisme, tandis que la nouvelle règle s’applique dans le second. Fixer une date d’entrée en vigueur et atteindre cette date sont deux choses distinctes. Rédiger la proposition ne fait pas basculer tout le réseau. [4]
Bitcoin Knots permet de faire fonctionner son propre nœud, un ordinateur qui télécharge et valide entièrement les blocs et transactions. Sa documentation décrit la reprise de développements de Bitcoin Core et la possibilité d’ajouter d’autres modifications ; un portefeuille et une interface graphique peuvent aussi être inclus. Lors de cette révision, le site officiel présente Dashjr comme responsable principal de la maintenance. Cette responsabilité sur un logiciel ne permet pas d’imposer des règles à tout le réseau. Pour choisir, mieux vaut lire les fonctions et réglages de chaque version que supposer un comportement toujours identique. [5] [6]
En téléchargeant Bitcoin Knots, vous voulez vérifier que le fichier vient de l’éditeur attendu. Le site recommande les signatures OpenPGP et la comparaison des clés publiques provenant de sources indépendantes. Une clé publique sert à vérifier une signature numérique ; il faut d’abord établir à qui elle appartient. Une signature valide associée à une clé correctement vérifiée atteste l’origine et l’absence de modification des données signées. Elle ne garantit pas un logiciel sans défaut. Vérifier la provenance, examiner le code et choisir les réglages restent des tâches différentes. [6]
Dashjr a également écrit le BIP 2 sur la préparation et la publication des propositions. Il est aujourd’hui remplacé par le BIP 3 de Murch. Celui-ci explique explicitement qu’un BIP publié ne représente pas à lui seul le consensus de la communauté ni une recommandation générale de mise en œuvre. Une proposition peut rester sur le papier, être adoptée par un logiciel ou aboutir à des changements de règles appliquées collectivement. Lui attribuer un numéro n’active rien. À l’annonce d’un nouveau BIP, demandez donc aussi qui l’a mis en œuvre et s’il est effectivement utilisé. [7] [8]
Pour une vision complète, lisez aussi Matt Corallo, Peter Todd, Satoshi Nakamoto. Cette entrée est également citée par Matt Corallo, Peter Todd.