Irresponsabilidad de Bitcoin Unlimited

El inicio de los problemas

El 26 de agosto del 2016 alguien notó que un nodo del Bitcoin Classic había sido forkeado de una Prueba de Grandes Bloques que el Bitcoin Classic el Bitcoin Unlimited estaba ya corriendo. Ninguna implementación estaba siendo probada sobre el código de consenso en ninguna red; esta era efectivamente la única prueba (testnet) que estaba siendo usado en su código de base. El problema se debió a que un bloque del testnet fue minado el 30 de julio, un mes antes de que alguien haya notado el fork, el cual fue una violación directa a las especificaciones del BIP109 que los mineros Classic se habían auto-adheridos en el tiempo. Gregory Maxwell observó:

Eso fue hace un mes, pero recién lo hemos notado ahora. Creo que esto demuestra que ¿están liberando Bitcoin Classic sin muchas pruebas y nadie más lo ha hecho? :-/

La transacción en sí no parece inusual, solo que es grande. Fue, incidentalmente, minado por pool.bitcoin.com, el cual había firmado el apoyo por BIP109 en el mismo bloque que había sido minado el BIP109 que estaba violando la transacción.

Ese mismo día, Maxwell le preguntó a Roger Ver para para que clarifique si realmente estaba actualmente corriendo Bitcoin Classic en el pool de bitcoin.com, quien esquivó la pregunta y respondió con una vaguedad que, inexplicablemente, cambió el asunto a cuestiones de censura.

Andrew Stone (el desarrollador principal del Bitcoin Unlimited) confundió más acerca de BIP109 y de cómo Bitcoin Unlimited había violado las especificaciones (mientras daba muestras de apoyar). Dijo que Bitcoin Unlimited no tenía la necesidad de adherirse a las especificaciones las cuales apoyaban las especificaciones, y al hacerlo violaban la filosofía de la implementación. Peter Rizun compartió este punto de vista. Sin embargo, ningún desarrollador había respondido la pregunta de Maxwell sobre la violación del BIP 109 §4/5, el cual había resultado en un consenso de divergencia (fork).

A pesar de que Maxwell había proveído un link directo a la transacción que violaba el BIP109 y causó la división de la cadena, explicando las consecuencias de esto, Andrew Stone dijo:

No he encontrado (ni he buscado) la causa exacta. Hemos pasado BUIP016 para adherir la compatbilidad estricta al BIP109 pero esta es DOA — así que nadie se molestó en ello.

Pero creo que el único valor de este episodio es darte cuenta que las reglas del consenso deben permanecer a una función absoluta de protección-función de dinero. Si esto fuera en la red principal, creo que los usuarios de Classic estarían descontentos de forkear a una minoría por unos limites arbitrarios que es otra cosa que debemos luchar para mejorar el desempaño de la maquinaria pero los limites se mantengan.

Increíblemente, cuando un usuario confundido expresa sus preocupaciones sobre el fork, Andrew Stone responde:

¿Enserio? ¿No había un fork clásico? Como dije, no lo he investigado. ¿Me darías más información? Es importante combatir esto.

Claro, que una proof of fork (y la violación del bloque/transacción BIP109) ya había sido proveído a Stone por Maxwell. Andrew Stone estaba dispuesto a creer que el fork entero era imaginario, en cara de la verificación del incidente. Admite que no investigaron el asunto en absoluto, aún cuando fuera el único testnet que Unlimited había hecho hasta el momento, y aunque este fork forzó a Classic a abandonar el BIP109 completamente, dejando vulnerable a los tipos de ataques que Gavin Andresen describió en su Guía del fork de 2MB:

Un preciso conteo de sigop/sighash y los límites es importante, por que sin ella, el incremento de los límites de los bloques puede ser peligroso…está configurado a 1.3 gigabytes, lo cual es suficientemente grande para que ninguno de los bloques actuales en la blockchain golpee, pero lo suficientemente pequeño para sea imposible crear bloques dañinos que tome minutos a validarse.

Como resultado de este fork (el cual Stone no entendía lo suficiente como para dudar que había pasado), Bitcoin Classic y Bitcoin Unlimited eran vulnerables a ataques. Fascinantemente, esto no pareció molestar en absoluto a los desarrolladores de Bitcoin Unlimited.


Los errores suman y lo pagan otros

El 17 de noviembre del 2016, Andrew Stone publicó un artículo titulado A short tour of Bitcoin Core dijo:

Bitcoin Unlimited está construyendo el cliente Bitcoin más estable y con la más alta calidad. Tenemos un fuerte compromiso de calidad y prueba como lo verán en el resto del documento.

La ironía pronto se haría visible. En el resto del artículo, Stone escribió con una venenosa y hostil retórica:

Mientras minamos en el basurero del Bitcoin Core juntos…quiero que se den cuenta que estos problemas son sistemáticos en el Core.

Describió lo que el creía que era múltiples bugs y pasó desapercibido por los developers de Core, y concluyó con el siguiente párrafo:

Espero que cuando lean estos problemas, se den cuenta que el equipo de Bitcoin Unlimited son los más cuidadosos testers y committers, con una larga y dedicada prueba de infraestructura.

Y espero que vean que estos commits del Bitcoin Core — bugs no son engañosos ni esotéricos, sino asuntos simples conocidos por ingenieros de software — y los commits de “Hackeo Feo” no reflejan realmente el cuidado requerido por una red financiera importante. Espero que se den cuenta que, al contrario de las declaraciones de Adam Back y otros, el equipo Core no tiene habilidades que los califiquen para administrar la red.

Tan pronto como el artículo fue publicado, fue inmediatamente rebatido completamente. Los bugs no existieron en el código base del Core; algunos fueron resultados de como Andrew arruinó el código de la billetera lo suficientemente para romperlo y muchos de los asuntos que fueron causados fueron por cambios que ellos hicieron al código que ellos ni entendieron o ya fueron arreglados por el Core, y solo le afectaron a clientes obsoletos (irónicamente incluye a Bitcoin Unlimited mismo).

Como dijo Gregory Maxwell:

Quizás el asunto más preocupante aquí es que no saben que es lo que están haciendo; pero ellos no saben que no saben, al punto que esto es su mejor criticismo.

Graciosamente, en la sección del artículo “Let’s Lose Some Money”, Stone menosprecia a un desarrollador anónimo por dejar comentarios de baja calidad en una porción del código, inconscientemente burlándose de Satoshi en el proceso.

Resumen

Stone expuso su crítica al equipo de developer del Core, y en el proceso reveló que no entendía el código base que estaba trabajando, dado que él introdujo la mayoría de los bugs que el estaba criticando y era completamente inviable que identifique bugs en versiones actuales de Core.

Lo peor de todo, luego de recibir respuestas de su articulo, no pareció comprender (mucho menos apreciar) ninguno de los hechos.


El 27 de enero del 2017, Bitcoin Unlimited lanzó la versión 1.0 de su software, anunciando:

El tercer cliente de BU refleja nuestra opinión que el software para el full-node de Bitcoin ha llegado su meta de funcionalidad, estabilidad y escalabilidad. Por tanto, la culminación de la fase alfa/beta durante 2009–16 puede ser marcada con el lanzamiento de nuestra versión.

Dos días después, el 29 de enero, su código accidentalmente intentó hacer un hard-fork de la red. A pesar de que existe un claro y estricto comentario en el Bitcoin Core explicando el espacio reservado para transacciones en el código, Bitcoin Unlimited fusionó (merged) con un bug dentro de su cliente lo cual resultó en una invalidación de bloques (23 bytes más grandes que 1MB) cuando se estaban minando en el pool mining de Bitcoin.com de Roger Ver el 29 de enero del 2017, costandole al pool por lo menos 13.2 bitcoins. Una larga porción de los nodos y mineros de Bitcoin Unlimited (quienes aceptaron ingenuamente estos bloques como válidos) fueron rechazados de la red.

Este cambio del código en cuestión reveló que los desarrolladores del Bitcoin Unlimited no solamente estaban comentando y reemplazando código sin entender para que lo hacían, sin hablar que ignoraron multi-medidas de seguridad que pudieron haberlos prevenido de lo ocurrido, sino que no estaban realizando ninguna revisión o testeando en absoluto varios de sus cambios que estaban realizando.

Este bug particular fue insertado dentro del master branch directamente del Bitcoin Unlimited (por Andrew Stone), sin realizar pull request o cualquier otra revisión que involucre un chequeo doble de la actualización. Esto nuevamente expuso la falta de profesionalidad y una enorme negligencia del equipo de desarrolladores del Bitcoin Unlimited, y en este caso, tuvo un efecto negativo que costó a Bitcoin.com miles de dolares en valor de Bitcoin.

