No se ha eliminado ningún código y aún no se ha tomado una decisión final, pero las métricas de adopción persistentemente bajas han llevado a los contribuidores de Bitcoin Core a reexaminar los compromisos prácticos de seguridad e ingeniería de mantener redes superpuestas heredadas dentro del cliente principal de Bitcoin — un debate que ahora se centra en si la red de enrutamiento cifrado CJDNS todavía justifica su lugar en la implementación de referencia.

Siete nodos “buenos” desencadenan una auditoría de infraestructura más amplia

La discusión técnica comenzó en un issue abierto de GitHub, donde los desarrolladores cuestionaron si Bitcoin Core debería seguir ofreciendo soporte a una capa de enrutamiento cifrado que registra casi ningún tráfico documentado en el mundo real. El objetivo principal de añadir capas de transporte de red alternativas a Bitcoin es la redundancia: evitar cualquier punto único de falla o censura a nivel de red. Sin embargo, las rutas redundantes solo funcionan si una malla activa de pares participa en la red subyacente.

Durante pruebas automatizadas de una configuración de nodo exclusivamente CJDNS, el desarrollador de Core Marco Falke reportó que su instancia no lograba establecer conexiones con más de tres o cuatro pares distintos en un momento dado. Tras ese hallazgo, otro contribuidor consultó una base de datos de seeders de red establecida — los servicios de arranque que entregan a los nodos recién iniciados sus primeras direcciones de pares — que contenía 25 direcciones CJDNS conocidas. De las 25 direcciones probadas, 22 respondieron a handshakes básicos, pero solo siete cumplieron los criterios técnicos requeridos para clasificarse como pares “buenos” y confiables para la propagación activa de bloques y transacciones.

Una sola consulta a un seeder no representa un censo absoluto de todos los nodos en funcionamiento en todo el ecosistema CJDNS; los nodos privados no anunciados y los pares no indexados aún pueden existir fuera de las listas públicas de seeders. Aun así, las cifras subrayan una realidad práctica seria: una red superpuesta con menos de una docena de objetivos de enrutamiento accesibles no proporciona la redundancia operativa que requiere un nodo de producción resiliente. Como referencia, los rastreos públicos de larga duración han contado miles de nodos Bitcoin alcanzables anunciados a través de Tor, frente a las 25 direcciones que contenía el seeder de CJDNS.

Entendiendo CJDNS: enrutamiento IPv6 cifrado frente a reglas de consenso

CJDNS es una red superpuesta de malla IPv6 cifrada que utiliza criptografía de clave pública para la asignación de direcciones y el enrutamiento distribuido. Fuera de Bitcoin, el protocolo es conocido principalmente como la capa de enrutamiento de Hyperboria, una red de malla comunitaria mantenida por voluntarios. Bitcoin Core añadió el soporte nativo de CJDNS en la versión 23.0 en 2022, permitiendo a los operadores de nodos enrutar el tráfico de pares a través de CJDNS junto con IPv4, IPv6, Tor e I2P.

Según la documentación de Bitcoin Core, CJDNS cifra el tráfico de extremo a extremo y puede dificultar el análisis y el filtrado del tráfico. Sin embargo, no es una red de anonimato en el mismo sentido que Tor: los enrutadores intermedios de CJDNS todavía pueden ver las direcciones criptográficas de origen y destino de los paquetes que reenvían.

La propuesta se refiere únicamente a cómo Bitcoin Core encuentra y se conecta a los pares. Eliminar el soporte de CJDNS no cambiaría la validación de bloques, la minería, las reglas de script ni los formatos de transacción; los nodos seguirían aplicando las mismas reglas de consenso de Bitcoin.

La mecánica de seguridad de un ataque de eclipse

En la seguridad de los nodos de Bitcoin, el transporte de red y la selección de pares están directamente ligados a la integridad de los datos. El cifrado oculta el contenido de los paquetes a terceros, pero no protege a un nodo de recibir información falsa o retrasada si su selección de pares es demasiado restringida. Los grupos de pares escasos debilitan la seguridad al hacer que sea dramáticamente más fácil para los actores maliciosos aislar y manipular nodos exclusivamente CJDNS.

La principal amenaza para los nodos aislados es un ataque de eclipse. En un ataque de eclipse, un adversario compromete o controla todas las conexiones de pares establecidas por un nodo objetivo. Al rodear por completo el nodo objetivo, el atacante lo separa efectivamente de la red global legítima de Bitcoin. Desde esa posición, el atacante puede manipular la visión de la blockchain que tiene la víctima, retrasando anuncios de bloques, censurando transacciones entrantes específicas o intentando ataques de doble gasto contra transacciones no confirmadas.

