Es wurde kein Code entfernt und keine endgültige Entscheidung getroffen, doch die anhaltend niedrige Nutzung hat die Bitcoin-Core-Mitwirkenden dazu veranlasst, die praktischen Sicherheits- und Engineering-Abwägungen bei der Pflege von Legacy-Overlay-Netzwerken im Haupt-Bitcoin-Client erneut zu prüfen — eine Debatte, die sich inzwischen darum dreht, ob das verschlüsselte Routing-Netzwerk CJDNS seinen Platz in der Referenzimplementierung noch rechtfertigt.

Sieben „gute“ Nodes lösen eine breitere Infrastrukturprüfung aus

Die technische Diskussion begann in einem offenen GitHub-Issue, in dem Entwickler infrage stellten, ob Bitcoin Core eine verschlüsselte Routing-Schicht weiterhin unterstützen sollte, die fast keinen dokumentierten Verkehr aus der Praxis aufweist. Das Kernziel der Hinzufügung alternativer Netzwerk-Transportschichten zu Bitcoin ist Redundanz: die Verhinderung einzelner Ausfall- oder Zensurpunkte auf Netzwerkebene. Redundante Routen funktionieren jedoch nur, wenn sich ein aktives Mesh von Peers am zugrunde liegenden Netzwerk beteiligt.

Bei automatisierten Tests eines reinen CJDNS-Node-Setups berichtete der Core-Entwickler Marco Falke, dass seine Instanz zu keinem Zeitpunkt Verbindungen zu mehr als drei oder vier verschiedenen Peers aufbauen konnte. Als Reaktion auf diese Beobachtung befragte ein anderer Mitwirkender eine etablierte Netzwerk-Seeder-Datenbank — die Bootstrap-Dienste, die neu gestarteten Nodes ihre ersten Peer-Adressen übergeben —, die 25 bekannte CJDNS-Adressen enthielt. Von den 25 getesteten Adressen reagierten 22 auf grundlegende Handshakes, aber nur sieben erfüllten die technischen Kriterien, um als zuverlässige „gute“ Peers für die aktive Block- und Transaktionsweitergabe eingestuft zu werden.

Eine einzelne Seeder-Abfrage stellt keine absolute Bestandsaufnahme aller betriebenen Nodes im gesamten CJDNS-Ökosystem dar; private, nicht beworbene Nodes und nicht indizierte Peers können außerhalb öffentlicher Seeder-Listen weiterhin existieren. Dennoch unterstreichen die Zahlen eine ernste praktische Realität: Ein Overlay-Netzwerk mit weniger als einem Dutzend erreichbarer Routing-Ziele bietet nicht die betriebliche Redundanz, die von einem widerstandsfähigen Produktions-Node gefordert wird. Zur Einordnung: Langlaufende öffentliche Crawler haben per Tor beworbene, erreichbare Bitcoin-Nodes im niedrigen vierstelligen Bereich gezählt — verglichen mit den 25 Adressen, die der CJDNS-Seeder vorhält.

CJDNS verstehen: verschlüsseltes IPv6-Routing vs. Konsensregeln

CJDNS ist ein verschlüsseltes IPv6-Mesh-Netzwerk-Overlay, das Public-Key-Kryptografie für die Adressvergabe und das verteilte Routing verwendet. Außerhalb von Bitcoin ist das Protokoll vor allem als Routing-Schicht von Hyperboria bekannt, einem von Freiwilligen betriebenen Community-Mesh-Netzwerk. Bitcoin Core fügte in Version 23.0 im Jahr 2022 native CJDNS-Unterstützung hinzu, womit Node-Betreiber Peer-Verkehr über CJDNS neben IPv4, IPv6, Tor und I2P leiten können.

Laut der Dokumentation von Bitcoin Core verschlüsselt CJDNS den Datenverkehr Ende-zu-Ende und kann Verkehrsanalyse und Filterung erschweren. Es ist jedoch kein Anonymitätsnetzwerk im gleichen Sinne wie Tor: Zwischengeschaltete CJDNS-Router können weiterhin die kryptografischen Quell- und Zieladressen der von ihnen weitergeleiteten Pakete einsehen.

