Revisamos las cadenas ocultas y el doble gasto, con el White Paper. por Steve Shadders

Revisamos las cadenas ocultas y el doble gasto, con el White Paper.

por Steve Shadders

13 de agosto de 2021

https://bitcoinsv.io/2021/08/13/on-the-whitepapers-view-of-hidden-chains-and-double-spends/

 

 

Introducción

Bitcoin SV ha sido recientemente objeto de ataques por parte de un actor con un poder de hash sustancial y que intenta defraudar millones de dólares en BSV. En este artículo describimos los ataques, los esfuerzos de movilización y la eventual respuesta exitosa.

Eventos como este siempre te obligan a mirar los elementos de Bitcoin de formas que quizás no hayas considerado fuera del nuevo contexto. También echaremos un vistazo al documento técnico de Bitcoin (White Paper) y lo que podría tener que decir sobre este tipo particular escenario y cómo debería responderse.

TL;DR; Estoy 100% seguro de que lo que las acciones tomadas por los mineros fue lo que se esperaba, de acuerdo con el documento técnico. Y tengo más confianza que nunca en la capacidad de resistencia de Bitcoin, incluso frente al abrumador poder de hash.

Antecedentes:

Ataques – primera oleada

El 24 de junio de 2021, un bloque 4 se observó en la reorganización de la cadena principal (MainNet) de BSV,  que implicó un nuevo minero fusionado de Hathor a «Zulupool». En ese momento, tenía las características de un nodo mal conectado con un poder de hash significativo simplemente teniendo una reorganización accidental. El equipo de infraestructura de Bitcoin SV se acercó a este minero para ofrecerle asistencia técnica para mejorar sus conexiones con otros mineros, pero no recibió una respuesta.

Durante la primera semana de julio, se produjeron más reorganizaciones de duración similar. Nos comunicamos por segunda vez y Zulupool respondió indicando que en realidad no eran ellos quienes extraían esos bloques. El atacante estaba usando el nombre Zulupool en la cadena de la base de monedas y pagando a la dirección de pago de Zulupool . Por razones que explicaremos más adelante en este artículo, creemos que la afirmación real de Zulupool es creíble, que en realidad no estaba extrayendo los bloques involucrados con las reorganizaciones.

El equipo de infraestructura de Bitcoin SV se dispuso de inmediato a crear herramientas, para detectar la presencia de dobles gastos, así como a interactuar con los miembros del equipo de la Asociación de Bitcoin y los mineros para establecer una respuesta adecuada y crear canales de comunicación. La Asociación de Bitcoin también se acercó a los Exchanges para alertarlos y también para ver si podíamos identificar a las víctimas del doble gasto. Durante el transcurso de esta primera ola de ataques, no se nos informó de ninguna víctima y pusimos en marcha herramientas para automatizar la detección y notificación. (Más tarde supimos de las presentaciones judiciales públicas realizadas por el Exchange de activos digitales de Bitmart , que sufrió una pérdida de monedas BSV por doble gasto, que el atacante intercambió ilegalmente por otras monedas).

Una vez que estas herramientas estuvieron en su lugar, el atacante quedó inactivo durante varias semanas.

Ataques – segunda ola

El 3 y 4 de agosto, en tres ocasiones distintas, un atacante malintencionado desconocido, extrajo en secreto cadenas ocultas de bloques (Selfish Mining), que contenían transacciones de doble gasto de BSV, por valor de varios millones de dólares. Luego, el atacante liberó estas largas cadenas de bloques de una vez en la red BSV, superando temporalmente a la cadena honesta. Esta vez, el atacante se hacía pasar por el honesto minero TAAL.

Respuesta

Los preparativos implementados después de los ataques anteriores permitieron al Equipo de Infraestructura de Bitcoin SV detectar estos bloques fraudulentos a los pocos segundos de su lanzamiento y comunicarse rápidamente con mineros conocidos y honestos, que optaron por rechazar los bloques fraudulentos con su propio poder de hash, eventualmente superando la bifurcación del atacante y evitando que sucediera el doble gasto. Al mismo tiempo, la Asociación de Bitcoin se puso en contacto con los Exchanges, para informarles lo que estaba sucediendo y recomendó una respuesta protectora que los mantendría sincronizados con lo que la mayoría de los mineros habían elegido hacer.

Después de tres intentos fallidos de robar fondos de los intercambios el 3 y 4 de agosto, el atacante finalmente se rindió cuando aparentemente se dieron cuenta de que los mineros honestos continuarían rechazando bloques ocultos con dobles  gastos.

