-
Somsen sugiere guardar una lista de 7 MB de transacciones iniciales para la revisión de datos.
-
Propone ajustar reglas de bloques de 2010 para que Bitcoin valide transacciones de forma más simple.
Mientras la comunidad de colaboradores de Bitcoin (BTC) debate cambios en el cliente Bitcoin Core y la eliminación del límite en las transacciones OP_RETURN, el desarrollador Ruben Somsen ha señalado un fallo potencial en el protocolo.
El problema detectado, y vinculado a la Propuesta de Mejora de Bitcoin 30 (BIP-30) sobre su regla de transacciones duplicadas, podría generar riesgos en un escenario improbable de reorganización de la red.
Un presunto fallo, según Somsen
Ruben Somsen, conocido por sus contribuciones a propuestas como Silent Payments, publicó el 27 de abril de 2025 un análisis en la lista de correo bitcoindev, donde identificó un fallo en BIP-30, una propuesta creada por Pieter Wuille e implementada en 2012 para prevenir transacciones duplicadas en Bitcoin.
El posible fallo, aunque de baja probabilidad, podría provocar una bifurcación en la red si se diera una reorganización de bloques del año 2010, un escenario que los puntos de control actuales (checkpoints) mitigan. Esa bifurcación implicaría un cambio en las reglas que requiere que todos los nodos actualicen su software, conocido también como “hard fork”.
Una reorganización, por su parte, ocurre cuando los nodos de Bitcoin reemplazan una cadena de bloques por otra más larga, algo que requiere un esfuerzo computacional inmenso para bloques de 2010.
El BIP-30, activo desde el bloque génesis hasta marzo de 2013 (bloque 227.931, cuando se activó el BIP-34), busca evitar que dos transacciones con el mismo identificador (txid) coexistan en el archivo si sus salidas no han sido gastadas. En Bitcoin, cada transacción genera salidas no gastadas (UTXO), que son los fondos disponibles para gastar en futuras transacciones. El BIP-30 verifica que una nueva transacción no cree una salida ya existente en el conjunto UTXO, lo que podría causar “confusión” en los nodos y permitir gastos dobles.
Somsen explica que el problema radica en dos excepciones históricas de transacciones coinbase (las que generan nuevos bitcoins en cada bloque) en 2010, ubicadas en los bloques 91722/91880 y 91812/91842.
En el bloque 91880, la transacción coinbase sobrescribió la del bloque 91722, eliminándola del conjunto UTXO. Si ocurriera una reorganización entre estos bloques, los nodos que procesen la reorganización eliminarían la salida sobrescrita, mientras que los nodos que no la presencien la mantendrían. Si esta salida se gastara posteriormente, los nodos tendrían conjuntos UTXO inconsistentes, lo que provocaría una bifurcación.
«El problema ocurre cuando reorganizamos la blockchain a un punto entre los bloques 91880 y 91722. La salida sobrescrita desaparece completamente del conjunto UTXO. Un nodo que no presenció la reorganización, sin embargo, aún tendrá esa UTXO en su conjunto. Si esa UTXO se gasta, resultaría en una bifurcación», afirma Somsen.
¿Cuán real es el riesgo?
El riesgo señalado por Somsen es teórico, ya que requiere una reorganización de la red Bitcoin hasta 2010, algo prácticamente imposible debido a la enorme cantidad de trabajo acumulado en la cadena y los puntos de control que, hasta 2013, impiden esa reorganización. Sin embargo, la comunidad está considerando eliminar estos checkpoints, lo que haría el fallo “teóricamente explotable”, aunque no práctico, según el desarrollador.
Somsen no aboga por una acción inmediata, ya que «el statu quo parece bastante sostenible». No obstante, propone dos soluciones para mitigar el problema. La primera consiste en prohibir reorganizaciones parciales entre los bloques 91722 y 91880, obligando a los nodos a reorganizar los 160 bloques completos o ninguno. «Considerando que son solo 160 bloques con la baja dificultad de minado de 2010, esto no sería una gran restricción», explica.
La segunda solución, sugerida tras discusiones con el desarrollador Sjors Provoost, aprovecha la posible eliminación de los checkpoints, considerada un hard fork (cambio incompatible con versiones anteriores). Esto permitiría modificar las reglas de consenso pre-2013 para evitar que las transacciones coinbase de los bloques 91880 y 91842 se eliminen durante una reorganización, lo que corregiría el fallo.
La ineficiencia de BIP-30: el análisis de Somsen
Más allá del fallo de consenso, Somsen destaca la ineficiencia del BIP-30, que requiere verificar todo el conjunto UTXO para cada transacción, un proceso costoso en términos computacionales. Esta verificación complicaría métodos alternativos de validación expuestos por Somsen, como Utreexo, que reduciría el tamaño del conjunto UTXO, SwiftSync, que acelera la sincronización de nodos, y ZeroSync, basado en pruebas de conocimiento cero (zero knowledge).
El desarrollador propone reemplazar esta verificación por una caché de identificadores de transacciones coinbase (txids), que ocuparía unos 7 MB hasta el bloque 227931, asegurando que no haya duplicados. Además, sugiere verificar que las transacciones coinbase no entren en conflicto con las reglas del BIP-34, que garantiza la unicidad de estas transacciones, incluso en caso de una reorganización. «Podemos reemplazar la ineficiente verificación del conjunto UTXO de BIP-30 con una verificación de unicidad de coinbase», afirma Somsen.
La respuesta de Luke Dashjr
El desarrollador Luke Dashjr, CTO y cofundador del pool de minería de Bitcoin OCEAN, respondió a la propuesta de Somsen con dos soluciones adicionales.
La primera sugiere tratar la sobrescritura de una transacción como un gasto, restaurando la UTXO original. La segunda propone no crear las UTXO que serán sobrescritas cuando se detecten por primera vez.
Sin embargo, Dashjr cuestiona la propuesta de Somsen de usar una caché de txids, argumentando que verificar 7 MB de datos por transacción es menos eficiente que comparar 64 bytes. «Suena estrictamente peor que cómo lo manejamos hoy», señaló.
En Bitcoin, el método actual para identificar una transacción se basa en comparar el txid, que es el hash de la transacción. Ese hash es generado usando SHA-256 y su tamaño es 32 bytes.
Dashjr podría estar pensando en un contexto donde se comparan dos hashes de 32 bytes (por ejemplo, un txid y otro identificador), lo que sumaría 64 bytes. Sin embargo, en la verificación de BIP-30, solo se usa un txid de 32 bytes por transacción.
Un debate para el futuro de Bitcoin
El análisis de Somsen, respaldado por discusiones con expertos como Antoine Poinsot, Pieter Wuille y Sjors Provoost, pone sobre la mesa un fallo que, aunque remoto, subraya la importancia de revisar las reglas de consenso de Bitcoin.
El fallo en BIP-30 no representa una amenaza inmediata para los usuarios de bitcoin, pero su identificación refleja el compromiso de los desarrolladores con la seguridad de la red creada por Satoshi Nakamoto.
