Nueva cruzada contra Bitcoin Core  

La guerra de clientes por la inclusión de datos arbitrarios en las transacciones de Bitcoin suma un nuevo asalto.  

Este conflicto, reportado ampliamente por CriptoNoticias, divide a quienes desean a Bitcoin puramente financiero de quienes permiten el uso de su espacio para inscribir información no económica. 

La polémica versión 30 de Bitcoin Core, el software principal de la red, amplió el límite de espacio para incrustar datos en formato texto pasando de los 83 bytes a 100.000 bytes (1 Megabyte, el tamaño máximo de 1 bloque en Bitcoin).  

Un bug en Bitcoin Core encendió la disputa 

El inicio del debate se dio luego de que fuese encontrado un error de programación (bug) en Core v.30, detectado el 5 de enero, que elimina las wallets de los usuarios que intentan realizar un proceso de migración de sus archivos. 

Como consecuencia, ese fallo podría causar la pérdida de los fondos de quienes operen esas versiones de nodos. 

No obstante, Wicked, un desarrollador cercano a Bitcoin Core, emitió una publicación el 7 de enero asegurando que la versión 29 (v.29) de Bitcoin Knots también mantiene el mismo error. Knots es la versión mantenida por Luke Dashjr, el principal opositor a la política de inclusión de datos de Core. Por lo que el problema puede ir más allá de solo el cliente principal. 

El peligro detrás del fallo técnico de Bitcoin Core v.30 

Un analista maximalista de Bitcoin (quien aboga por la superioridad técnica y ética de Bitcoin sobre otras criptomonedas) conocido en X como ‘barackomaba’ advirtió sobre la gravedad del error en la versión 30. 

Según explicó en X el mismo 6 de enero, la gente está «subestimando el impacto» de aquel fallo crítico.  

«La versión 30 dejó de cargar o crear wallets de tipo ‘legacy’ (monederos antiguos)», señaló.

Cualquier usuario con una wallet antigua se ve obligado a migrar su archivo. Si esa migración falla, el mismo software que te obliga a realizar el proceso que puede borrar tu acceso a los bitcoins si no cuentan con un respaldo de seguridad necesario.  

Este bitcoiner también señaló que el riesgo aumenta en los nodos podados (pruned), los cuales ahorran espacio en disco eliminando datos históricos de la red.  

Si el usuario intenta migrar su wallet sin que esta se encuentre cargada, el software intenta buscar información antigua para reconstruir el saldo. Como un nodo podado ya no dispone de esos datos históricos en su almacenamiento, el proceso de migración falla y activa una ruta de limpieza defectuosa que termina por borrar todos los archivos de la carpeta de la wallet. 

Para él, calificar este error como algo irrelevante es una irresponsabilidad. Según su visión, esto evidencia un proceso de revisión cada vez más centralizado y descuidado dentro de Bitcoin Core. 

Luke Dashjr promueve correr nodos ‘antispam’ 

Por su parte, Luke Dashjr sugirió el 6 de enero, volvió a señalar que la opción más precisa para correr un nodo es «Bitcoin Knots con BIP-110».  

La Propuesta de Mejora de Bitcoin 110 (BIP-110, ahora BIP-444) busca invalidar automáticamente los bloques que contengan transacciones con datos arbitrarios considerados como basura, como lo informó CriptoNoticias. 

Correr esta combinación de software implica que el usuario utiliza una versión de Bitcoin que no reconoce ni procesa la información no financiera incrustada en las transacciones.  

El nodo sigue viendo y validando los bloques minados por otros para mantener la sincronización con la red, pero no almacena esta “data” adiocional que es incrustada en la función OP_RETURN. 

Una propuesta para dar un paso atrás

Finalmente, Ben Sigman, un ingeniero activo en el desarrollo del ecosistema propuso revertir la ampliación de espacio para datos.  

Para el autor de la BIP-360 (una propuesta que busca defender a Bitcoin de la cuántica) la solución es restaurar el límite histórico de 80 bytes para el comando OP_RETURN. 

Sigman argumenta que restaurar este valor por defecto ofrece un punto medio que respeta la elección del operador del nodo.  

A su propuesta, Wicked respondió con sarcasmo: «Nadie te impide limitar tu propio nodo si quieres, pero los que están más molestos ya no usan Core, así que no deberían ser atendidos. Pueden seguir usando Knots«.