Der Vorschlag betrifft ausschließlich, wie Bitcoin Core Peers findet und sich mit ihnen verbindet. Eine Entfernung der CJDNS-Unterstützung würde die Blockvalidierung, das Mining, die Skriptregeln oder die Transaktionsformate nicht ändern; die Nodes würden weiterhin dieselben Bitcoin-Konsensregeln durchsetzen.

Die Sicherheitsmechanik eines Eclipse-Angriffs

In der Sicherheit von Bitcoin-Nodes sind Netzwerktransport und Peer-Auswahl unmittelbar mit der Datenintegrität verknüpft. Verschlüsselung verbirgt Paketinhalte vor Dritten, schützt aber nicht davor, dass ein Node mit falschen oder verzögerten Informationen versorgt wird, wenn seine Peer-Auswahl zu eingeschränkt ist. Dünne Peer-Pools untergraben die Sicherheit, indem sie es böswilligen Akteuren drastisch erleichtern, reine CJDNS-Nodes zu isolieren und zu manipulieren.

Die Hauptbedrohung für isolierte Nodes ist ein Eclipse-Angriff. Bei einem Eclipse-Angriff kompromittiert oder kontrolliert ein Angreifer sämtliche Peer-Verbindungen, die ein Ziel-Node aufgebaut hat. Indem der Angreifer den Ziel-Node vollständig umgibt, koppelt er ihn faktisch vom legitimen globalen Bitcoin-Netzwerk ab. Von dieser Position aus kann der Angreifer die Sicht des Opfers auf die Blockchain manipulieren, indem er Blockankündigungen verzögert, bestimmte eingehende Transaktionen zensiert oder Double-Spend-Angriffe auf unbestätigte Transaktionen versucht.

Unter Standard-Routing über IPv4, IPv6 oder Tor mildert Bitcoin Core Eclipse-Angriffe ab, indem es mehrere unabhängige Verbindungen über unterschiedliche Netgroups und Netzwerkbereiche aufbaut; standardmäßig hält die Software gleichzeitig acht ausgehende Full-Relay-Verbindungen offen. Betreibt ein Node ausschließlich über ein Netzwerk mit nur sieben zuverlässigen Peers — weniger als diese standardmäßigen ausgehenden Slots —, ist der gesamte Pool verfügbarer Verbindungen viel zu klein: Ein Angreifer benötigt nur sehr wenige Ressourcen, um sämtliche ein- und ausgehenden Verbindungen eines reinen CJDNS-Nodes zu monopolisieren, und macht so einen als Sicherheits-Fallback gedachten Mechanismus zu einem erheblichen Single Point of Failure.

Codekomplexität und das Argument für die Abschaffung

Neben den niedrigen Nutzungszahlen und Sicherheitsbedenken heben Entwickler, die sich für eine Entfernung aussprechen, die laufende Wartungslast hervor, die der CJDNS-Code dem gesamten Software-Repository von Bitcoin Core auferlegt.

Anders als standardmäßige Protokoll-Handler ist die CJDNS-Integration nicht vollständig von der standardmäßigen IPv6-Verbindungslogik isoliert. Da CJDNS speziell formatierte IPv6-Adressen verwendet, erfordert die Codebasis eigene Verarbeitungslogik, dedizierte Startargumente wie -cjdnsreachable und spezialisierte Workarounds für Sonderfälle. Mit der Zeit haben Entwickler festgestellt, dass diese eigenen Logikpfade Fehlerrisiken einführen und das routinemäßige Refactoring des Netzwerk-Stacks erschweren. Auch die Transportschicht befindet sich in aktiver Entwicklung: Der verschlüsselte v2-Transport gemäß BIP 324 wurde in Version 26.0 als Option ausgeliefert und in Version 27.0 standardmäßig aktiviert — neuer Verbindungscode trifft ein, während Legacy-Pfade wie CJDNS neu bewertet werden.