Tenga en cuenta que durante este tiempo, la Asociación de Bitcoin publicó el comando que habían utilizado los mineros honestos, para invalidar los bloques previamente ocultos del atacante, que contenían gastos dobles. Esto se debía a que se sabía que la cadena del atacante podría tardar algún tiempo en ser superada por mineros honestos y dio a otros operadores (no mineros) del software Bitcoin SV Node (como las aplicaciones que operan como oyentes de bloques) el mecanismo para siga la cadena sobre la que estaban construyendo la mayoría honesta de los mineros, antes de que se convirtiera en la cadena más larga. Desde el punto de vista de la red BSV, no se permitió que ocurrieran gastos dobles durante esta segunda ola de ataques. El atacante gastó aproximadamente $ 200k USD con la esperanza de obtener una mayor ganancia financiera a través del fraude, pero no lo hizo, lo que resultó en una pérdida de $ 200k. Mientras tanto, la red continuó sin obstáculos, procesando un volumen récord de transacciones e incluso varios bloques récord de 1GB.

 

Explicación del libro blanco de Bitcoin sobre las acciones de los mineros

Los mineros, encargados de la responsabilidad de hacer cumplir las reglas establecidas en el protocolo de Bitcoin, esencialmente tomaron medidas para rechazar las transacciones no válidas y, por lo tanto, los bloques que las contenían, sobre la base de la ‘primera regla vista’ tal como se define en el documento técnico de Bitcoin.

¿Qué significa primera vista?

Primero visto significa precisamente lo que dice: «Primero visto». (first seen.) La determinación de la primera vez que se vio requiere una observación directa en el momento de los eventos, a quién se debe determinar el orden. La cadena de bloques de Bitcoin proporciona un mecanismo, para convertir las observaciones directas de un conjunto de nodos igualitarios, en un registro preciso de los primeros eventos observados.

Debemos tener cuidado de distinguir entre dos puntos de vista subjetivos cuando hablamos de «lo visto por primera vez». Existe la vista de los participantes activos en la red en el momento del evento. Tienen conocimiento directo de primera mano de lo primero que se ve por observación. Cuando dos eventos relacionados están separados por un período de tiempo significativo (más que la latencia de transmisión), esta vista es indiscutible. Llamemos a esto el «punto de vista observado ( PoV )» observed point-of-view.

La otra opinión es la de alguien que más tarde se pondrá al día con la historia. Llamemos a esto el » Punto de vista histórico» historical PoV . Dado que no estaban presentes y eran capaces de observar directamente el orden de los eventos , deben confiar en el registro que producen los nodos a través de la cadena de bloques más larga. Si los que observan, actúan sobre la regla visto por primera vez de forma fiable como lo hicieron recientemente, para presentar el registro, entonces la cuestión de la que, a partir de dos pruebas celebradas (doble gasto) es el primer visto desde el histórico POV coincide con el observado POV que es el objetivo principal de Bitcoin. Al tener un registro de este orden correcto, los nuevos participantes pueden unirse a la red con una vista precisa del estado de todos los UTXO y asegurarse de que todas las transacciones futuras que confirmen gasten Bitcoins que a) existen y b) no se han gastado ya.

No puede haber cierta ambigüedad, potencialmente, durante un corto período de la histórica POV si hay varios consejos de cadena activos con puntos impugnados de vista de la competencia (bloques que contienen doble gasto) en el momento de que nuevo participante se incorpore. Pero esto es relativamente raro y se resuelve en poco tiempo. Esto solo es relevante para alguien que se une a la red durante este período. Los demás, incluso si solo escuchan, pueden observar, simplemente no participan en la creación del registro. Sin embargo, para la gran mayoría de las transacciones que no son impugnadas, queda claro que un evento ocurrió incluso durante esta ventana.

Lo interesante es si el Bitcoin el documento técnico describe el punto de vista observado o histórico. Porque esto se refiere a la cuestión de si debería aceptarse una cadena de bloques más larga que contenga un registro obviamente falso. Si describe el punto de vista observado, no hay duda de que los nodos que saben que un registro (bloque) es incorrecto deben rechazarlo. Solo se vuelve relevante desde el punto de vista histórico cuando no se puede conocer el orden de los eventos y se debe confiar en el consenso de los nodos.

Mi propia interpretación es que el libro blanco describe un mecanismo para convertir el histórico POV en un registro confiable de manera que pueda servir como un histórico preciso POV .

