Bitcoin Core 32.1 llegó el 27 de octubre, hace siete días, y el arreglo que más importa de todo el paquete no tiene nada que ver con la velocidad ni con las comisiones. Cierra una vía por la que un nodo podía difundir una transacción a través de Tor y, en un escenario muy concreto, terminar entregando su dirección IP real al par que la recibía. Ese escenario exigía cuatro condiciones a la vez y ninguna de ellas era la configuración por defecto, lo que rebaja el alcance del fallo sin anularlo.
La función afectada se llama difusión privada (private broadcast) y entró con la versión 31.0, publicada en abril de este año. Su promesa es sencilla: cuando un programa envía una transacción al nodo, este no la anuncia por las conexiones que mantiene abiertas con sus pares, sino que abre conexiones aparte a través de Tor o de I2P. Así el receptor no ve la IP del emisor y dos transacciones sin relación entre sí no quedan pegadas por compartir el mismo canal.
El detalle que se escapaba es que esa separación depende de que la conexión salga de verdad por el proxy anónimo. En 32.1 el proyecto corrige el reintento que podía saltárselo, y de paso pone topes a una cola que hasta ahora crecía sin freno: 10.000 transacciones pendientes y 1.000 intentos de envío por transacción. Para quien opera un nodo, la lectura práctica es que actualizar deja de ser una cuestión de rendimiento y pasa a ser una cuestión de quién puede deducir desde dónde se envió el dinero.
Qué se filtraba y en qué condiciones
La difusión privada es la opción, desactivada por defecto, que hace que el comando `sendrawtransaction` no anuncie la transacción por las conexiones normales, sino que abra un canal aparte por Tor o por I2P para cada envío.
La retransmisión es otra cosa y la hace todo nodo: avisar a los pares de las transacciones que acaba de ver y mandarles las que piden, para que el anuncio llegue a los mineros sin intermediarios.
Aquí es donde aparece el fallo. Antes de enviar por difusión privada, el nodo sustituye la selección normal de proxy y fuerza la salida por Tor. El problema es que Bitcoin Core intenta primero el protocolo de pares v2 y, si la negociación falla, reintenta con v1; ese reintento se hacía sin la orden de proxy temporal, así que podía salir por IPv4 o IPv6 a la vista. Las condiciones que tenían que darse a la vez son estas:
- Un par había anunciado al nodo una dirección IPv4 o IPv6 con soporte para el protocolo v2.
- El nodo tenía Tor configurado para la difusión privada.
- Su configuración permitía conexiones directas a IPv4 o IPv6, es decir, sin ningún valor en `-proxy=`.
- El par no soportaba v2 de verdad y sus banderas de anuncio eran falsas.
Las cuatro tienen que coincidir y la última exige un par que mienta, así que el fallo no alcanzaba a cualquier operador con Tor. El daño, aun así, no era pequeño: la IP de origen es el dato que permite atar una firma anónima a una conexión doméstica o a un servidor contratado a nombre de alguien.
El arreglo, registrado en el PR 35410, conserva la orden de proxy cuando el reintento pasa de v2 a v1. La 31.2, publicada el mismo 27 de octubre, no incluye ese parche: quien tenga la difusión privada activada debe pasar a la 32.1. El parche no toca la retransmisión ordinaria: afecta a ese camino.
Los topes que llegan con el arreglo
El mismo paquete mete dos límites en la difusión privada que no tienen que ver con la fuga, sino con el consumo de recursos. La cola de transacciones pendientes de eco queda en 10.000 entradas y, cuando se llena, el nodo rechaza las nuevas; quien la usa puede mirar el estado con `getprivatebroadcastinfo` y liberar espacio con `abortprivatebroadcast`. Cada transacción tiene además un techo de 1.000 intentos de envío.
La función llegó sin etiqueta en la 31.0 y la 31.2 la marcó como experimental en el PR 36309. Tratarla como tal es lo sensato, porque no mueve fondos ni toca las reglas de consenso, pero introduce una cola propia con estados que nadie vigila por defecto.
Una transacción atascada ahí no está esperando confirmación, está esperando salir. Ese matiz cambia el modo de diagnosticar un envío que no aparece, ya que para un explorador de bloques la transacción no existe y para tu nodo está en un limbo que solo se ve preguntando por ella.
Una retransmisión con mochila compartida
El otro cambio del paquete toca la retransmisión normal, la de todas las transacciones y no solo las privadas. Bitcoin Core limitaba antes los envíos par por par; ahora usa una mochila global para toda la salida. El límite por defecto sigue en 14 transacciones por segundo, multiplicado por 2,5 para los pares de salida, y se añade un techo de 12 MB cada diez minutos. La idea es gastar menos memoria y menos CPU cuando la red se atasca.
Los pares también cambian de número. El máximo de conexiones automáticas pasa de 125 a 200, y los pares que retransmiten transacciones pueden ocupar como mucho la mitad de las entradas de recepción, un porcentaje que se ajusta con `-inboundrelaypercent` entre 0 y 100. Quien haya fijado `-maxconnections` a mano conserva su valor.
También hay un cambio para Tor. Los servicios ocultos que crea Bitcoin Core activan defensas de prueba de trabajo cuando el demonio de Tor las soporta, una barrera contra quien satura un servicio onion. No es minería ni compite por bloques.
Lo que conviene revisar en un nodo propio
Para quien administra un nodo, 32.1 es rutina con comprobaciones que no lo son. La primera es la descarga: el proyecto insiste en los binarios firmados y reproducibles de su directorio. La cadena de confianza de un instalador se rompe más veces de lo que parece, como ocurrió con los certificados TLS de eMudhra comprometidos, y aquí está en juego el software que firma transacciones.
La segunda es la automatización. `getmempoolinfo` deja de devolver el campo `fullrbf` salvo que se pida con `-deprecatedrpc=fullrbf`, y `bip125-replaceable` desaparece de las respuestas de mempool si no se activa la compatibilidad. Los cuatro comandos que crean transacciones parcialmente firmadas pasan a generar PSBT de versión 2 por defecto, así que un script que compare bytes va a notar la diferencia.
La tercera es de calendario. El ciclo de vida de Bitcoin Core dejó de cubrir las versiones 29.x y anteriores el mismo 27 de octubre. Si el tuyo es de Ethereum, los requisitos de disco, memoria y sincronización que exige son otros.
| Ajuste |
Valor por defecto en 32.1 |
Qué implica |
| Cola de difusión privada |
10.000 transacciones |
Al llenarse, rechaza envíos nuevos |
| Intentos por transacción privada |
1.000 |
Después hay que relanzarla con `sendrawtransaction` |
| Conexiones automáticas |
200, antes 125 |
Más hueco de entrada |
| Pares que retransmiten sobre entradas |
50% |
Se ajusta con `-inboundrelaypercent` |
| Salida de transacciones |
14 tx/s y 12 MB cada diez minutos |
Menos CPU en los picos |
Un día después, el 28 de octubre, el proyecto hizo públicos tres avisos de seguridad. CVE-2026-117349 cubre un crecimiento de memoria sin límite con pares antiguos en pausa, mientras CVE-2026-117350 describe el mismo desbordamiento con datos urgentes de TCP en sistemas que no son Linux. CVE-2026-117346 corrige un desbordamiento de los ficheros de deshacer, es de severidad baja y sigue sin solución en equipos de 32 bits y en nodos con bloques en FAT32.
Los dos primeros son de severidad media y los tres llegaron por la misma vía: un escaneo automático con modelos de lenguaje del proyecto Loupe, no una auditoría humana. La versión 32.1 trae el parche de los tres, y un equipo de 32 bits seguirá expuesto a uno de ellos aunque actualice.
La lección no es que Bitcoin expusiera a sus usuarios, porque no lo hizo: el fallo vivía en una función opcional que la mayoría de los nodos no tiene activada. La lección es más pequeña y más incómoda, porque un nodo también es un punto de observación, y la dirección desde la que habla cuenta cosas que la cadena no cuenta.
Por eso la privacidad de la infraestructura deja de ser un capricho de paranoicos y se parece más a la higiene de actualizar. Quien difunda transacciones desde su propio nodo debería revisar la configuración de proxy antes de dar por hecho que el anonimato lo pone la herramienta por defecto, y quien no use esa función puede actualizar sin prisa pero sin olvido.
