Bitcoin Core considera eliminar el soporte de enrutamiento cifrado a medida que la mala salud de los nodos expone a los usuarios a ataques de eclipse

Los contribuyentes de Bitcoin Core están sopesando si un transporte de red poco utilizado ofrece un seguro valioso o se ha convertido en una carga demasiado costosa de mantener.

En la discusión abierta sobre el soporte de CJDNS, el miembro de Bitcoin Core Andrew Chow dijo que una base de datos de sembradores contenía 25 direcciones CJDNS, había alcanzado 22 y clasificó solo siete como buenas. El autor del problema, Martin Zumsande, informó haber visto solo de tres a cuatro pares a pesar de que Bitcoin Core se envía con 11 semillas CJDNS fijas.

Esas cifras han impulsado el apoyo a la desactivación y una sugerencia de que Bitcoin Core advierta a los usuarios en una versión 32.x antes de planear la eliminación en 33.x. Pero esa secuencia de versiones se planteó como una pregunta. A partir del domingo 23 de agosto, el problema permanecía abierto en el hito 32.0, con su sección de Desarrollo vacía de una rama de implementación o solicitud de extracción.

Bitcoin Core implementa CJDNS como un transporte y manejo de direcciones opcional entre pares, fuera del sistema de consenso de Bitcoin. El problema #36041 pregunta si Bitcoin Core debería mantener el manejo de direcciones CJDNS como una opción de respaldo cuando la escasa piscina de pares también puede hacer que los nodos solo CJDNS sean más fáciles de rodear.

Los siete buenos nodos de Bitcoin Core capturan una instantánea de sembrador

Los números de sembradores describen la base de datos de un rastreador en un momento dado. La población global de CJDNS puede ser mayor porque la cifra cubre solo la base de datos de ese rastreador.

El sembrador aplica "bueno" como un filtro técnico más estricto que la alcanzabilidad. En la implementación de DNSSeedrs de Chow, un nodo debe pasar verificaciones que cubren su puerto, servicio de red publicitado, versión de protocolo, altura de cadena y fiabilidad en evolución. Las pruebas de fiabilidad utilizan varias ventanas de tiempo y requieren recuentos mínimos de intentos. Eso explica cómo el sembrador pudo alcanzar 22 direcciones mientras clasificaba solo siete como buenas.

Solo siete de las 22 direcciones alcanzadas superaron los filtros de buenos nodos, dejando la piscina utilizable poco profunda. El nodo de Zumsande encontró solo tres o cuatro pares, y ofreció cifras de tres dígitos bajos como un nivel aproximado que podría justificar el apoyo continuo. El umbral de tres dígitos bajos era solo de Zumsande, dando a los mantenedores un número sobre el cual discutir en lugar de solo una queja general sobre el bajo uso.

La aritmética del recuento de pares por sí sola deja el costo del eclipse desconocido. Bitcoin Core normalmente mantiene ocho conexiones salientes de retransmisión completas y dos conexiones solo de retransmisión de bloques, con un ocasional sondeo o conexión extra solo de retransmisión de bloques. Un contribuyente sugirió basar cualquier umbral de CJDNS en el costo de llenar esos espacios regulares y eclipsar un nodo solo CJDNS.

Un ataque de eclipse aísla un nodo al monopolizar los pares que dan forma a su visión de la red. En un transporte con un conjunto de direcciones conocidas pequeño, un atacante tiene un objetivo más concentrado. La documentación actual de CJDNS de Bitcoin Core ya desaconseja la operación solo CJDNS porque un nodo puede fallar en llenar sus espacios salientes, intentar repetidamente las pocas direcciones que conoce y volverse más susceptible a ataques Sybil.

Un eclipse exitoso depende de más que los diez espacios salientes regulares. La discusión pública deja el costo total del ataque no cuantificado. La disponibilidad de direcciones, la selección de direcciones, las puertas de fiabilidad del rastreador y las conexiones salientes adicionales ocasionales afectan la exposición práctica. La piscina medida apoya una preocupación de concentración para los nodos solo CJDNS, mientras que el costo de explotar esa preocupación permanece no cuantificado.

La redundancia depende de cómo se utiliza CJDNS

CJDNS ofrece una propuesta diferente cuando es un camino entre varios. La documentación de Bitcoin Core lo presenta como una opción complementaria junto a IPv4, IPv6, Tor e I2P, permitiendo que un nodo mantenga otra ruta disponible si una red tiene problemas.

Esa opción se ha vuelto más fácil de usar. CJDNS 22.1 introdujo el auto-peering basado en DNS el 8 de enero de 2025, haciendo que la adición manual de pares sea opcional. Bitcoin Core luego fusionó la documentación de configuración actualizada el 30 de marzo de 2026, reemplazando las instrucciones de emparejamiento manual obsoletas con el nuevo flujo.

Esos cambios redujeron la fricción de configuración. Cualquier efecto en la población de pares CJDNS de Bitcoin sigue sin medirse. Bitcoin Core fusionó otro cambio de documentación el 18 de agosto de 2026, desaconsejando explícitamente el uso solo CJDNS porque la piscina de direcciones seguía siendo demasiado pequeña para llenar los espacios salientes de manera confiable.

Los operadores solo CJDNS y de redes mixtas, por lo tanto, enfrentan diferentes riesgos. Un operador solo CJDNS enfrenta el riesgo de piscina delgada que la documentación ahora advierte. Un operador de red mixta utiliza CJDNS para diversidad de rutas opcional y puede mantener otros caminos automáticos incluso cuando CJDNS tiene pocos pares.

Una futura desactivación eliminaría la configuración de transporte mientras deja las reglas de validez de bloques sin cambios. Bitcoin Core agregó soporte completo de CJDNS en la versión 23.0 como una característica de red P2P. El debate se limita al manejo de direcciones y opciones de conexión; las reglas de consenso y validez de bloques de Bitcoin están fuera de su alcance.

Los operadores directamente afectados serían aquellos que utilizan -cjdnsreachable, que le dice a Bitcoin Core que trate el rango IPv6 relevante como CJDNS, o -onlynet=cjdns, que limita las conexiones salientes automáticas a ese transporte. La misma opción actualmente puede combinarse con otras redes, mientras que las conexiones entrantes y manualmente añadidas permanecen disponibles bajo -onlynet, según la documentación.

El problema #36041 permanece abierto, con la advertencia y la secuencia de eliminación registradas solo como una propuesta. Muestra un pequeño conjunto de pares observados, múltiples expresiones de apoyo a la desactivación y una secuencia de lanzamiento propuesta. También muestra por qué un recuento de uso por sí solo es una prueba incompleta: la capacidad de respaldo es más valiosa antes de que falle una ruta principal, pero una red de respaldo que no logra llenar conexiones puede ofrecer menos resiliencia de lo que su presencia en el código sugiere.

Bitcoin Core aún apoya CJDNS. Una solicitud de advertencia o eliminación fusionada cambiaría el estado del debate. Siete buenos nodos hacen que la compensación de diversidad de transporte sea medible y dejan la opción de eliminación abierta.

Este contenido se ofrece únicamente con fines informativos generales y no constituye un asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, operar o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.