Hay varias declaraciones en el libro blanco que simplemente no tienen sentido si se considera desde el histórico POV . Algunos de estos se detallan a continuación …

Sección 1 Introducción:

La meta:

«Un servidor de marca de tiempo distribuido de igual a igual para generar una prueba computacional del orden cronológico de las transacciones»

Tenga en cuenta que para que se genere una prueba cronológica en primer lugar, ese orden cronológico debe determinarse primero mediante observaciones subjetivas de los eventos a medida que ocurren. La aceptación de esas observaciones (en forma de bloque) por la mayoría de los nodos en ese momento es la confirmación requerida de que las observaciones fueron correctas y acordadas por la mayoría de todos los nodos de observación activos en ese momento.

Definición de fraude con un sistema de efectivo p2p: (a peer-to-peer cash system)

«Las transacciones cuya reversión no es práctica desde el punto de vista computacional protegerían a los vendedores del fraude»

Es decir, que una vez que se recibe y acepta una transacción, el autor considera que su anulación es un fraude.

Sección 2: Transacciones

Definición de válido en presencia de doble gasto:

“Necesitamos una forma para que el beneficiario sepa que los propietarios anteriores no firmaron ninguna transacción anterior. Para nuestros propósitos, la primera transacción es la que cuenta, por lo que no nos preocupan los intentos posteriores de realizar un doble gasto «.

Tenga en cuenta que no es posible que aparezcan dos versiones de una transacción en la cadena de bloques más larga. Tampoco es posible, solo a partir de las marcas de tiempo de los bloques, determinar con certeza cuál de los dos bloques en competencia ocurrió o se transmitió públicamente primero en tiempo real de reloj de pared. Entonces, el término ‘más temprano’ aquí solo puede aplicarse a la vista subjetiva observada por los nodos activos en la red en ese momento.

No se da una ponderación especial u otra consideración a las transacciones en un bloque, para anular la noción de ‘más temprana’.

La necesidad de la transmisión pública:

«La única forma de confirmar la ausencia de una transacción es estar al tanto de todas las transacciones»

‘Todas las transacciones’ incluye transacciones confirmadas y no confirmadas.

«Para lograr esto sin una parte de confianza, las transacciones deben anunciarse públicamente»

Esta transmisión pública es fundamental para que las observaciones subjetivas puedan ser realizadas por todos los nodos activos en la red, lo que nos lleva de vuelta a …

De vuelta a la meta:

«El beneficiario necesita prueba de que en el momento de cada transacción, la mayoría de los nodos acordaron que fue el primero en recibir»

Desde el punto de vista del beneficiario, esto es importante porque quieren saber que los Bitcoins que están recibiendo son válidos.

Nuevamente, esto solo es posible cuando se considera la vista subjetiva observada por los nodos activos en la red en el momento del evento de doble gasto. Y es la razón por la que las transacciones deben anunciarse públicamente.

Sección 5: La red

Instrucciones que definen la red:

«Las nuevas transacciones se transmiten a todos los nodos»

Esto es bastante inequívoco. Ocultar una transacción mientras se transmite simultáneamente una transacción en conflicto no solo viola esta regla, sino que define explícitamente que la transacción de transmisión es válida mientras que la transacción oculta es el gasto doble no válido.

Los bloques deben transmitirse:

«Cuando un nodo encuentra una prueba de trabajo, transmite el bloque a todos los nodos»

Esta regla aclara exactamente cuándo se debe transmitir un bloque. Que es inmediatamente después de encontrar una prueba de trabajo válida y formar el encabezado válido.

Los bloques válidos deben contener transacciones que aún no se hayan gastado:

«Los nodos aceptan el bloque, sólo si todas las transacciones en él son válidas y no se han gastado».

Como hemos visto anteriormente, «no gastado ya» es desde el punto de vista del observador. Si han visto anteriormente una versión conflictiva de cualquier transacción en el nuevo bloque, entonces el bloque no es válido.

Carreras en bloque:

“Si dos nodos transmiten diferentes versiones del siguiente bloque simultáneamente, algunos nodos pueden recibir primero uno u otro. En ese caso, trabajan en la primera que recibieron, pero guardan la otra rama en caso de que se alargue. El empate se romperá cuando se encuentre la siguiente prueba de trabajo y una rama se alargue; los nodos que estaban trabajando en la otra rama cambiarán a la más larga «.

