Er is nog geen code verwijderd en er is nog geen definitieve beslissing genomen, maar aanhoudend lage adoptiecijfers hebben Bitcoin Core-bijdragers gedwongen de praktische beveiligings- en engineeringafwegingen van het behoud van legacy-overlay-netwerken in de belangrijkste Bitcoin-client opnieuw te onderzoeken — een debat dat zich nu concentreert op de vraag of het versleutelde routenetwerk CJDNS zijn plaats in de referentie-implementatie nog rechtvaardigt.

Zeven “goede” nodes ontketenen een bredere infrastructuuraudit

De technische discussie begon in een open GitHub-issue, waarin ontwikkelaars zich afvroegen of Bitcoin Core een versleutelde routingslaag moet blijven ondersteunen waarvan vrijwel geen gedocumenteerd werkelijk verkeer bekend is. Het kerndoel van het toevoegen van alternatieve netwerktransportlagen aan Bitcoin is redundantie: het voorkomen van elk afzonderlijk punt van falen of censuur op netwerkniveau. Redundante routes functioneren echter alleen als een actieve mesh van peers deelneemt op het onderliggende netwerk.

Tijdens geautomatiseerde tests van een CJDNS-only-nodesetup meldde Core-ontwikkelaar Marco Falke dat zijn instantie op geen enkel moment verbindingen kon opbouwen met meer dan drie of vier verschillende peers. Naar aanleiding van die waarneming bevraagde een andere bijdrager een gevestigde netwerk-seederdatabase — de bootstrapservices die net gestarte nodes hun eerste peer-adressen verstrekken — met 25 bekende CJDNS-adressen. Van de 25 geteste adressen reageerden er 22 op eenvoudige handshakes, maar slechts zeven voldeden aan de technische criteria om te worden geclassificeerd als betrouwbare “goede” peers voor actieve blok- en transactiepropagatie.

Eén enkele seederbevraging vormt geen absolute volkstelling van elke draaiende node in het gehele CJDNS-ecosysteem; privé-nodes zonder aankondiging en niet-geïndexeerde peers kunnen buiten openbare seederlijsten nog steeds bestaan. Desondanks onderstrepen de cijfers een serieuze praktische realiteit: een overlay-netwerk met minder dan een dozijn toegankelijke routingdoelen levert niet de operationele redundantie die van een robuuste productienode wordt geëist. Ter vergelijking: langlopende openbare crawls hebben via Tor aangekondigde, bereikbare Bitcoin-nodes geteld in de lage duizenden, tegenover de 25 adressen die de CJDNS-seeder bevat.

CJDNS begrijpen: versleutelde IPv6-routing versus consensusregels

CJDNS is een versleutelde IPv6-mesh-netwerkoverlay die public-key-cryptografie gebruikt voor adrestoewijzing en gedistribueerde routing. Buiten Bitcoin is het protocol vooral bekend als de routingslaag van Hyperboria, een door vrijwilligers beheerd community-meshnetwerk. Bitcoin Core voegde in 2022 in versie 23.0 native CJDNS-ondersteuning toe, waarmee node-operators peer-verkeer naast IPv4, IPv6, Tor en I2P ook via CJDNS kunnen laten lopen.

Volgens de documentatie van Bitcoin Core versleutelt CJDNS verkeer van end tot end en kan het verkeersanalyse en filtering bemoeilijken. Het is echter geen anonimiteitsnetwerk in dezelfde zin als Tor: tussenliggende CJDNS-routers kunnen nog steeds de cryptografische bron- en bestemmingsadressen zien van de pakketten die zij doorsturen.

Het voorstel betreft uitsluitend de manier waarop Bitcoin Core peers vindt en verbindingen met hen opbouwt. Het verwijderen van CJDNS-ondersteuning zou niets veranderen aan blokvalidatie, mining, scriptregels of transactieformaten; nodes zouden dezelfde Bitcoin-consensusregels blijven afdwingen.

De beveiligingsmechanismen van een eclipse-aanval

Bij de beveiliging van Bitcoin-nodes hangen netwerktransport en peer-selectie rechtstreeks samen met data-integriteit. Versleuteling verbergt de inhoud van pakketten voor derden, maar beschermt een node er niet tegen om vals of vertraagd informatie toegediend te krijgen als de selectie van peers te beperkt is. Dunne peer-pools ondermijnen de beveiliging doordat het voor kwaadwillende actoren aanzienlijk gemakkelijker wordt om CJDNS-only-nodes te isoleren en te manipuleren.

De voornaamste dreiging voor geïsoleerde nodes is een eclipse-aanval. Bij een eclipse-aanval compromitteert of controleert een tegenstander alle peer-verbindingen die een doelnode heeft opgebouwd. Door de doelnode volledig te omringen, isoleert de aanvaller die in de praktijk van het legitieme wereldwijde Bitcoinnetwerk. Vanuit die positie kan de aanvaller het blockchain-beeld van het slachtoffer manipuleren door blokaankondigingen te vertragen, specifieke inkomende transacties te censureren of double-spend-aanvallen op onbevestigde transacties te proberen.