Mehrere Core-Mitwirkende haben ein „Concept ACK“ für die Abschaffung des Protokolls abgegeben. In der Terminologie der Open-Source-Entwicklung von Bitcoin Core bedeutet ein „Concept ACK“, dass ein Mitwirkender das übergeordnete Ziel eines Vorschlags unterstützt; es stellt keine endgültige Abstimmung, keinen Code-Merge und keine unmittelbare Verpflichtung dar, die Funktion zu entfernen.

Das Argument für langfristige Notfallreserven

Auf der anderen Seite der Debatte argumentieren Entwickler, die zur Vorsicht mahnen, dass der Nutzen eines Netzwerks nicht ausschließlich anhand aktueller Verkehrskennzahlen beurteilt werden sollte. Der Mitwirkende Jon Atack wies darauf hin, dass die automatische CJDNS-Peer-Erkennung erst Anfang 2025 in Core integriert wurde. Vor diesem Update mussten Node-Betreiber Peer-Adressen manuell konfigurieren — ein Prozess, der im Vergleich zu den für Tor oder I2P verfügbaren Ein-Klick-Setups eine erhebliche Eintrittsbarriere darstellte.

Befürworter argumentieren, dass die geringen Nutzungszahlen von CJDNS auf mangelnde Bekanntheit bei Nutzern und eine begrenzte Integration in verbreiteten Fertig-Node-Software-Distributionen zurückzuführen sind und nicht auf einen Mangel an grundlegendem Wert. Sollten große öffentliche Anonymisierungsnetzwerke wie Tor oder I2P mit zentralisierter Blockierung, Infrastrukturausfällen oder Filterung auf Ebene von Nationalstaaten konfrontiert werden, könnten alternative Mesh-Protokolle wie CJDNS einen wichtigen Notfall-Fallback-Kanal zur Aufrechterhaltung von Peer-Verbindungen bieten.

Atack hat sich zudem bereit erklärt, den CJDNS-Integrationscode persönlich zu pflegen, und begegnet damit Bedenken hinsichtlich des Entwicklungsaufwands. Die Core-Mitwirkenden müssen nun entscheiden, ob sie eine alternative Transportroute für Notfälle in Sonderfällen bewahren oder die Codebasis durch das Entfernen wenig genutzter Netzwerklogik verschlanken.

Was eine mögliche Entfernung für Node-Betreiber bedeutet

Sollte Bitcoin Core die native CJDNS-Integration in einer künftigen Version schließlich entfernen, wird die Software schlicht aufhören, CJDNS-Peer-Verbindungen intern auf Anwendungsebene zu verwalten. Die Änderung würde Betreiber nicht daran hindern, CJDNS extern auf Betriebssystemebene zu betreiben, und sie würde auch nicht verändern, wie das breitere Bitcoin-Netzwerk Transaktionen verarbeitet.

Entfernungen in Bitcoin Core folgen üblicherweise einem langsamen, dokumentierten Verlauf — die Abschaffung wird in den Release Notes gekennzeichnet, und der Code fällt erst in einer späteren Hauptversion weg, im rund sechsmonatigen Veröffentlichungsrhythmus des Projekts —, sodass die zu beobachtenden Anzeichen der GitHub-Thread, ein formeller Deprecation-Pull-Request und die Frage sind, ob die 2025 hinzugefügte automatische Peer-Erkennung die Nutzungszahlen verändert, bevor die Maintainer entscheiden.

Für die große Mehrheit der Node-Betreiber, die auf Standardverbindungen über IPv4, IPv6, Tor oder I2P angewiesen sind, würde die Entfernung von CJDNS völlig unbemerkt vorübergehen. Die laufende Diskussion spiegelt die rigorose Engineering-Philosophie von Bitcoin Core wider: Jede Codezeile muss ihre Existenz durch bewährte Sicherheit und aktiven Nutzen rechtfertigen.

Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Anlageberatung dar.

Quelle: Coindoo