En efecto, este fue el primer intento público de forkear hecho por Bitcoin Unlimited. Obviamente, esto falló, costando a los forkeadores bitcoins. Es posible que el costo de este bug sea mucho más grande que la simple perdida de recompensas y comisiones del bloque en sí, así como los mineros de Bitcoin Unlimited estuvieron expandiendo su poder hash en un esfuerzo de minar sobredimensionado bloques (inválidos) e inadvertidamente gastando recursos valiosos.


El 14 de marzo del 2017, una vulnerabilidad remota fue exitosamente descubierta y explotada en Bitcoin Unlimited haciendo caer el 75% de los nodos en minutos.

Para calmar el incidente, Andrew Stone rápidamente publica un artículo en el cual dice que el bug explotado también afecto a los nodos del Bitcoin Core:

..Aproximadamente 5% de los clientes “Satoshi” (Core, Unlimited, XT) están fuera de la red en estos momentos

En Reddit, mintió mucho más explicitamente, describiendolo como un bug cuyo efecto es la caída del 5% de los nodos de Core así como una falla del cliente de la red Bitcoin. Fue más lejos incluso:

El equipo de Bitcoin Unlimited encontró el issue, identificándolo como un ataque y ha arreglado el problema mientras que el equipo del Core simplemente lo ignoró.

La vulnerabilidad en cuestión fue thinblock.cpp, el cual nunca fue parte del Bitcoin Core; es decir, esta vulnerabilidad solo afectó a los nodos de Bitcoin Classic y Bitcoin Unlimited. En el mismo artículo de Medium, Andrew Stone aparece con imágenes alteradas para engañar a los lectores.

En un thread de Reddit se discutía esta decepción, Andrew Stone negó que las imágenes fueran alteradas pero cuando fue cuestionado mucho más profundamente del asunto en cuestión, se limitó a responder citando sus propias imágenes como fuentes y se negó a responder más preguntas para aclarar los pasos realizados.

Más allá de eso, el mismo reporte de incidente (con imágenes) conscientemente omitieron el hecho que la caída del 5% en la captura de pantalla (photoshopeada) del gráfico del nodo fue realmente el rastreador del nodo que estaba reiniciando y no era un problema de los nodos del Core. Este hecho fue demostrado en el mismo sitio (21.co) donde el gráfico fue originado, sin mencionar que fue hecho dentro del reporte de Stone, incluso luego de que se le solicitara revisar sus declaraciones.

Hay 3 explotaciones xthin-asserts (muy idénticas) que los desarrolladores del Unlimited publicaron inconscientemente durante este episodio, el cual causó también problemas en el Bitcoin Classic, quien también estaba vulnerable.

Encima de todo esto, el código vulnerable estuvo 10 meses sin ser detectado, y a pesar de que los desarrolladores de Unlimited (incluido Andrew Stone) declararon que encontraron el bug por su cuenta, esto cayó por su peso, resultando ser una mentira; un investigador de seguridad externo lo encontró en realidad y lo mostró al equipo (de Unlimited). Este investigador dijo lo siguiente sobre Bitcoin Unlimited:

Estoy preocupado de como un proyecto que apunta tomar el poder de una red que tiene una valoración de más de 20 mil millones de dolares pueda tener errores de principiantes como este.

Estoy decepcionado por el pobre nivel de la calidad del código de Bitcoin Unlimited y sospecho que es la superficie de mucho más.

El problema es que los bugs son increíblemente obvios que una vez arreglados, resulta muy fácil notar que cualquiera pudo haberlo observado en el proceso de desarrollo.

En este caso, la vulnerabilidad fue increíblemente obvia, y es por que evidentemente no han auditado su código por que esto sale tan simplemente con un pulgar adolorido.

Lo que aparenta ser un intento de distracción de la ineptitud fundamental de las vulnerabilidades expuestas, los seguidores de Bitcoin Unlimited (incluyendo Andrew Stone) intentaron cambiar el foco de la atención por un tuit de Peter Todd acerca de la vulnerabilidad, acusándolo de exponer los ataques y que los mismos exploten estas debilidades.

Pero otros desarrolladores de Unlimited revelaron que dichos ataques iniciaron antes de que Todd tuiteara acerca de la vulnerabilidad. Esto fue señalado varias veces, incluso por el mismo Todd, pero Stone lo ignoró una semana después, mintió descaradamente en un esfuerzo propagandístico de distraer el debate.

Este artículo es una traducción (original del autor) de un thread de Reddit hecho por sound8bits.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s