O Bitcoin Core debate a remoção do suporte ao CJDNS devido à pequena base de nós disponíveis. Dados recentes indicam que poucos pares atendem aos critérios de qualidade do software. Essa concentração pode ampliar a exposição dos operadores a ataques de eclipse.

Na discussão sobre o suporte ao CJDNS, Andrew Chow afirmou que o banco de dados de um seeder continha 25 endereços. O sistema alcançou 22 deles. No entanto, o rastreador classificou apenas sete endereços como bons.

Martin Zumsande, autor da questão, relatou ter encontrado somente três ou quatro pares. Isso ocorreu apesar de o Bitcoin Core incluir 11 sementes fixas de CJDNS. Por isso, alguns participantes defenderam a descontinuação do recurso.

A proposta sugere avisar os usuários na versão 32.x e planejar a remoção na versão 33.x. Contudo, os participantes apresentaram essa sequência como uma pergunta, e não como uma decisão. Em 23 de agosto de 2026, a questão permanecia aberta no marco da versão 32.0. A seção de desenvolvimento também não indicava um ramo de implementação nem um pull request.

Rede registra somente sete nós CJDNS qualificados

Os dados do seeder retratam o banco de um crawler em um momento específico. Portanto, a população global de nós CJDNS pode superar o total observado no levantamento. Ainda assim, os resultados mostram a dificuldade para encontrar pares que cumpram todos os requisitos.

O critério de nó bom exige mais do que a simples capacidade de responder ao rastreador. Na implementação DNSSeedrs de Chow, o software verifica porta, serviço anunciado, versão do protocolo, altura da cadeia e confiabilidade acumulada. Dessa forma, o filtro exclui endereços que respondem, mas não satisfazem todos os parâmetros.

Os testes de confiabilidade consideram várias janelas de tempo e exigem um número mínimo de tentativas. Assim, o crawler alcançou 22 endereços, mas somente sete superaram todos os filtros. Zumsande citou algumas centenas de nós como possível justificativa para manter o suporte. Porém, ele apresentou esse número apenas como referência, sem defini-lo como parâmetro oficial dos mantenedores.

Concentração de pares aumenta preocupação com eclipse

A quantidade de pares, isoladamente, não determina o custo de um ataque de eclipse. Em condições normais, o Bitcoin Core mantém oito conexões de saída para retransmissão completa. O programa também reserva duas conexões somente para retransmitir blocos.

O software pode abrir ocasionalmente uma conexão feeler ou uma conexão adicional para blocos, conforme a documentação técnica. Nesse contexto, um participante sugeriu avaliar qualquer limite do CJDNS pelo custo de ocupar esses espaços. O cálculo ajudaria a estimar a dificuldade para isolar um nó que use exclusivamente essa rede.

Em um ataque de eclipse, o invasor monopoliza os pares que formam a visão de rede de um nó. Com isso, um conjunto pequeno e conhecido de endereços cria um alvo mais concentrado. Entretanto, o debate público não calculou o custo completo de uma possível exploração.

A documentação do CJDNS já desaconselha a operação exclusiva por essa rede. O texto alerta que o nó pode não preencher suas conexões de saída. Também aponta o risco de tentativas repetidas entre poucos endereços e maior suscetibilidade a ataques Sybil.

Outros fatores influenciam a exposição prática dos operadores. Entre eles estão a disponibilidade dos endereços, os critérios de seleção, os filtros do crawler e as conexões adicionais. Por esse motivo, os sete nós qualificados não representam, sozinhos, uma medida completa do risco.

CJDNS ainda funciona como rota complementar

O CJDNS assume outro papel quando funciona como uma das várias rotas disponíveis. A documentação do Bitcoin Core apresenta a tecnologia como complemento a IPv4, IPv6, Tor e I2P. Nesse cenário, o operador pode preservar outra rota caso uma das redes enfrente problemas.

Em 8 de janeiro de 2025, o CJDNS 22.1 introduziu o autopeering com sementes DNS. A atualização tornou opcional a inclusão manual de pares. Com isso, o processo de configuração ficou menos dependente de endereços adicionados pelo operador.

Depois, em 30 de março de 2026, o Bitcoin Core incorporou uma documentação atualizada de configuração. A mudança substituiu instruções obsoletas de peering manual pelo fluxo mais recente. Apesar disso, os participantes não mediram o impacto sobre a quantidade de pares de Bitcoin disponíveis no CJDNS.

Em 18 de agosto de 2026, outra mudança na documentação reforçou a escassez de endereços nessa rede. Segundo o texto, o CJDNS ainda não oferece pares suficientes para preencher conexões de saída com confiança. A atualização manteve, portanto, o alerta aos operadores.

Uma eventual remoção afetaria as configurações de transporte, mas não mudaria as regras de consenso nem a validade dos blocos. O Bitcoin Core adicionou suporte completo ao CJDNS na versão 23.0. Desde então, o recurso funciona como uma opção de rede entre pares.

Os operadores mais afetados usam -cjdnsreachable ou -onlynet=cjdns. A primeira opção identifica como CJDNS a faixa IPv6 correspondente. Já a segunda limita as conexões automáticas de saída a esse transporte.

O Bitcoin Core ainda oferece suporte ao CJDNS. Enquanto isso, a proposta permanece aberta e sem implementação definida. O debate contrapõe a diversidade de rotas ao risco de manter uma rede auxiliar incapaz de preencher conexões com confiança.