Satoshi no aborda el caso de bloques competidores ocultos en esta sección, solo bloques competidores que se transmiten casi exactamente al mismo tiempo. Los bloques en competencia que se ven en momentos muy diferentes solo se tratan en la sección del documento técnico que trata de los ataques a la red.

Sección 11: Cálculos

El Bitcoin El documento técnico deja en claro que una cadena de bloques extraídos en secreto es deshonesta:

«Una vez que se envía la transacción, el remitente deshonesto comienza a trabajar en secreto en una cadena paralela que contiene una versión alternativa de su transacción»

El minero de bloques secretos se conoce de nuevo como el «atacante».

«Para obtener la probabilidad de que el atacante pueda alcanzarlo ahora»

Sección 12: Conclusión

Aquí vemos el propósito de Bitcoin descrito nuevamente:

«Para resolver esto, propusimos una red peer-to-peer que usa prueba de trabajo para registrar un historial público de transacciones que rápidamente se vuelve impráctico computacionalmente para que un atacante cambie si los nodos honestos controlan la mayor parte de la potencia de la CPU»

El objetivo del servidor de marca de tiempo es evitar que un ‘atacante’ cambie el registro del historial PÚBLICO que ya es observado subjetivamente y acordado por la mayoría de los nodos de la red en el momento anterior en el que realmente sucedieron los eventos. Ese registro incluye el orden en que se vieron los eventos (transacciones y bloques). No implica que un ataque de bloque oculto exitoso deba considerarse la versión HONESTA de ese registro, especialmente cuando todos los que están activos en la cadena en el momento de los eventos saben que no lo es.

Bloques válidos:

«Votan con la potencia de su CPU, expresando su aceptación de bloques válidos trabajando para extenderlos y rechazando bloques inválidos negándose a trabajar en ellos»

Esto se reduce a la definición de un bloque válido. Ya sabemos de la Sección 5: que solo debe contener transacciones válidas, y de la Sección 2: que las transacciones válidas deben ser las primeras vistas de cualquier conjunto de gastos dobles observados subjetivamente por participantes honestos en ese momento.

Finalmente, regresemos a la oración final del Resumen:

«Los nodos pueden salir y volver a unirse a la red a voluntad, aceptando la cadena de prueba de trabajo más larga como prueba de lo que sucedió mientras estaban fuera»

Existe una diferencia significativa entre aceptar la cadena de prueba de trabajo más larga como prueba de lo que sucedió mientras usted no estaba presente; y aceptarlo si estuvo presente y sabe que no es válido. El objetivo original descrito en la sección 1 es generar esa prueba y corresponde a los nodos activos en el momento de producirla. El documento técnico es claro que un historial no válido debe ser rechazado por los nodos con conocimiento de esa invalidez y escribir el historial correcto en su lugar, asegurando que se convierta en parte de la cadena de prueba de trabajo más larga.

Eso es exactamente lo que hicieron los mineros honestos, presentes en el momento del ataque.

El código no es ley, ni tampoco la definición de Bitcoin

Bitcoin es un sistema económico que describe el comportamiento previsto . Como tal, el software y los algoritmos no lo anulan. El software en sí es una implementación de un algoritmo que puede automatizar la aplicación del objetivo en casi todos los casos, pero los algoritmos nunca son perfectos. La realidad es que, en un sistema contradictorio, cada intento de codificar una regla algorítmicamente abre la posibilidad de que ese algoritmo se use de una manera que no tenía la intención de atacar el sistema. Y algunas reglas son simplemente difíciles de codificar a prueba de ataques.

Un ejemplo de esto serían las reglas de codificación para detectar y automáticamente los bloques huérfanos que contienen gastos dobles. Sé que he intentado definir un conjunto de reglas viable para este propósito muchas veces, que es fácil de hacer para los escenarios comunes y probablemente protegería muy bien a los usuarios, pero abre muchos ataques potenciales que pueden causar divisiones de cadena con acciones oportunas por un atacante.

Incluso la primera regla vista en sí misma, es difícil de codificar de manera confiable en presencia de latencia de red y, aunque podría resolverse mediante la codificación de carreras de bloques forzadas en la mayoría de los casos, los casos complejos que involucran múltiples conjuntos de gastos dobles pueden hacer que dos conjuntos de nodos estén en desacuerdo permanentemente. y persistentemente separados el uno del otro. Estoy bastante seguro de que esta es la razón por la que el Bitcoin original se codificó de la forma en que estaba en lugar de hacer cumplir esta regla sin piedad hasta el milisegundo.

