Référence pour développeurs
Voici la couche de référence : les types de messages P2P, les opcodes de script, les noms de champs RPC et les structures du protocole que l'on rencontre en lisant le code de bitcoin ou en décodant une transaction brute, plutôt qu'en achetant quoi que ce soit.
Elle existe parce que le glossaire pour développeurs de Bitcoin Core, où la plupart de ces termes sont encore recherchés, n'a guère changé depuis 2021, et plusieurs de ses entrées ne décrivent plus le logiciel. Le protocole de paiement BIP70 qu'il documente a été supprimé de Bitcoin Core dans la version 0.20.0. Ses entrées sur les filtres de Bloom décrivent un mécanisme que Core a cessé de servir par défaut dans la version 0.19.0. Chacune de ces entrées est réécrite ici d'après ce que fait le code aujourd'hui, la correction étant indiquée plutôt qu'appliquée en silence.
Les termes se répartissent en groupes. Les types de messages comme inv, getdata et MSG_FILTERED_WITNESS_BLOCK appartiennent au protocole pair-à-pair. Les opcodes comme OP_RETURN et OP_CHECKSIG appartiennent à Script. Les indicateurs de hachage de signature, les numéros de séquence et le locktime régissent ce à quoi une signature engage réellement. Les entrées X509 et demande de paiement sont historiques, et elles le disent.
La plupart des lecteurs n'auront jamais besoin de cette section, et c'est très bien. Elle est là pour qu'une recherche sur un nom de champ exact mène à une page qui l'explique correctement plutôt qu'à une ébauche d'une ligne.
47 termes. Dernière vérification le 24 septembre 2026.
Termes de la section Référence pour développeurs
- Bitcoin Scriptaussi ScriptBitcoin Script est le petit langage à pile que porte chaque sortie de bitcoin, qui fixe les conditions à remplir avant que ces bitcoins puissent être dépensés à nouveau.
- Certificat feuilleLe certificat feuille est le certificat d'entité finale présenté par le serveur auquel vous vous êtes réellement connecté, et il prouve le contrôle d'un nom de domaine, rien sur les personnes qui se trouvent derrière.
- Certificat intermédiaireUn certificat intermédiaire se situe entre une racine et un certificat feuille, signé par la racine et signant la feuille, ce qui permet à la clé privée de la racine de rester hors ligne et inutilisée.
- Certificat racineUn certificat racine est l'ancre de confiance auto-signée située au sommet d'une chaîne de certificats, et il n'est digne de confiance que parce que votre système d'exploitation ou le fournisseur de votre navigateur l'y a placé.
- Certificat X.509aussi Certificats X.509Un certificat X.509 est un fichier signé qui lie une clé publique à un nom et à une période de validité, et c'est le format qui sous-tend chaque connexion HTTPS que vous établissez vers une plateforme d'échange.
- Chaîne de certificatsUne chaîne de certificats est la liste ordonnée de certificats qui relie celui présenté par un serveur à une racine à laquelle votre appareil fait déjà confiance, chaque maillon étant signé par le suivant.
- CompactSizeaussi entier de longueur variable, Compact size unsigned integer, VarIntCompactSize est l'entier de longueur variable que le bitcoin utilise pour préfixer les compteurs et les longueurs dans les données sérialisées : un octet pour les valeurs inférieures à 253 et jusqu'à neuf pour les autres.
- Données marchand PPLes données marchand PP étaient une chaîne d'octets opaque qu'un marchand BIP70 plaçait dans une demande de paiement et récupérait telle quelle, ce qui permettait de rattacher les bitcoins reçus à une commande.
- Données PKI de PPLes données PKI de PP étaient le champ d'une demande de paiement BIP70 qui portait les certificats du marchand, encodés en DER, le certificat feuille en premier, les intermédiaires derrière lui et la racine laissée de côté.
- Fonction pointLa fonction point transforme une clé privée en clé publique en multipliant le point générateur de secp256k1 par ce nombre, et c'est l'étape à sens unique sur laquelle repose chaque adresse bitcoin.
- LabelLe label dans un URI Bitcoin nomme la personne ou l'entreprise payée, et dans un portefeuille c'est la note privée que vous associez à une adresse ou à une transaction.
- Mémo PPLe mémo PP était la note en texte libre UTF-8 que le BIP70 permettait à un marchand, à un payeur ou à un serveur d'accusé de réception de joindre à un paiement pour qu'un humain la lise.
- Montant PPLe montant PP était le champ libellé en satoshis d'une sortie BIP70, mis à zéro lorsque le commerçant voulait que le payeur choisisse la somme à envoyer.
- MSG_BLOCKMSG_BLOCK est le type d'inventaire 2, le code qu'un nœud place dans un message getdata pour demander à un pair un bloc complet par son hash.
- MSG_CMPCT_BLOCKMSG_CMPCT_BLOCK, type d'inventaire 4, est un code réservé aux requêtes : il n'apparaît jamais dans une annonce et n'est légal qu'à l'intérieur d'un message getdata envoyé à un pair qui l'a accepté au préalable.
- MSG_FILTERED_WITNESS_BLOCKLe type de bloc témoin filtré figure dans la liste réservée du BIP144 et dans l'énumération source de Bitcoin Core, sans aucune implémentation derrière lui, ni ici ni là.
- MSG_TXMSG_TX marque une entrée d'inventaire comme une transaction, code de type 1, et c'est ainsi que votre paiement non confirmé est annoncé aux pairs avant que l'un d'eux ait vu son contenu.
- MSG_WITNESS_BLOCKLe type d'inventaire witness block est la façon dont un nœud compatible segwit demande un bloc dans la sérialisation étendue, avec toutes les signatures attachées au lieu d'être retirées.
- MSG_WITNESS_TXUne demande de transaction témoin, envoyée sous forme de getdata, indique à un pair de renvoyer la transaction nommée avec ses données de signature encore attachées plutôt que supprimées.
- OP_CHECKMULTISIGOP_CHECKMULTISIG vérifie en une seule étape un groupe de signatures par rapport à une liste de clés publiques, et les dépenses Taproot ne peuvent pas l'utiliser du tout car il empêche la vérification par lots.
- OP_CHECKSIGOP_CHECKSIG retire une clé publique et une signature de la pile et vérifie que la signature porte sur cette transaction, ce qui est la vérification qui prouve réellement que vous possédez les bitcoins.
- OP_DUPOP_DUP copie l'élément situé au sommet de la pile pour qu'il puisse servir deux fois, ce qui permet au script standard pay-to-public-key-hash de hacher votre clé publique et de vérifier une signature à partir d'elle.
- OP_EQUALOP_EQUAL compare octet par octet les deux éléments du haut de la pile et empile un résultat vrai ou faux, et c'est le dernier opcode de toute sortie pay-to-script-hash.
- OP_EQUALVERIFYOP_EQUALVERIFY compare les deux éléments situés au sommet de la pile et met fin au script sur-le-champ s'ils diffèrent, ce qui permet à une dépense héritée de prouver qu'elle a présenté la bonne clé publique.
- OP_HASH160OP_HASH160 applique SHA-256 à l'élément en haut de la pile, puis RIPEMD-160 à ce résultat, ce qui donne un condensé de 20 octets, la même empreinte présente dans toute adresse commençant par 1 ou 3.
- OP_RETURNOP_RETURN est l'opcode qui rend une sortie de transaction impossible à dépenser de manière prouvable, ce qui permet d'inscrire une petite quantité de données arbitraires dans la blockchain sans alourdir l'ensemble des bitcoins non dépensés.
- OP_VERIFYOP_VERIFY retire l'élément situé au sommet de la pile et interrompt tout le script si cet élément n'est pas vrai, ce qui transforme tout test dans Bitcoin Script en exigence absolue.
- Opcodeaussi Opcode de poussée de données, Opcode sans poussée de donnéesUn opcode est un octet unique du langage Bitcoin Script qui indique à un nœud de validation quoi faire ensuite : soit empiler des données, soit effectuer une opération sur ce qui se trouve déjà dans la pile.
- Ordre des octets interneL'ordre des octets interne est la disposition que le bitcoin utilise à l'intérieur des structures sérialisées : les entiers sont écrits octet le moins significatif en premier, et les empreintes de hachage dans l'ordre où SHA-256 les a produites.
- Ordre des octets RPCL'ordre des octets RPC est la manière inversée dont les logiciels bitcoin affichent les hachages de 32 octets, et c'est la forme de chaque identifiant de transaction que vous copiez depuis un portefeuille ou un explorateur de blocs.
- Paramètre RLe paramètre R est l'ajout du BIP72 à un URI bitcoin qui remplace l'adresse de paiement par une URL depuis laquelle votre portefeuille est censé récupérer une demande signée.
- PaymentDetailsPaymentDetails est le message interne du BIP70 qui décrivait réellement un paiement : quelles sorties payer, quel montant, quand la demande expire et où envoyer la transaction signée.
- PaymentRequestPaymentRequest est l'enveloppe externe du BIP70 : elle contient un bloc PaymentDetails sérialisé ainsi qu'une chaîne de certificats et une signature, ce qui permettait au payeur de vérifier qui formulait la demande.
- PKIaussi Infrastructure à clés publiquesLe PKI, ou infrastructure à clés publiques, est le système d'autorités de certification, de certificats et de magasins de confiance qui permet à un logiciel de décider si une clé publique appartient réellement au nom qui lui est associé.
- PP expiresPP expires était l'horodatage Unix facultatif d'un message PaymentDetails de BIP70 qui indiquait à un portefeuille de cesser d'honorer la demande une fois ce moment passé.
- PP pki typePP pki type était la chaîne d'un seul mot dans une demande de paiement BIP70 qui indiquait comment le commerçant l'avait signée : none, x509 avec SHA-256, ou x509 avec SHA-1.
- Protocole de paiement (BIP70)aussi Protocole de paiement, BIP70Le protocole de paiement (BIP70) était la tentative du bitcoin de remplacer les adresses brutes par des demandes de paiement signées et couvertes par un certificat, et Bitcoin Core en a supprimé la dernière prise en charge dans la version 0.20.0.
- QR code URIUn QR code URI est le motif carré noir et blanc qui encode un URI bitcoin:, afin qu'une caméra puisse lire l'adresse et le montant qu'il faudrait sinon saisir à la main.
- ReçuEn bitcoin, un reçu désigne toute preuve que vous conservez qu'un paiement a eu lieu : dans le BIP70, il s'agissait d'un accusé de réception signé par le marchand, et en pratique, c'est l'identifiant de transaction.
- Script de clé publiqueaussi scriptPubKey, Script de verrouillage, Pubkey scriptLe script de clé publique est le court fragment de Bitcoin Script attaché à chaque sortie de transaction, qui énonce les conditions à remplir avant que les bitcoins de cette sortie puissent à nouveau être déplacés.
- Script de rachataussi Redeem scriptUn script de rachat est le contrat de dépense complet dissimulé derrière une sortie pay-to-script-hash, fourni par celui qui effectue la dépense à la fin du script de signature et haché pour vérifier qu'il correspond.
- Script de signatureaussi scriptSig, Script de déverrouillageUn script de signature est l'ensemble des données de déverrouillage qu'une entrée transporte pour satisfaire le script de clé publique de la sortie qu'elle dépense, et sur les entrées SegWit modernes il est vide.
- Script PPLe script PP était le champ obligatoire d'une sortie BIP70 contenant le script de verrouillage brut que le payeur devait reproduire, les mêmes octets que l'on retrouve dans une sortie de transaction.
- Script témoinLe script témoin contient les conditions de dépense réelles d'une sortie P2WSH et voyage dans le témoin, où ses octets sont pondérés au quart du coût habituel.
- Signature SSLLa signature SSL est le nom que le BIP70 a donné aux octets signant une PaymentRequest avec la clé de certificat d'un serveur web, et cette appellation était déjà impropre au moment où elle a été écrite.
- Somme de contrôle de descripteurUne somme de contrôle de descripteur est le code de huit caractères qui suit le dièse dans un descripteur de sortie, un code BCH qui détecte les fautes de frappe et de copie avant qu'un portefeuille n'importe les mauvaises clés.
- URI Bitcoinaussi BIP21Un URI Bitcoin regroupe les détails d'un paiement dans une seule chaîne cliquable qui commence par bitcoin : et peut contenir une adresse, un montant et un libellé.
Les 13 autres sections
- Les basesCe qu'est le bitcoin, ce qu'est un satoshi, et la poignée d'idées sur lesquelles repose le reste du glossaire.
- Adresses et clésOù envoyer des fonds, ce que contrôle réellement une clé privée, et comment une seule phrase de récupération produit des milliers d'adresses.
- Portefeuilles et conservationChaud, froid, dépositaire et multisig, et ce que chacun change sur qui peut déplacer vos fonds.
- Confidentialité et sécuritéLes attaques qui font perdre leur bitcoin aux gens, et les habitudes et outils qui les arrêtent.
- Transactions et fraisDe quoi se compose une transaction bitcoin, pourquoi elle coûte ce qu'elle coûte, et comment débloquer une transaction coincée.
- Achat et plateformesTypes d'ordres, spreads et grilles de frais : le vocabulaire qu'emploie une plateforme pendant qu'elle vous facture.
- Marchés et investissementCapitalisation, volatilité et ETF au comptant. Le langage du prix, sans les prédictions de prix.
- Minage et consensusComment naissent les nouveaux blocs, ce qu'ajuste la difficulté, et pourquoi les règles tiennent sans personne aux commandes.
- Protocole et mises à jourSegWit, Taproot, soft forks et BIP : comment le bitcoin évolue et qui en décide.
- Lightning et couche 2Canaux de paiement, factures et routage, pour déplacer du bitcoin sans payer de place dans un bloc.
- Réglementation et fiscalitéKYC, règle de voyage, MiCA et plus-values : les règles qui touchent votre compte et votre déclaration d'impôts.
- Culture et histoireMt. Gox, le bloc de genèse, HODL, et les événements et l'argot qui ont façonné la façon de parler du bitcoin.
- Nœuds et logicielsBitcoin Core, nœuds complets, élagage et RPC : le logiciel qui fait respecter les règles.
Questions fréquentes
À qui s'adresse cette section ?
À quiconque lit le code source du bitcoin, décode une transaction brute ou travaille avec le protocole P2P et l'interface RPC. C'est la couche de référence plutôt que la couche d'achat, et rien de tout cela n'est nécessaire pour posséder ou dépenser du bitcoin.
Qu'est-ce que Bitcoin Script ?
Le petit langage à pile qui décide si une pièce peut être dépensée. Il n'a pas de boucles, volontairement, ce qui rend le coût de chaque script prévisible avant son exécution. La plupart des transactions utilisent l'un d'une poignée de modèles standard.
Pourquoi l'ordre des octets change-t-il sans cesse ?
Parce que le bitcoin affiche les hachages dans l'ordre inverse de celui dans lequel il les stocke. L'ordre interne des octets est celui qu'utilise le protocole, tandis que la sortie RPC et les explorateurs de blocs l'inversent. Mélanger les deux est le premier bug classique.
Où se trouve la documentation qui fait autorité ?
Dans le code source et dans les BIP plutôt que sur un site particulier. Les entrées présentées ici citent la spécification quand elle existe, et corrigent l'ancienne documentation pour développeurs là où elle n'est plus à jour plutôt que de la répéter.