Bitcoin Core envisage de supprimer le support du routage chiffré alors qu'une mauvaise santé des nœuds expose les utilisateurs à des attaques d'éclipse

Les contributeurs de Bitcoin Core examinent si un transport réseau peu utilisé offre une assurance précieuse ou est devenu une responsabilité trop coûteuse à conserver.

Dans la discussion ouverte sur le support de CJDNS, le membre de Bitcoin Core Andrew Chow a déclaré qu'une base de données de semeurs contenait 25 adresses CJDNS, en avait atteint 22 et n'en avait classé que sept comme bonnes. L'auteur du problème, Martin Zumsande, a rapporté n'avoir vu que trois à quatre pairs bien que Bitcoin Core soit livré avec 11 semeurs CJDNS fixes.

Ces chiffres ont suscité un soutien pour la dépréciation et une suggestion que Bitcoin Core avertisse les utilisateurs dans une version 32.x avant de planifier la suppression dans 33.x. Mais cette séquence de version a été posée comme une question. Au dimanche 23 août, le problème restait ouvert dans le jalon 32.0, avec sa section Développement vide d'une branche d'implémentation ou d'une demande de tirage.

Bitcoin Core implémente CJDNS comme un transport et un traitement d'adresses pair-à-pair optionnels, en dehors du système de consensus de Bitcoin. Le problème #36041 demande plutôt si Bitcoin Core devrait conserver le traitement des adresses CJDNS comme une solution de secours lorsque le pool de pairs mince pourrait également rendre les nœuds uniquement CJDNS plus faciles à entourer.

Les sept bons nœuds de Bitcoin Core capturent un instantané d'un semeur

Les chiffres des semeurs décrivent la base de données d'un crawler à un moment donné. La population mondiale de CJDNS peut être plus grande car le chiffre ne couvre que la base de données de ce crawler.

Le semeur applique "bon" comme un filtre technique plus strict que la connectivité. Dans l'implémentation DNSSeedrs de Chow, un nœud doit passer des vérifications couvrant son port, le service réseau annoncé, la version du protocole, la hauteur de la chaîne et la fiabilité en cours. Les tests de fiabilité utilisent plusieurs fenêtres temporelles et nécessitent des comptes d'essai minimums. Cela explique comment le semeur a pu atteindre 22 adresses tout en ne classant que sept comme bonnes.

Seules sept des 22 adresses atteintes ont franchi les filtres de bons nœuds, laissant le pool utilisable peu profond. Le nœud de Zumsande n'a trouvé que trois ou quatre pairs, et il a proposé des chiffres à trois chiffres bas comme un niveau approximatif qui pourrait justifier un soutien continu. Le seuil à trois chiffres bas était uniquement celui de Zumsande, donnant aux mainteneurs un chiffre sur lequel discuter au lieu d'une simple plainte générale concernant une faible utilisation.

L'arithmétique du nombre de pairs laisse le coût d'éclipse inconnu. Bitcoin Core maintient normalement huit connexions sortantes de relais complets et deux connexions de relais de blocs uniquement, avec un contact occasionnel ou une connexion de relais de blocs supplémentaire. Un contributeur a suggéré de fonder tout seuil CJDNS sur le coût de remplissage de ces emplacements réguliers et d'éclipser un nœud uniquement CJDNS.

Une attaque d'éclipse isole un nœud en monopolisant les pairs qui façonnent sa vue du réseau. Sur un transport avec un petit ensemble d'adresses connues, un attaquant a une cible plus concentrée. La documentation actuelle de CJDNS de Bitcoin Core décourage déjà l'opération uniquement CJDNS car un nœud peut échouer à remplir ses emplacements sortants, essayer à plusieurs reprises les quelques adresses qu'il connaît et devenir plus susceptible aux attaques Sybil.

Une éclipse réussie dépend de plus que des dix emplacements sortants réguliers. La discussion publique laisse le coût total de l'attaque non quantifié. La disponibilité des adresses, la sélection des adresses, la fiabilité des crawlers et les connexions sortantes supplémentaires occasionnelles affectent tous l'exposition pratique. Le pool mesuré soutient une préoccupation de concentration pour les nœuds uniquement CJDNS, tandis que le coût d'exploitation de cette préoccupation reste non quantifié.

La redondance dépend de la manière dont CJDNS est utilisé

CJDNS offre une proposition différente lorsqu'il est un chemin parmi plusieurs. La documentation de Bitcoin Core le présente comme une option complémentaire aux côtés de l'IPv4, de l'IPv6, de Tor et de l'I2P, permettant à un nœud de garder une autre route disponible si un réseau rencontre des problèmes.

Cette option est devenue plus facile à utiliser. CJDNS 22.1 a introduit l'auto-peering par semence DNS le 8 janvier 2025, rendant l'ajout manuel de pairs optionnel. Bitcoin Core a ensuite fusionné la documentation de configuration mise à jour le 30 mars 2026, remplaçant les instructions de peering manuel obsolètes par le nouveau flux.

Ces changements ont réduit la friction de configuration. Tout effet sur la population de pairs CJDNS de Bitcoin reste non mesuré. Bitcoin Core a fusionné un autre changement de documentation le 18 août 2026, décourageant explicitement l'utilisation uniquement CJDNS car le pool d'adresses restait trop petit pour remplir les emplacements sortants de manière fiable.

Les opérateurs uniquement CJDNS et ceux de réseaux mixtes font donc face à des enjeux différents. Un opérateur uniquement CJDNS fait face au risque de pool mince que la documentation avertit désormais. Un opérateur de réseau mixte utilise CJDNS pour la diversité de route optionnelle et peut conserver d'autres chemins automatiques même lorsque CJDNS a peu de pairs.

Une future dépréciation supprimerait les paramètres de transport tout en laissant les règles de validité des blocs inchangées. Bitcoin Core a ajouté un support complet de CJDNS dans la version 23.0 en tant que fonctionnalité de mise en réseau P2P. Le débat est limité au traitement des adresses et aux options de connexion ; les règles de consensus et de validité des blocs de Bitcoin sont en dehors de son champ d'application.

Les opérateurs directement affectés seraient ceux utilisant -cjdnsreachable, qui indique à Bitcoin Core de traiter la plage IPv6 pertinente comme CJDNS, ou -onlynet=cjdns, qui limite les connexions sortantes automatiques à ce transport. La même option peut actuellement être combinée avec d'autres réseaux, tandis que les connexions entrantes et ajoutées manuellement restent disponibles sous -onlynet, selon la documentation.

Le problème #36041 reste ouvert, avec l'avertissement et la séquence de suppression enregistrés uniquement comme une proposition. Il montre un petit ensemble de pairs observés, plusieurs expressions de soutien à la dépréciation et une séquence de publication proposée. Il montre également pourquoi un simple compte d'utilisation est un test incomplet : la capacité de sauvegarde est la plus précieuse avant qu'une route principale échoue, mais un réseau de sauvegarde qui échoue à remplir les connexions peut offrir moins de résilience que sa présence dans le code ne le suggère.

Bitcoin Core prend toujours en charge CJDNS. Une demande de tirage d'avertissement ou de suppression fusionnée changerait le statut du débat. Sept bons nœuds rendent le compromis de diversité de transport mesurable et laisse le choix de suppression ouvert.

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.