Glossaire / Nœuds et logiciels
Transport chiffré BIP-324
Aussi appelé v2 transport.
- Qu'est-ce que le transport chiffré BIP-324 ?
- Le transport chiffré BIP-324 est la version 2 du protocole de liaison pair-à-pair de bitcoin, qui chiffre chaque message échangé entre deux nœuds et rend la connexion indistinguable de données aléatoires pour un observateur.
Spécifié dans BIP-324.
Deux nœuds qui prennent tous deux en charge BIP-324 lancent un échange de clés éphémères avant qu'aucun message Bitcoin ne soit envoyé, puis enveloppent chaque message dans ChaCha20Poly1305. La spécification a été marquée finale le 10 juillet 2024, et un nœud annonce sa prise en charge avec le drapeau de service NODE_P2P_V2, le bit 11. Rien ne change pour vos bitcoins : ce qui change, c'est qu'un observateur passif ne peut plus lire les transactions que votre nœud fait circuler.
Comment cela fonctionne
BIP-324 remplace les octets magiques fixes qui ouvraient autrefois une connexion bitcoin par un flux qui n'a aucune forme reconnaissable.
Le côté qui se connecte génère une clé secp256k1 jetable et envoie l'encodage ElligatorSwift de 64 octets de sa clé publique. Cet encodage est l'astuce : une clé publique ordinaire est identifiable comme point de courbe, tandis que toute chaîne de 512 bits est un encodage ElligatorSwift valide, donc les octets d'ouverture ne sont statistiquement que du bruit. Chaque côté peut ensuite ajouter jusqu'à 4095 octets de remplissage arbitraire, appelé garbage, pour qu'une connexion ne commence pas forcément par exactement 64 octets. Les deux extrémités exécutent un ECDH X-only et font passer le résultat par HKDF-SHA256 pour dériver quatre clés de chiffrement, deux terminateurs de garbage de 16 octets et un identifiant de session.
Ces octets d'ouverture sont la seule partie de l'échange envoyée en clair. Après les terminateurs, tout ce qui circule est constitué de paquets. Un paquet se compose d'un champ de longueur chiffré de 3 octets suivi d'un texte chiffré ChaCha20Poly1305 couvrant un en-tête de 1 octet et le contenu, soit 20 octets plus la charge utile. Le bit de poids fort de cet en-tête est le bit d'ignorance, et un paquet qui le porte est un leurre : le destinataire vérifie qu'il se déchiffre puis le rejette, ce qui permet à un nœud de bourrer son trafic pour masquer le moment où un vrai message est parti. Les clés avancent par paliers tous les 224 paquets, un intervalle choisi pour qu'une liaison presque inactive qui n'envoie que des pings de 20 minutes change de clés environ tous les 3,11 jours, et ce mécanisme donne à une session sa confidentialité persistante.
La conception s'arrête délibérément avant de prouver qui se trouve à l'autre bout. Il n'y a ni certificats ni identités, donc un homme du milieu déterminé peut toujours s'interposer entre deux nœuds. Ce qu'il ne peut pas faire, c'est s'y installer à bon compte ou de façon invisible : l'identifiant de session découle de l'échange de clés, et deux opérateurs qui se lisent mutuellement le leur verront des valeurs différentes dès que quelqu'un s'interpose.
Où le voit-on
BIP-324 ne laisse rien sur la blockchain, le seul endroit où il apparaît est donc entre deux nœuds en fonctionnement.
La prise en charge est annoncée dans le gossip d'adresses par le drapeau NODE_P2P_V2 que les pairs apprennent des messages addr et addrv2. Ces drapeaux passent par des relais non fiables et sont combinés par OR, donc une fausse annonce est possible, et le BIP encourage un client v2 qui est déconnecté immédiatement à réessayer le même pair en v1. Dans l'autre sens, un nœud v2 continue volontairement d'accepter les connexions entrantes v1, pour éviter que le réseau ne se scinde en deux moitiés incapables de communiquer.
Le second effet visible est que les messages sont plus courts. La version 1 dépensait 12 octets ASCII pour chaque nom de commande ; la version 2 attribue des identifiants d'un octet aux 28 types de messages définis jusqu'ici, donc inv est l'octet unique 14 et getblocktxn est 10, et tout message utilisant un identifiant court coûte 3 octets de moins que sa forme v1. Tout ce qui n'a pas d'identifiant attribué retombe sur un encodage de 13 octets, un octet zéro suivi de l'ancien nom ASCII, donc rien n'est perdu.
La spécification porte le statut Deployed, livre des vecteurs de test et une implémentation de référence naïve en Python destinée uniquement à la démonstration, et elle est encore modifiée : la révision 1.0.2 du 30 janvier 2026 a ajouté un tableau d'identifiants de types de messages dans un fichier auxiliaire, pour que d'autres BIP puissent réclamer des identifiants sans modifier le document principal. L'en-tête indique aussi que BIP-324 remplace BIP-151.