Un parche de privacidad de Bitcoin Core 31.x recibe una nueva revisión y sigue pendiente
Publicación de la fuente: 2026-10-09 · Análisis editorial publicado: 2026-10-11
Una revisión del 9 de octubre reconoce el parche de transmisión privada de Bitcoin Core para 31.x. La propuesta permanece abierta en el momento de la verificación; una revisión aprobada, un cambio fusionado y una versión estable descargable son hitos separados.
Análisis e implicaciones prácticas
Esta sección contiene nuestro análisis y cálculos ilustrativos, separados del informe original.
Una nueva revisión del backport de la serie estable
El 9 de octubre, el revisor davidgumberg publicó un ACK para la commit 22ac577 en la pull request 36358 de Bitcoin Core. La propuesta apunta a la rama 31.x y permanece abierta en nuestra verificación del 11 de octubre, con un hito 31.2. Su propósito es mantener las conexiones de transmisión privada fuera del mecanismo ordinario de discouragement de los pares y, al mismo tiempo, desconectar a los pares privados que se portan mal. Un reconocimiento de revisión no es una fusión y un hito no es una fecha de lanzamiento anunciada.
Esto es importante para los operadores que utilizan deliberadamente la función experimental de transmisión de transacciones y necesitan saber qué ruta de software contiene una corrección. Nuestro informe trata la revisión como el nuevo evento y proporciona la historia anterior del desarrollo como contexto. No describe un nuevo archivo de firmware ASIC ni afirma que cada nodo esté expuesto a través de su configuración predeterminada. El catálogo de hardware y el archivo de firmware del fabricante están separados del software de nodo de Bitcoin Core.
Dónde ya se incorporó la corrección
El cambio original, pull request 36312, se fusionó con la rama de desarrollo principal el 25 de septiembre. El paquete de backport 32.x, pull request 36300, se fusionó el 1 de octubre e incluye la misma corrección. Esos eventos del repositorio establecen la presencia de código en esas ramas. No establecen que una máquina que todavía ejecuta el binario estable anterior haya obtenido el cambio, ni que se haya instalado una nueva versión final en algún lugar.
Una etiqueta de versión debe estar vinculada al ejecutable real y su fuente. Una rama puede contener una solución, mientras que una versión empaquetada de otra rama puede no incluirla. Por el contrario, un distribuidor puede aplicar un backport que cambie el código sin utilizar la misma etiqueta de lanzamiento ascendente. Un operador debe conservar el origen del paquete y la información exacta de compilación en lugar de tratar el número de versión más alto que aparece en un titular como una evaluación de seguridad completa.
La característica es deliberadamente opcional.
Las notas de la versión 31.0 anterior describen la transmisión privada como una opción que afecta las transacciones enviadas a través de sendrawtransaction, utilizando conexiones dedicadas a través de redes de privacidad. Un cambio de documentación separado, pull request 36309, reduce los reclamos de privacidad y marca la característica como experimental. Está deshabilitado de forma predeterminada. Estas calificaciones son relevantes porque la corrección reportada se refiere a una ruta de transmisión opcional específica, no a cada conexión ordinaria o cada transacción vista por un nodo.
Para una empresa minera, identifique si su propio software realmente envía transacciones a través de esa ruta antes de evaluar la importancia operativa. Un ASIC que se comunica con un pool no es el mismo servicio que un nodo Bitcoin Core que transmite una transacción de billetera. Enumerar los servicios y sus dependencias ayuda a evitar cambiar una configuración de minería en respuesta a un parche que pertenece a un componente diferente. El titular no establece un defecto en una interfaz de red Antminer o WhatsMiner.
El manejo de la conexión observable es un límite de privacidad
La descripción del parche identifica un efecto de manejo de la conexión que puede observarse desde el exterior. El diseño separa a los pares de transmisión privada del mecanismo ordinario de discouragement y mantiene la desconexión de los pares privados que se portan mal. Nuestra interpretación es que esta separación busca reducir una posible señal de correlación. No es una promesa de que un nodo, una billetera o una persona dejen de ser rastreables bajo todas las condiciones de la red después del cambio.
Como forma editorial de razonar sobre el tema, pregunte qué acciones visibles externamente se comparten entre un flujo de trabajo supuestamente separado y el flujo de trabajo normal. Si una decisión en un camino cambia el comportamiento de otro, un observador puede aprender una relación que el operador no pretendía exponer. Esta es una explicación de los límites del sistema, no una nueva prueba de vulnerabilidad. No hemos medido la explotación en una red en vivo ni evaluado ningún nodo de lector.
No lo confunda con la corrección 31.1 anterior.
Las notas oficiales de Bitcoin Core 31.1 describen una corrección anterior del enrutamiento de la conexión de transmisión privada que involucra al proxy configurado durante la reconexión. Esa cuestión anterior y la actual propuesta de manejo entre pares abordan mecanismos diferentes. La página de descarga oficial todavía presenta la 31.1 como la última versión estable en nuestro control. Su presencia es evidencia de una versión disponible, no evidencia de que la propuesta 31.x actualmente abierta ya esté incluida.
Los registros de mantenimiento deben asignar cada problema relevante a la versión o paquete que realmente contiene su solución. La combinación de varios titulares relacionados con la privacidad en un supuesto parche puede hacer que un operador crea que se ha solucionado un problema posterior cuando sólo se cubrió uno anterior. Mantenga los enlaces ascendentes y las fechas de revisión en el registro de cambios. Una discusión en el repositorio sobre una futura versión de mantenimiento no puede reemplazar una nota de versión verificada para el binario en uso.
Una actualización controlada comienza con un inventario
Antes de programar una actualización de nodo, conserve la versión exacta, el origen del paquete, la configuración relevante y los servicios que dependen del nodo. Para un pool o billetera empresarial, incluya la ruta de envío de transacciones y cualquier automatización que espere un comportamiento RPC particular. Este inventario permite decidir si un cambio específico ascendente afecta al sistema instalado. También evita que se aplique un proceso genérico de mantenimiento de firmware al software de nodo con diferentes requisitos de datos y disponibilidad.
Un plan de verificación práctico verifica el inicio del servicio, el estado de sincronización, las llamadas RPC requeridas y el comportamiento de transmisión de transacciones en un entorno de prueba apropiado antes de la ventana de producción. Registre el resultado y conserve un plan de recuperación para la configuración y los datos involucrados. Estas son sugerencias operativas editoriales, no instrucciones de lanzamiento de nuevos proyectos ni una recomendación para instalar una rama no revisada. Un candidato de prueba y un paquete de producción estable deberían seguir siendo opciones visiblemente diferentes.
El estado de publicación debe verificarse en el momento de su uso.
El estado registrado es una instantánea fechada: la propuesta 31.x estaba abierta cuando se revisó el 11 de octubre. Puede cambiar después de la publicación. Una fusión posterior establecería otro hito, pero los operadores aún necesitarían identificar una compilación distribuida que lo contenga. La distinción es importante cuando se planifica una ventana de mantenimiento varios días después de la lectura de una noticia. Vuelva a verificar los registros oficiales del proyecto antes de atribuir una solución a una versión instalada.
Un ejemplo independiente es una flota con diez instancias de nodos, de las cuales ocho se han actualizado a un paquete verificado y dos permanecen en una compilación anterior. Un anuncio de lanzamiento por sí solo no actualiza los diez. Realice un seguimiento del ejecutable real y el resultado del reinicio para cada instancia en lugar de convertir la disponibilidad del software en un recuento de implementaciones. El ejemplo es hipotético; no describe la tasa de adopción de Bitcoin Core ni un pool de minería encuestado.
Qué deberían sacar los mineros de la actualización
La noticia inmediata es el progreso en la revisión de un backport, y la entrega de la serie estable aún espera más pasos en los registros verificados. No cambia el algoritmo de prueba de trabajo de Bitcoin, la velocidad nominal de un ASIC o el consumo de electricidad de una granja. La respuesta operativa útil es identificar el servicio opcional afectado y seguir la ruta de lanzamiento oficial, preservando la diferencia entre revisión de código, fusión, empaquetado e instalación.
Dos fotografías de red de archivo con licencia ilustran el contexto de la red. No representan un ataque, un sistema de prueba de un desarrollador o una empresa minera afectada por el problema. La fuente principal y los registros de apoyo del proyecto están vinculados a continuación con sus fechas. Este artículo informa sobre un evento de revisión actual específico y explica sus límites operativos; no etiqueta una versión futura como descargable ni inventa una fecha límite para el hito 31.2.
Fuente: Bitcoin Core / GitHub ↗ · Original private-broadcast patch ↗ · 32.x backport bundle ↗ · Experimental feature and qualified privacy claims ↗ · Official Bitcoin Core 31.0 notes ↗ · Official Bitcoin Core 31.1 notes ↗ · Current official stable download ↗
Calculadora de minería ↗
