Bitcoin Core ha incorporado a su rama de código 32.x una corrección de privacidad destinada a evitar que el comportamiento de ciertas conexiones pueda utilizarse para relacionar emisiones privadas con conexiones ordinarias de un nodo. El parche para la rama 31.x, sin embargo, continúa abierto a 8 de octubre, por lo que los usuarios de la versión estable más reciente, la 31.1, todavía no disponen de esa reparación.
La corrección ya está en la rama 32.x
El cambio original llegó a la rama principal de desarrollo el 25 de septiembre y su adaptación a la rama 32.x quedó incorporada el 1 de octubre. La propuesta para trasladarlo también a la serie 31.x recibió el visto bueno del revisor vasild el 6 de octubre y figura asociada al hito 31.2.
Ese hito no implica una fecha de lanzamiento. La página oficial de descargas sigue mostrando Bitcoin Core 31.1 como la última versión disponible. En cuanto a la serie 32.0, su directorio de descargas contiene candidatos de prueba, entre ellos binarios de la tercera versión candidata fechados el 6 de octubre, pero no archivos de una versión final.
Por tanto, el recorrido para los usuarios de la rama anterior pasa todavía por completar la adaptación del parche a 31.x y publicar una versión que la incluya.
El riesgo se limita a una función activada de forma voluntaria
La cuestión afecta a la opción de emisión privada, desactivada por defecto. Los usuarios pueden activarla mediante privatebroadcast al enviar transacciones con sendrawtransaction, el comando utilizado para difundir una transacción sin procesar a la red.
Este mecanismo emplea conexiones específicas y de corta duración con pares de Tor o I2P, así como con pares IPv4 e IPv6 a través de Tor. La posible correlación no afecta a todos los nodos que funcionan con la configuración predeterminada, sino a la actividad asociada a esas emisiones privadas.
El problema estaba relacionado con el tratamiento denominado «desincentivo» —discouragement en la terminología del proyecto—, que Bitcoin Core aplica a determinados pares considerados problemáticos. Los revisores explicaron que desincentivar un par utilizado para una emisión privada podía modificar el comportamiento observable desde el exterior. Además, una acción de ese tipo podía desconectar otras conexiones que compartieran la misma dirección del par.
Esos efectos comunes podían ofrecer a un observador una pista para vincular una conexión privada con la actividad ordinaria del nodo. La nueva modificación separa ambos comportamientos: los pares empleados para emisiones privadas quedan fuera del mecanismo normal de desincentivo, aunque los pares privados que se comporten de forma incorrecta siguen pudiendo ser desconectados. A la inversa, desincentivar un par ordinario ya no desconecta las conexiones privadas que compartan su dirección.
Una protección experimental con un alcance más acotado
Las notas de lanzamiento de Bitcoin Core 31.1 ya describían otra fuga de dirección IP. En determinadas circunstancias, las conexiones de emisión privada podían utilizar la red abierta en lugar de la red de privacidad configurada por el usuario. Aquella corrección actuaba sobre el enrutamiento de las conexiones.
El cambio que ahora ha llegado al código de 32.x aborda un problema distinto: los efectos observables del tratamiento de los pares. Los desarrolladores también han calificado la emisión privada de experimental y han limitado sus garantías de privacidad a una reducción del riesgo, en lugar de presentarla como una protección absoluta.