Bajo el enrutamiento estándar de IPv4, IPv6 o Tor, Bitcoin Core mitiga los ataques de eclipse estableciendo múltiples conexiones independientes a través de netgroups y rangos de red diversos; por defecto, el software mantiene abiertas simultáneamente ocho conexiones salientes de retransmisión completa. Cuando un nodo opera exclusivamente sobre una red con solo siete pares confiables — menos que esos espacios salientes predeterminados —, el conjunto total de conexiones disponibles es demasiado pequeño: un atacante necesita muy pocos recursos para monopolizar todas las conexiones entrantes y salientes de un nodo exclusivamente CJDNS, convirtiendo un respaldo de seguridad previsto en un punto único de falla significativo.

Complejidad del código y el argumento a favor de la deprecación

Además de las bajas cifras de adopción y las preocupaciones de seguridad, los desarrolladores que abogan por la eliminación enfatizan la carga de mantenimiento continua que el código de CJDNS impone al repositorio de software de Bitcoin Core en general.

A diferencia de los manejadores de protocolo estándar, la integración de CJDNS no está completamente aislada de la lógica de conexión IPv6 estándar. Debido a que CJDNS utiliza direcciones IPv6 con un formato especial, la base de código requiere lógica de manejo personalizada, argumentos de inicio dedicados como -cjdnsreachable y soluciones especializadas para casos extremos. Con el tiempo, los desarrolladores han señalado que estas rutas de lógica personalizada introducen riesgos de errores y complican la refactorización rutinaria de la pila de red. La capa de transporte también está en desarrollo activo, con el transporte cifrado v2 del BIP 324 incorporado como opción en la versión 26.0 y habilitado por defecto en la versión 27.0 — código de conexión nuevo que llega mientras rutas heredadas como CJDNS son reevaluadas.

Varios contribuidores de Core han ofrecido un “Concept ACK” hacia la deprecación del protocolo. En la terminología del desarrollo de código abierto de Bitcoin Core, un “Concept ACK” indica que un contribuidor está de acuerdo con el objetivo general de una propuesta; no constituye una votación final, una fusión de código ni un compromiso inmediato de eliminar la función.

El argumento a favor de reservas de emergencia a largo plazo

En el otro lado del debate, los desarrolladores que piden cautela argumentan que la utilidad de un nodo no debe juzgarse exclusivamente por las métricas de tráfico actuales. El contribuidor Jon Atack señaló que el descubrimiento automatizado de pares CJDNS solo se integró en Core a comienzos de 2025. Antes de esa actualización, los operadores de nodos debían configurar manualmente las direcciones de los pares — un proceso que creaba una barrera de entrada significativa en comparación con las configuraciones de un solo clic disponibles para Tor o I2P.

Los defensores argumentan que las bajas cifras de uso de CJDNS se derivan de la falta de conocimiento entre los usuarios y de una integración limitada en las distribuciones populares de software de nodos llave en mano, y no de una falta de valor subyacente. Si redes públicas de anonimización importantes como Tor o I2P llegaran a sufrir bloqueos centralizados, interrupciones de infraestructura o filtrado a nivel de Estado-nación, protocolos de malla alternativos como CJDNS podrían proporcionar un canal de respaldo de emergencia vital para mantener las conexiones entre pares.

Atack también se ha ofrecido a mantener personalmente el código de integración de CJDNS, respondiendo así a las preocupaciones sobre la carga de trabajo de los desarrolladores. Los contribuidores de Core deben decidir ahora si conservan una ruta de transporte alternativa para emergencias de casos extremos o agilizan la base de código eliminando la lógica de red de bajo uso.

Qué significaría una posible eliminación para los operadores de nodos

Si Bitcoin Core finalmente elimina la integración nativa de CJDNS en una versión futura, el software simplemente dejará de gestionar internamente, dentro de la capa de aplicación, las conexiones de pares CJDNS. El cambio no impediría que los operadores ejecuten CJDNS externamente a nivel del sistema operativo, ni alteraría la forma en que la red de Bitcoin en su conjunto procesa las transacciones.

Las eliminaciones en Bitcoin Core suelen seguir un arco lento y documentado — la deprecación se señala en las notas de la versión y el código se elimina solo en una versión mayor posterior, según el ciclo de lanzamiento de aproximadamente seis meses del proyecto —, por lo que los indicadores a seguir son el hilo en GitHub, cualquier pull request formal de deprecación y si el descubrimiento automatizado de pares añadido en 2025 mueve las cifras de adopción antes de que los mantenedores decidan.

Para la gran mayoría de los operadores de nodos que dependen de conexiones estándar de IPv4, IPv6, Tor o I2P, la eliminación de CJDNS pasaría completamente desapercibida. La discusión en curso refleja la rigurosa filosofía de ingeniería de Bitcoin Core: cada línea de código debe justificar su existencia mediante seguridad demostrada y utilidad activa.

Este artículo se proporciona únicamente con fines informativos y no constituye asesoramiento de inversión.

Fuente: Coindoo