El caso es que el código no es perfecto y, a veces, los humanos intervienen. Esto ha sucedido a lo largo de la historia de Bitcoin. El objetivo de Bitcoin es producir un registro persistente y confiable de lo que sucedió en la red. Ese objetivo se cumple con los nodos que observan, registran y, si es necesario, toman medidas manuales para garantizar que el registro sea preciso y no contenga fraude. Muchos mineros pueden tomar estas acciones de forma independiente y con poca o ninguna coordinación porque es relativamente fácil encontrar consenso sobre la verdad.

Esos registros van mucho más allá de lo que se registra en la cadena de bloques. Y esos registros también se están utilizando como evidencia adicional de eventos pasados. Es un proceso mucho más manual hacer coincidir los archivos de registro de cientos de máquinas independientes, pero esa evidencia es igualmente útil.

 

El papel de MinerID

Ha habido muchas preguntas y comentarios sobre el papel de MinerID para abordar estos ataques recientes. Lo que vimos allí fue algo inusual en el sentido de que el atacante se hacía pasar por otros mineros ( Zulupool y luego TAAL) e incluso usaba las direcciones de pago de esos mineros. En el caso de la suplantación de TAAL, esto fue evidente debido al hecho de que TAAL firma rutinariamente sus bloques con MinerID , por lo que la presencia de una gran cantidad de bloques que no estaban firmados inmediatamente creó una señal de alerta de que la suplantación estaba en juego. También sucedió para facilitar la identificación de bloques de atacantes en este caso.

MinerID puede desempeñar muchas funciones más en la creación de confianza con los mineros a través de la reputación de prueba de trabajo ganada con esfuerzo. En el futuro, garantizará que los mineros tengan canales de comunicación rápidos y confiables entre sí en caso de escenarios de ataque u otros eventos críticos de la red.

Para obtener más detalles sobre MinerID, consulte: https://github.com/bitcoin-sv-specs/brfc-minerid

Respuestas futuras

Si bien la respuesta implementada fue eficaz y se puede repetir, se puede mejorar aún más. Hay varios cambios de comportamiento predeterminados en el software Bitcoin SV Node que se pueden implementar y una serie de otras medidas de mitigación, herramientas, procesos operativos, etc.

Por razones obvias de seguridad, estas medidas se darán a conocer una vez que estén listas para ser implementadas a fin de no señalar ningún vector potencial de ataque. Muchas de las mejores mentes en la infraestructura de Bitcoin han estado trabajando en estos problemas en todo momento y continuarán haciéndolo hasta que todos los aprendizajes que se hayan absorbido de estos incidentes se hayan convertido en respuestas operativas y de código.

Sin embargo, uno de los principales problemas que esto resalta es la necesidad de un monitoreo activo de los eventos en la red y la disponibilidad de operadores humanos capacitados, así como canales de comunicación sólidos entre los actores corporativos. Cualquier sistema financiero que valga la pena existente tiene centros de operaciones 24 horas al día, 7 días a la semana , sistemas de monitoreo continuo. Estos ya existen en la red Bitcoin SV, pero esa capacidad de monitoreo operativo ahora es mucho más fuerte e interconectada de lo que estaba.

Conclusión

En última instancia, el documento técnico de Bitcoin describió un conjunto de comportamientos necesarios para que el protocolo Bitcoin funcione correctamente. La mayor parte de esto se puede automatizar algorítmicamente y, con el tiempo, más se automatizará. Pero no siempre es práctico expresar una regla algorítmicamente sin abrir posibles vectores de ataque cuando el algoritmo se usa maliciosamente, por lo que ocasionalmente se requiere el juicio y la intervención humanos. Bitcoin no es un código, es un sistema de múltiples partes independientes que imponen un conjunto de reglas y rechazan las violaciones de ese conjunto de reglas por parte de otras partes.

Artículos

por Steve Shadders

Steve ha estado involucrado en la infraestructura de Bitcoin desde principios de 2011. En su rol, contribuye con su perspectiva de todo el ecosistema, para apoyar la construcción de la infraestructura de minería y UX, necesaria para habilitar la Visión de Satoshi.

 

Revisamos las cadenas ocultas y el doble gasto, con el White Paper.

por Steve Shadders

13 de agosto de 2021

https://bitcoinsv.io/2021/08/13/on-the-whitepapers-view-of-hidden-chains-and-double-spends/