In der Bitcoin-Core-Entwicklung wird diskutiert, ob der optionale Netzwerktransport CJDNS aus der Software entfernt werden sollte. Grund ist ein auffällig dünner Peer-Pool, der CJDNS-only-Knoten laut einem offenen GitHub-Issue anfälliger für sogenannte Eclipse-Angriffe machen könnte, bei denen ein Angreifer das Netzwerkbild eines Ziel-Knotens vollständig kontrolliert.
Das Wichtigste im Überblick:
- Bitcoin Core diskutiert eine mögliche Degradierung oder Entfernung der CJDNS-Unterstützung, Issue #36041 ist derzeit offen
- Eine Seeder-Datenbank verzeichnete nur 7 von 22 Adressen als „good“, obwohl Bitcoin Core 11 feste CJDNS-Seeds mitliefert
- Die Blockvalidität und Konsensregeln sind von der Debatte nicht betroffen, es geht ausschließlich um die Peer-zu-Peer-Ebene
- Bis zum 23. August blieb die 32.0-Milestone-Planung unverändert, ein konkreter Zeitplan für eine Entfernung existiert nicht
Was genau zur Debatte steht
Auslöser der Diskussion ist ein offener Support-Thread zur CJDNS-Seeder-Infrastruktur. Dort wird berichtet, dass eine Seeder-Datenbank ursprünglich 25 CJDNS-Adressen hielt, dann auf 22 zurückfiel, während lediglich sieben als „good“ eingestuft wurden. Der Issue-Autor meldete aus eigener Beobachtung sogar nur drei bis vier tatsächlich erreichbare Peers, obwohl Bitcoin Core standardmäßig 11 feste CJDNS-Seeds mitliefert.
Entscheidend ist dabei die Definition von „good“: Der Filter prüft nicht nur die reine Erreichbarkeit, sondern auch Port, beworbenen Netzwerkdienst, Protokollversion, Chain-Height und eine Rolling-Reliability über mehrere Zeitfenster hinweg. Ein Knoten muss also über längere Zeit zuverlässig antworten, um als vertrauenswürdig zu gelten – was den effektiv nutzbaren Pool deutlich kleiner macht als die reine Adressanzahl vermuten lässt.
Warum ein dünner Pool für Eclipse-Angriffe relevant ist
Bitcoin Core hält in der Regel acht Full-Relay-Outbound-Verbindungen sowie zwei Block-Relay-only-Verbindungen offen, gelegentlich ergänzt durch zusätzliche Feeler- oder Block-Relay-Slots. Kann ein Angreifer diese Slots gezielt über einen kleinen, gut kartierbaren Adresssatz füllen, steigt das Risiko, dass ein Ziel-Knoten fast ausschließlich mit vom Angreifer kontrollierten Peers kommuniziert. Wie hoch der tatsächliche Angriffspreis dafür liegt, bleibt in der öffentlichen Diskussion allerdings offen – die Debatte stützt sich bislang auf Beobachtungen zum Pool, nicht auf belastbare Kostenrechnungen.
Wichtig ist die Abgrenzung: Es geht ausschließlich um die Adress- und Verbindungslogik außerhalb des Konsenssystems. Blockvalidität und Konsensregeln von Bitcoin bleiben von der CJDNS-Frage vollständig unberührt.
CJDNS als Redundanz – und ihre Grenzen
In der Dokumentation positioniert Bitcoin Core CJDNS als komplementäre Option neben IPv4, IPv6, Tor und I2P – als zusätzlichen Weg, falls ein bestimmtes Netz gerade ausfällt. Dieses Redundanzargument funktioniert aber vor allem dann, wenn CJDNS nur einer von mehreren Transportwegen im Mischbetrieb ist. Wer CJDNS ausschließlich über die Option -onlynet=cjdns nutzt, trägt laut der Diskussion das größere Risiko: Bei einem zu kleinen Pool kann eine Node ihre Outbound-Slots nicht zuverlässig auffüllen und greift wiederholt auf dieselben wenigen bekannten Adressen zurück, was sie sowohl für Sybil- als auch für Eclipse-Angriffe anfälliger macht. Betreiber im Mischbetrieb profitieren dagegen davon, dass andere Netzpfade weiterhin automatisch verfügbar bleiben.
Für Node-Betreiber, die sich generell mit Sicherheitsfragen ihrer Infrastruktur befassen, reiht sich die Debatte in eine Serie ähnlicher Themen ein – etwa die kürzlich diskutierte BTCPay-Server-Sicherheitslücke oder Berichte über Schwachstellen bei Coldcard-Wallets, die zeigen, wie sehr die Sicherheit einzelner Komponenten von sorgfältiger Konfiguration abhängt.
Was als Nächstes zu beobachten ist
Ein fester Plan existiert bislang nicht. Das zugrundeliegende Issue #36041 ist weiterhin offen, und die im Thread diskutierte Warn- und Entferner-Pipeline ist als Vorschlag formuliert, nicht als Beschluss. Bis zum 23. August blieb die 32.0-Milestone-Planung unverändert, ohne sichtbare Implementierungszweige oder Pull Requests.
- Warnhinweis: Ob eine Warnung bereits in einer 32.x-Version erscheint, ist noch offen und Gegenstand der Diskussion.
- Mögliche Entfernung: Eine Deprecation in einer 33.x-Version wurde als Option genannt, ist aber nicht beschlossen.
- Betroffene Optionen: Direkt betroffen wären die Konfigurationsoptionen -cjdnsreachable und -onlynet=cjdns.
Bitcoin Core unterstützt CJDNS nach aktuellem Stand weiterhin unverändert. Erst ein konsolidierter Warntext oder ein konkreter Entferner-Pull-Request im Entwicklungszweig würde die Richtung der Entscheidung festzurren, wie aus dem Bericht von IT Boltwise hervorgeht.
Warum Sie 99Bitcoins vertrauen können
99Bitcoins wurde 2013 gegründet und verfügt über ein Team von Experten, deren Erfahrung bis in die Anfänge der Kryptozeit zurückreicht.
Wöchentliche Recherche
100k+Monatliche Leser
Experten
2000+Krypto-Projekte unter die Lupe genommen