Onder standaard IPv4-, IPv6- of Tor-routing beperkt Bitcoin Core het risico van eclipse-aanvallen door meerdere onafhankelijke verbindingen op te bouwen over uiteenlopende netgroups en netwerkbereiken; standaard houdt de software tegelijk acht uitgaande full-relay-verbindingen open. Wanneer een node uitsluitend opereert over een netwerk met slechts zeven betrouwbare peers — minder dan die standaard uitgaande slots — is de totale beschikbare verbindingspool veel te klein: een aanvaller heeft slechts zeer beperkte middelen nodig om alle inkomende en uitgaande verbindingen van een CJDNS-only-node te monopoliseren, waardoor een beoogde beveiligingsfallback verandert in een aanzienlijk single point of failure.

Codecomplexiteit en het pleit voor deprecatie

Naast de lage adoptiecijfers en beveiligingszorgen benadrukken ontwikkelaars die pleiten voor verwijdering de voortdurende onderhoudslast die de CJDNS-code oplegt aan de algehele softwarerepository van Bitcoin Core.

Anders dan standaard protocolhandlers is de CJDNS-integratie niet volledig geïsoleerd van de standaard IPv6-verbindingslogica. Omdat CJDNS speciaal geformatteerde IPv6-adressen gebruikt, vereist de codebase aangepaste verwerkingslogica, specifieke startargumenten zoals -cjdnsreachable en gespecialiseerde workarounds voor randgevallen. In de loop van de tijd hebben ontwikkelaars vastgesteld dat deze aangepaste logicapaden bugrisico's met zich meebrengen en het routinematig refactoren van de netwerkstack bemoeilijken. De transportlaag staat bovendien in actieve ontwikkeling, met het versleutelde BIP 324 v2-transport dat als optie werd meegeleverd in versie 26.0 en standaard werd ingeschakeld in versie 27.0 — nieuwe verbindingscode die arriveert terwijl legacy-paden zoals CJDNS opnieuw worden beoordeeld.

Meerdere Core-bijdragers hebben een “Concept ACK” gegeven richting deprecatie van het protocol. In de terminologie van open-source Bitcoin Core-ontwikkeling geeft een “Concept ACK” aan dat een bijdrager het eens is met het overkoepelende doel van een voorstel; het is geen definitieve stemming, geen code-merge en geen onmiddellijke toezegging om de functie te verwijderen.

Het pleit voor langetermijn-noodreserves

Aan de andere kant van de discussie betogen ontwikkelaars die voorzichtigheid adviseren dat het nut van een node niet uitsluitend beoordeeld moet worden op huidige verkeerscijfers. Bijdrager Jon Atack wees erop dat geautomatiseerde CJDNS-peerdiscovery pas begin 2025 in Core werd geïntegreerd. Vóór die update moesten node-operators peer-adressen handmatig configureren — een proces dat een aanzienlijke instapdrempel vormde vergeleken met de one-click-setups die voor Tor of I2P beschikbaar zijn.

Voorstanders betogen dat de lage gebruikerscijfers van CJDNS voortkomen uit een gebrek aan bekendheid onder gebruikers en beperkte integratie in populaire kant-en-klare nodesoftware-distributies, niet uit een gebrek aan onderliggende waarde. Als grote openbare anonimiseringsnetwerken zoals Tor of I2P te maken zouden krijgen met gecentraliseerde blokkades, infrastructuurstoringen of filtering op nationaal niveau, zouden alternatieve mesh-protocollen zoals CJDNS een cruciaal noodfallbackkanaal kunnen bieden om peer-verbindingen in stand te houden.

Atack heeft zich bovendien vrijwillig aangemeld om de CJDNS-integratiecode persoonlijk te onderhouden, waarmee hij zorgen over de werklast voor ontwikkelaars aanpakt. Core-bijdragers moeten nu beslissen of zij een alternatieve transportroute voor noodgevallen behouden, of de codebase stroomlijnen door weinig gebruikte netwerklogica te verwijderen.

Wat een mogelijke verwijdering betekent voor node-operators

Als Bitcoin Core uiteindelijk de native CJDNS-integratie in een toekomstige release verwijdert, zal de software simpelweg stoppen met het intern beheren van CJDNS-peer-verbindingen binnen de applicatielaag. De wijziging zou operators niet verhinderen om CJDNS extern op besturingssysteemniveau te draaien, en zou ook de manier waarop het bredere Bitcoinnetwerk transacties verwerkt niet veranderen.

Verwijderingen bij Bitcoin Core volgen doorgaans een traag en gedocumenteerd traject — deprecatie wordt gemarkeerd in release notes en code wordt pas in een latere major release geschrapt, volgens de releasecyclus van ruwweg zes maanden van het project — zodat de signalen om in de gaten te houden de GitHub-discussie zijn, een eventuele formele deprecatie-pullrequest, en de vraag of de in 2025 toegevoegde geautomatiseerde peerdiscovery de adoptiecijfers doet stijgen voordat de maintainers een beslissing nemen.

Voor de grote meerderheid van de node-operators die vertrouwen op standaard IPv4-, IPv6-, Tor- of I2P-verbindingen, zou de verwijdering van CJDNS volledig onopgemerkt voorbijgaan. De lopende discussie weerspiegelt de rigoureuze engineeringfilosofie van Bitcoin Core: elke coderegel moet zijn bestaan rechtvaardigen met bewezen beveiliging en actief nut.

Dit artikel dient uitsluitend ter informatie en vormt geen beleggingsadvies.

Bron: Coindoo