Bitcoin Core

Pavel vend des livres contre des bitcoins. Une cliente lui montre une confirmation sur son téléphone, mais il veut savoir si le paiement est vraiment arrivé et figure dans un bloc valide. Il peut consulter un explorateur public ou utiliser un portefeuille relié à son propre nœud. Bitcoin Core est le programme qui fait fonctionner ce nœud. Un nœud désigne ici un ordinateur dont le logiciel vérifie lui-même les règles de Bitcoin ; un bloc est un ensemble de transactions ajouté à l’historique commun. Il reçoit les données des autres, mais en évalue lui-même la validité. Pavel est un exemple : l’intérêt est de remplacer la simple confiance dans un affichage extérieur par sa propre vérification. Installer le programme ne le transforme pas en mineur, ne lui donne pas automatiquement des BTC et ne permet pas d’annuler les paiements d’autrui. Le code est publié sous licence MIT, qui autorise son étude, sa modification et sa redistribution dans les conditions prévues. [1] [16]

On confond facilement les deux fonctions, car Bitcoin Core peut les assurer toutes deux. Le nœud contrôle l’historique et les nouveaux blocs. Le portefeuille suit les fonds concernés, crée des adresses et prépare des transactions ; s’il détient des clés privées, il peut aussi signer avec elles. Une clé privée est une donnée secrète utilisée pour créer une signature numérique autorisant la dépense des bitcoins correspondants. La clé elle-même n’est pas envoyée aux autres nœuds. Core peut pourtant fonctionner sans portefeuille. Pavel peut payer avec une autre application compatible et utiliser son nœud comme source de données vérifiées ; certains raccordements demandent un logiciel supplémentaire. Exécuter Core ne redirige pas automatiquement tous les autres portefeuilles vers ce nœud. Quelques noms permettent de se repérer : bitcoin-qt offre l’interface graphique, bitcoind tourne en arrière-plan et bitcoin-cli envoie des commandes au programme. [12] [17]

Un nouveau nœud doit d’abord rattraper l’historique. C’est l’Initial Block Download, ou IBD. Lors d’une synchronisation habituelle, il télécharge les blocs et contrôle leur enchaînement, le travail des mineurs et les règles des transactions. Il construit ainsi son chainstate : l’état local des sorties encore disponibles, les UTXO. Une sortie de transaction indique un montant et les conditions permettant de le dépenser, par exemple une signature requise. Elle reste dans cet état jusqu’à ce qu’une autre transaction la dépense. Ce n’est pas une liste de noms et de comptes bancaires. La vitesse dépend de l’ordinateur, du disque et de la connexion ; un démarrage lent ne signifie donc pas forcément une panne. Pavel attend la fin de la synchronisation avant de vérifier des paiements actuels.

Une précision compte : sous certaines conditions, assumevalid permet d’omettre des vérifications de scripts, c’est-à-dire des conditions de dépense, loin dans l’historique ; -assumevalid=0 désactive ce raccourci. Une autre fonction, AssumeUTXO, permet de partir d’un instantané d’état contrôlé tout en traitant l’historique antérieur en arrière-plan. Cet instantané conserve l’état des UTXO à un bloc donné. Le programme compare d’abord son hash, une empreinte numérique, à la valeur attendue dans son code ; cela ne signifie pas qu’il a déjà vérifié lui-même tout l’historique antérieur. Les hypothèses sont différentes : toutes les installations n’ont pas nécessairement effectué exactement les mêmes contrôles dès le départ. [9] [10] [12] [17]

Une fois synchronisé, Core continue de recevoir des données des nœuds connectés, appelés peers. Les transactions non confirmées qu’il accepte sont conservées dans son Mempool, une salle d’attente temporaire. Y apparaître ne vaut pas confirmation dans un bloc, et son contenu peut varier d’un nœud à l’autre. Lorsqu’un bloc arrive, Core le vérifie. Parmi les chaînes candidates valides, il retient le travail cumulé le plus élevé, et non un vote des ordinateurs ou simplement le plus grand nombre de blocs. Pavel distingue donc « paiement vu » et « paiement confirmé ». Son propre nœud ne garantit ni inclusion immédiate ni absence de réorganisation, lorsqu’une autre branche valide remplace une partie de l’historique suivi. [16]

