
Bitcoin Core diskutiert, die Unterstützung für das verschlüsselte Routing-Netzwerk CJDNS künftig einzustellen. Hintergrund ist die geringe Zahl verfügbarer Knoten, die CJDNS-only-Knoten einem erhöhten Eclipse-Risiko aussetzen könnte. Die Debatte zeigt den Zielkonflikt zwischen zusätzlicher Netzwerkdiversität und einem kleinen Peer-Pool.
Dünne Knotenpopulation löst GitHub-Debatte aus
Auslöser ist eine öffentliche Diskussion im GitHub-Issue #36041 des Bitcoin-Core-Projekts. Laut CryptoSlate enthielt die Datenbank eines Seeders 25 CJDNS-Adressen. Von diesen wurden 22 erreicht, während nur sieben die strengeren Kriterien für „gute“ Knoten erfüllten.

Dieselbe Berichterstattung verweist auf lediglich drei bis vier Peers, obwohl Bitcoin Core elf feste CJDNS-Seeds mitliefert. Die Zahlen haben die Diskussion über eine Abschaffung der Unterstützung befördert. Im Raum steht eine Warnung in einer 32.x-Version und eine mögliche Entfernung in 33.x. Dieser Ablauf war jedoch als Frage formuliert und ist nicht beschlossen. Nach Angaben von CryptoSlate war das Issue am Sonntag, 23. August, weiterhin offen; ein Implementierungs-Branch oder Pull Request war nicht verknüpft.
Warum der kleine Peer-Pool im Fokus steht
Ein Eclipse-Angriff zielt darauf, einen Knoten von anderen Teilnehmern abzuschirmen, indem ein Angreifer dessen Verbindungen kontrolliert. In der CJDNS-Debatte geht es deshalb um die Frage, ob ein kleiner Adresspool CJDNS-only-Knoten leichter umgeben könnte. CJDNS ist in Bitcoin Core ein optionaler Transport- und Mechanismus zur Adressverarbeitung außerhalb des Bitcoin-Konsenssystems.
Die sieben als gut eingestuften Knoten bilden dabei nur eine Momentaufnahme aus der Datenbank eines einzelnen Crawlers ab. Die weltweite CJDNS-Population kann größer sein. Zudem nutzt der Seeder für die Einstufung als guter Knoten strengere technische Kriterien als die bloße Erreichbarkeit. Die geringe Zahl in dieser Erhebung beschreibt daher einen begrenzten nutzbaren Pool, nicht zwingend die gesamte Zahl der CJDNS-Knoten.
Parallel: Bitcoin Core testet Version 31.1rc1
Unabhängig von der CJDNS-Debatte hat das Bitcoin-Core-Projekt am 29. Juni 2026 die Testversion 31.1rc1 veröffentlicht. Laut den Release Notes behebt sie eine Datenschutzlücke in der PrivateBroadcast-Funktion. Unter bestimmten Netzwerkbedingungen konnte dabei die IP-Adresse eines Nutzers über eine Verbindung außerhalb des vorgesehenen Privacy-Netzwerks sichtbar werden.

Die Version enthält außerdem Änderungen bei Blockchain-Validierung, Wallet-Funktionen, Netzwerkverhalten und der Sicherheit von MuSig2. So wurden unter anderem Schätzungen der Transaktionsgröße in Wallets verfeinert und zusätzliche Prüfungen für ungültige Public-Key-Listen in MuSig2 ergänzt. Wie crypto.news berichtet, bittet das Projekt die Community, den Release Candidate vor der stabilen Veröffentlichung zu testen und mögliche Fehler zu melden.
Optionale verschlüsselte Verbindungen in Version 30.0
Die CJDNS-Diskussion fällt in eine Phase weiterer Netzwerk- und Datenschutzentwicklungen bei Bitcoin Core. Version 30.0 führte laut CoinMarketCap optionale verschlüsselte Verbindungen zwischen Knoten ein. Dieser Schritt ist von der aktuellen Frage über die CJDNS-Unterstützung zu trennen: Die Diskussion betrifft den Fortbestand eines bestimmten optionalen Transportwegs und dessen kleinen Peer-Pool.
Was das für Node-Betreiber bedeutet
Solange keine Entscheidung getroffen und keine Änderung im Bitcoin-Core-Code umgesetzt ist, bleibt CJDNS-Unterstützung Teil der laufenden Debatte. Besonders relevant ist sie für Betreiber von Knoten, die ausschließlich über CJDNS verbunden sind, weil sich ihre verfügbaren Peers aus dem dortigen Pool speisen.
Wer einen eigenen Bitcoin-Knoten betreibt, kann die weitere Entwicklung des GitHub-Issues #36041 sowie die Testphase von 31.1rc1 verfolgen. Derzeit handelt es sich bei den Überlegungen zu CJDNS um einen offenen Vorschlag, nicht um eine beschlossene Änderung.
Zuletzt aktualisiert am 24. August 2026




Fragen und Antworten
Sie haben eine Frage? Unser Experten-Panel beantwortet gerne Ihre Fragen.