Die Mitwirkenden von Bitcoin Core wägen ab, ob ein dünn genutzter Netzwerktransport wertvolle Absicherung bietet oder zu einer zu kostspieligen Haftung geworden ist, um ihn beizubehalten.
In der offenen Diskussion zur Unterstützung von CJDNS sagte das Mitglied von Bitcoin Core, Andrew Chow, dass eine Seeder-Datenbank 25 CJDNS-Adressen enthielt, 22 erreicht hatte und nur sieben als gut klassifiziert wurden. Der Autor des Problems, Martin Zumsande, berichtete, dass er nur drei bis vier Peers gesehen habe, obwohl Bitcoin Core mit 11 festen CJDNS-Seedern ausgeliefert wird.
Diese Zahlen haben die Unterstützung für die Abwertung angeregt und einen Vorschlag hervorgebracht, dass Bitcoin Core die Benutzer in einer Version 32.x vor der geplanten Entfernung in 33.x warnen sollte. Aber diese Versionsfolge wurde als Frage formuliert. Am Sonntag, den 23. August, blieb das Problem im Meilenstein 32.0 offen, wobei der Entwicklungsbereich leer von einem Implementierungszweig oder Pull-Request war.
Bitcoin Core implementiert CJDNS als optionalen Peer-to-Peer-Transport und Adressverwaltung, außerhalb des Konsenssystems von Bitcoin. Problem #36041 fragt stattdessen, ob Bitcoin Core die CJDNS-Adressverwaltung als Rückfalloption beibehalten sollte, wenn der dünne Peer-Pool auch CJDNS-nur Knoten leichter umgeben könnte.
Die Seeder-Zahlen beschreiben die Datenbank eines Crawlers zu einem bestimmten Zeitpunkt. Die globale CJDNS-Population könnte größer sein, da die Zahl nur die Datenbank dieses Crawlers abdeckt.
Der Seeder wendet "gut" als strengeren technischen Filter als die Erreichbarkeit an. In Chows DNSSeedrs-Implementierung muss ein Knoten Prüfungen bestehen, die seinen Port, den beworbenen Netzwerkdienst, die Protokollversion, die Kettenhöhe und die laufende Zuverlässigkeit abdecken. Die Zuverlässigkeitstests verwenden mehrere Zeitfenster und erfordern Mindestversuchsanzahlen. Das erklärt, wie der Seeder 22 Adressen erreichen konnte, während nur sieben als gut klassifiziert wurden.
Nur sieben der 22 erreichten Adressen haben die Filter für gute Knoten bestanden, was den nutzbaren Pool flach lässt. Zumsandes Knoten fand nur drei oder vier Peers, und er bot niedrige dreistellige Zahlen als grobe Ebene an, die eine fortgesetzte Unterstützung rechtfertigen könnte. Der niedrige dreistellige Benchmark war allein Zumsandes, was den Betreuern eine Zahl gab, über die sie streiten konnten, anstatt nur eine allgemeine Beschwerde über die geringe Nutzung.
Die Berechnung der Peer-Zahl allein lässt die Kosten für den Eclipse-Angriff unbekannt. Bitcoin Core pflegt normalerweise acht vollständige Relay-Ausgangsverbindungen und zwei Block-Relay-nur Verbindungen, mit gelegentlichen Fühlern oder zusätzlichen Block-Relay-nur Verbindungen. Ein Mitwirkender schlug vor, einen CJDNS-Schwellenwert an den Kosten für das Füllen dieser regulären Slots und das Eklipsieren eines CJDNS-nur Knotens zu orientieren.
Ein Eclipse-Angriff isoliert einen Knoten, indem er die Peers monopolisiert, die seine Sicht auf das Netzwerk prägen. Bei einem Transport mit einer kleinen bekannten Adressmenge hat ein Angreifer ein konzentrierteres Ziel. Die aktuelle CJDNS-Dokumentation von Bitcoin Core rät bereits von einem CJDNS-nur Betrieb ab, da ein Knoten möglicherweise nicht in der Lage ist, seine Ausgangsslots zu füllen, wiederholt die wenigen Adressen versucht, die er kennt, und anfälliger für Sybil-Angriffe wird.
Ein erfolgreicher Eclipse hängt von mehr als nur den zehn regulären Ausgangsslots ab. Die öffentliche Diskussion lässt die vollen Angriffskosten unquantifiziert. Die Verfügbarkeit von Adressen, die Adressenauswahl, die Zuverlässigkeitsgates des Crawlers und gelegentliche zusätzliche Ausgangsverbindungen beeinflussen alle die praktische Exposition. Der gemessene Pool unterstützt ein Konzentrationsproblem für CJDNS-nur Knoten, während die Kosten für die Ausnutzung dieses Problems unquantifiziert bleiben.
CJDNS bietet ein anderes Angebot, wenn es ein Weg unter mehreren ist. Die Dokumentation von Bitcoin Core präsentiert es als ergänzende Option neben IPv4, IPv6, Tor und I2P, sodass ein Knoten einen anderen Weg verfügbar halten kann, wenn ein Netzwerk Probleme hat.
Diese Option ist einfacher zu nutzen geworden. CJDNS 22.1 führte am 8. Januar 2025 DNS-seeded Auto-Peering ein, wodurch die manuelle Peer-Hinzufügung optional wurde. Bitcoin Core fusionierte dann aktualisierte Einrichtungsdokumentation am 30. März 2026 und ersetzte veraltete Anweisungen zur manuellen Peering durch den neueren Ablauf.
Diese Änderungen reduzierten die Einrichtungsreibung. Jegliche Auswirkungen auf die CJDNS-Peer-Population von Bitcoin bleiben ungemessen. Bitcoin Core fusionierte eine weitere Dokumentationsänderung am 18. August 2026, die ausdrücklich von der Nutzung von CJDNS-nur abriet, da der Adresspool weiterhin zu klein blieb, um die Ausgangsslots zuverlässig zu füllen.
CJDNS-nur und gemischte Netzwerkbetreiber stehen daher vor unterschiedlichen Einsätzen. Ein CJDNS-nur Betreiber sieht sich dem Risiko eines dünnen Pools gegenüber, vor dem die Dokumentation jetzt warnt. Ein gemischter Netzwerkbetreiber nutzt CJDNS für optionale Routenvielfalt und kann andere automatische Wege beibehalten, selbst wenn CJDNS nur wenige Peers hat.
Eine zukünftige Abwertung würde die Transporteinstellungen entfernen, während die Regeln zur Blockgültigkeit unverändert bleiben. Bitcoin Core fügte in Version 23.0 die vollständige CJDNS-Unterstützung als P2P-Netzwerkfunktion hinzu. Die Debatte beschränkt sich auf die Adressverwaltung und Verbindungsoptionen; die Konsens- und Blockgültigkeitsregeln von Bitcoin liegen außerhalb ihres Rahmens.
Die direkt betroffenen Betreiber wären diejenigen, die -cjdnsreachable verwenden, was Bitcoin Core anweist, den relevanten IPv6-Bereich als CJDNS zu behandeln, oder -onlynet=cjdns, was die automatischen Ausgangsverbindungen auf diesen Transport beschränkt. Dieselbe Option kann derzeit mit anderen Netzwerken kombiniert werden, während eingehende und manuell hinzugefügte Verbindungen unter -onlynet weiterhin verfügbar bleiben, gemäß der Dokumentation.
Problem #36041 bleibt offen, wobei die Warnung und die Entfernung nur als Vorschlag aufgezeichnet sind. Es zeigt einen kleinen beobachteten Peer-Satz, mehrere Unterstützungsbekundungen für die Abwertung und eine vorgeschlagene Veröffentlichungsfolge. Es zeigt auch, warum eine Nutzungszahl allein ein unvollständiger Test ist: Backup-Kapazität ist am wertvollsten, bevor ein primärer Weg ausfällt, aber ein Backup-Netzwerk, das nicht in der Lage ist, Verbindungen zu füllen, bietet möglicherweise weniger Resilienz, als es der Code vermuten lässt.
Bitcoin Core unterstützt weiterhin CJDNS. Ein zusammengeführter Warn- oder Entfernungs-Pull-Request würde den Status der Debatte ändern. Sieben gute Knoten machen den Handelsausgleich der Transportvielfalt messbar und lassen die Wahl der Entfernung offen.
Dieser Inhalt wird nur zu allgemeinen Informationszwecken bereitgestellt und stellt keine finanzielle, Anlage-, Rechts- oder Steuerberatung dar. Alle erwähnten Ereignisse, Prämien, Online-Aktionen oder zugehörige Informationen sollten nicht als Empfehlung, Aufforderung oder Einladung zum Kauf, Verkauf, Handel oder anderweitigem Umgang mit Krypto-Assets betrachtet werden. Krypto-Assets sind sehr volatil und können zu Verlusten führen. Die Verfügbarkeit von WEEX Services, Produkten und zugehörigen Aktionen kann je nach Region unterschiedlich sein. Sie sind dafür verantwortlich sicherzustellen, dass Ihre Teilnahme mit geltenden lokalen Gesetzen und Vorschriften übereinstimmt.





