Supposons que le nœud de Pavel refuse une transaction non confirmée dans son Mempool. Cela ne veut pas dire qu’elle ne pourra jamais figurer dans un bloc valide. Les règles de consensus déterminent les blocs et les dépenses valides pour ce nœud. La relay policy locale ajoute des conditions d’acceptation et de transmission des transactions non confirmées, notamment pour éviter de saturer ses ressources. Cette politique ne s’applique pas de la même façon aux transactions contenues dans un bloc reçu : c’est alors la validité selon le consensus qui compte. Des paramètres de Mempool différents ne divisent donc pas à eux seuls le réseau. Cette distinction évite de prendre chaque débat sur un réglage de Core pour une modification des règles monétaires. [13]

Core conserve les données des blocs, l’état du nœud et, éventuellement, des portefeuilles. Le pruning libère de l’espace en supprimant après traitement d’anciens fichiers de blocs et les données permettant d’annuler leurs effets. Le nœud vérifie toujours les nouveaux blocs ; il ne garde simplement plus toutes les archives à portée de main. Certaines recherches historiques ou analyses d’anciens paiements peuvent exiger un nouveau téléchargement. Les index accélèrent des recherches ; txindex, par exemple, est incompatible avec le pruning. Leur choix dépend des services que le nœud doit rendre. Une différence est essentielle : les blocs publics se téléchargent à nouveau, mais ne permettent pas de retrouver des clés privées perdues. Un portefeuille Core exige sa propre sauvegarde sécurisée. Lorsque le programme tourne, utilisez la fonction prévue, comme backupwallet, plutôt que de copier à la volée une base de données en cours d’écriture. [11] [12]

Pavel part du site officiel et lit les instructions de la version choisie. Une somme SHA-256 est l’empreinte du fichier téléchargé : elle révèle une différence avec le fichier attendu. À elle seule, elle ne dit pas qui a publié cette empreinte. Il faut donc aussi vérifier les signatures numériques et l’identité des clés de signature. Si un attaquant fournit à la fois le logiciel et sa propre somme, leur correspondance ne déjoue pas l’attaque. Pour aller plus loin, le projet utilise des compilations reproductibles : des personnes indépendantes peuvent produire des fichiers identiques à partir du même code et comparer leurs résultats. Guix aide à uniformiser l’environnement de compilation. Cela renforce la vérification de l’origine du programme, sans prouver que son code ne contient aucun défaut. [8] [7]

Core propose JSON-RPC, une interface permettant à d’autres programmes de le commander. Elle sert à consulter son état ou à intégrer des services, mais peut aussi autoriser des opérations sur des fonds selon les portefeuilles et permissions disponibles. Ses identifiants ne sont donc pas à transmettre à un prétendu assistant. L’interface ne chiffre pas elle-même le trafic réseau et n’est pas conçue pour être exposée à Internet. Les connexions ordinaires aux autres nœuds Bitcoin sont distinctes de l’ouverture de ces commandes. Pour un accès local, Core utilise aussi des identifiants temporaires dans le fichier .cookie. L’administration à distance demande une connexion protégée et des accès restreints conformément à la documentation. Essayer un nœud ne nécessite pas d’ouvrir son administration au monde entier. [14]

Tout le monde peut proposer une modification. D’autres contributeurs la lisent, la testent et la discutent ; les responsables du dépôt, les maintainers, peuvent intégrer les changements acceptés. Ils n’obtiennent pas pour autant le contrôle à distance du nœud de Pavel. Son opérateur choisit le logiciel exécuté. Ce choix n’est pas non plus un bulletin de vote permettant à une personne d’imposer de nouvelles règles aux autres : un changement incompatible peut isoler son nœud. Bitcoin Core est une importante implémentation des règles, pas une société propriétaire de tout le réseau. Distinguez donc proposition, intégration au code, publication d’une version et adoption réelle. Le chemin entre ces étapes peut être long. [15]

Vous pouvez commencer sans conserver de clés privées sur le nœud. Pavel vérifie le fichier et les signatures, laisse l’IBD se terminer et contrôle que son portefeuille utilise bien les données de son nœud. Il suit ensuite les connexions, la progression des blocs et l’espace libre. Avant une mise à jour, il lit les release notes, qui expliquent changements et conditions éventuelles de migration ; s’il utilise un portefeuille, il vérifie sa sauvegarde et sa restauration. Le fichier de diagnostic debug.log aide à comprendre les problèmes, mais ne doit pas être publié sans réflexion. Pruning, index et RPC doivent correspondre à l’usage, pas à un tutoriel copié aveuglément. Un nœud personnel doit rester un outil de vérification compréhensible. Il n’est pas obligatoire pour un premier petit achat, mais devient pertinent pour savoir pourquoi on considère ses paiements comme valides. [12] [14]