Tres vulnerabilidades en viejas versiones de bitcoin core

Tipos de vulnerabilidades según las políticas

Baja: Difícil de explotar, bajo impacto.
Media: Impacto limitado, afecta entornos específicos.
Alta: Impacto severo, afecta redes o sistemas remotamente.
Crítica: Compromete toda la red, amenaza la seguridad económica del sistema.

Cuando un bloque compacto tiene transacciones faltantes, el nodo las solicita usando getblocktxn.
Al recibir las transacciones, el nodo llama al método FillBlock para reconstruir el bloque.
Si ocurre una colisión de IDs de transacción (txid), el nodo solicita el bloque completo, pero no libera la memoria asociada al bloque parcialmente descargado.
Esto permite que un segundo mensaje blocktxn llame nuevamente a FillBlock, lo cual viola una suposición del código: que este método solo debe ejecutarse una vez por bloque.
Como resultado, el nodo se cierra abruptamente (“crashea”).

El nodo recibe un bloque compacto e inicia su reconstrucción utilizando su mempool.
Solicita las transacciones faltantes mediante getblocktxn mientras mantiene un estado de descarga.
Un nodo peer envía un bloque mutado (con una raíz de Merkle o un compromiso de testigo incorrectos).
Bitcoin Core trataba este bloque mutado como válido y limpiaba el estado de descarga, asumiendo erróneamente que era el mismo bloque en reconstrucción.
Esto hacía que el nodo olvidara reconstruir el bloque, ignorando cualquier respuesta válida del mensaje blocktxn.
Como el bloque compacto no podía reconstruirse, no se propagaba a otros peers.

Se aseguró que cada peer solo pueda afectar su propio estado de descarga y no el de otros.

Cada nodo mantiene un conjunto m_tx_inventory_to_send con las transacciones que debe anunciar a sus peers.
Este inventario se ordena por:
- Dependencias: Para que las transacciones dependientes sean anunciadas en el orden correcto.
- Tarifas (fees): Para priorizar transacciones de mayor tarifa.
En 2023, la alta actividad de la red hizo que estos conjuntos crecieran más rápido de lo que se vaciaban (a una tasa fija de 7 transacciones por segundo).
Nodos “espías” (que solo escuchan pero no anuncian transacciones) agravaron el problema al mantener conjuntos enormes, ralentizando la ordenación.
Esto afectó:
- La propagación de bloques y transacciones.
- La estabilidad de las conexiones con otros nodos.

Eliminar transacciones que ya no estén en el mempool.
Incrementar dinámicamente la tasa de drenaje de las transacciones según el tamaño del conjunto.

¿Está el desarrollo de Bitcoin ya completo?
¿Cómo balanceamos la transparencia en vulnerabilidades frente al riesgo de ataques antes de solucionarlas?
¿Cómo equilibrar la urgencia de arreglar vulnerabilidades con la necesidad de pruebas exhaustivas?
¿Qué podemos hacer para fomentar la participación de más técnicos en la identificación, propuesta y solución de vulnerabilidades?