Los contribuidores de Bitcoin Core estudian si mantener o eliminar el soporte para un transporte de red poco utilizado que podría haberse convertido en un riesgo mayor que el beneficio que aporta. La discusión se centra en CJDNS, un protocolo de enrutamiento cifrado que Bitcoin Core integró como transporte opcional entre pares.
Según ha informado Andrew Chow, miembro del equipo de Bitcoin Core, una base de datos de rastreadores (seeders) contenía 25 direcciones CJDNS, alcanzó 22 de ellas pero solo clasificó siete como «buenas» bajo criterios técnicos estrictos. Martin Zumsande, autor de la propuesta de discusión abierta en GitHub, observó únicamente entre tres y cuatro pares activos, pese a que Bitcoin Core distribuye 11 semillas CJDNS fijas.
Criterios técnicos para catalogar un nodo como «bueno»
Los datos reportados reflejan una instantánea de un rastreador concreto en un momento dado, por lo que la población global de CJDNS podría ser mayor. El término «bueno» no es sinónimo de alcanzable: un nodo debe superar comprobaciones que evalúan puerto, servicios de red anunciados, versión de protocolo, altura de cadena y fiabilidad continuada en varias ventanas temporales.
Esta diferencia explica que el rastreador alcanzara 22 direcciones pero solo aprobase siete bajo sus filtros de calidad. Zumsande sugirió que un nivel de «cientos bajos» podría justificar mantener el soporte, aunque este umbral no representa consenso oficial sino un punto de partida para el debate.
Riesgo de ataque eclipse en redes con pocas direcciones conocidas
Bitcoin Core mantiene habitualmente ocho conexiones salientes completas de retransmisión y dos de solo bloques, con alguna conexión puntual adicional. Un ataque eclipse logra aislar un nodo monopolizando los pares que configuran su vista de la red. Cuanto menor es el conjunto de direcciones conocidas, más concentrado resulta el objetivo para un atacante.
La documentación actual de Bitcoin Core ya desaconseja operar exclusivamente con CJDNS, porque un nodo puede no llenar sus ranuras salientes, reintentar las pocas direcciones disponibles y volverse más vulnerable a ataques Sybil. Un contribuidor propuso calcular cualquier umbral de direcciones CJDNS en función del coste real de llenar esas ranuras regulares y ejecutar un eclipse contra un nodo que solo utilice ese transporte.
El número de ranuras salientes no es el único factor: disponibilidad de direcciones, criterios de selección, fiabilidad del rastreador y conexiones extra ocasionales influyen en la exposición práctica. La cifra medida apoya la preocupación por concentración en nodos exclusivos de CJDNS, aunque el coste real de explotarla no se ha cuantificado en la discusión pública.
La redundancia depende del uso combinado con otras redes
CJDNS adquiere un valor diferente cuando se emplea junto a IPv4, IPv6, Tor o I2P. La documentación oficial lo presenta como opción complementaria que mantiene una ruta alternativa disponible si otra red falla. Desde el 8 de enero de 2025, CJDNS 22.1 introdujo auto-peering sembrado por DNS, eliminando la necesidad de añadir pares manualmente. Bitcoin Core incorporó documentación actualizada el 30 de marzo de 2026, sustituyendo instrucciones obsoletas de emparejamiento manual.
Estos cambios redujeron la fricción de configuración, pero no se ha medido ningún efecto sobre la población de pares CJDNS de Bitcoin. El 18 de agosto de 2026, Bitcoin Core fusionó otra modificación documental que desaconseja expresamente el uso exclusivo de CJDNS porque el conjunto de direcciones sigue siendo demasiado pequeño para llenar ranuras salientes con fiabilidad.
Los operadores de nodos exclusivos de CJDNS enfrentan el riesgo de pool escaso que la documentación ya advierte. Quienes combinan CJDNS con otras redes lo utilizan para diversidad opcional de rutas y conservan caminos automáticos adicionales aunque CJDNS cuente con pocos pares.
Propuesta de aviso en 32.x y eliminación en 33.x
El debate ha generado múltiples expresiones de apoyo a la desaprobación (deprecation) y una sugerencia de que Bitcoin Core advierta a los usuarios en la versión 32.x antes de planificar la eliminación en la 33.x. No obstante, esa secuencia de versiones se planteó como pregunta. Hasta el domingo 23 de agosto de 2026, la propuesta permanecía abierta en el hito de la versión 32.0, sin rama de implementación ni pull request asociada.
Bitcoin Core integró el soporte completo para CJDNS en la versión 23.0 como característica de red entre pares. El debate está limitado al manejo de direcciones y opciones de conexión; las reglas de consenso y validez de bloques quedan fuera de su alcance. Los operadores directamente afectados serían quienes utilicen -cjdnsreachable (que indica a Bitcoin Core tratar el rango IPv6 relevante como CJDNS) o -onlynet=cjdns (que limita conexiones salientes automáticas a ese transporte).
La opción puede combinarse actualmente con otras redes, mientras las conexiones entrantes y manualmente añadidas permanecen disponibles bajo -onlynet, según la documentación. La propuesta muestra un conjunto de pares observado pequeño, pero también por qué un recuento de uso por sí solo es un test incompleto: la capacidad de respaldo resulta más valiosa antes de que falle una ruta principal, pero una red de respaldo que no consigue llenar conexiones puede ofrecer menos resiliencia que la que sugiere su presencia en el código.
Bitcoin Core aún mantiene el soporte de CJDNS. Un aviso o eliminación fusionados cambiarían el estatus del debate. Los siete nodos buenos hacen que el equilibrio entre diversidad de transporte y riesgo sea medible, dejando la decisión de eliminar todavía abierta.
Fuente: CryptoSlate · Esta información ha sido elaborada por la redacción de Criptonews con apoyo de herramientas editoriales automatizadas.