- PUBLICIDAD -

Bitcoin Cash Vigilante ‘Liquidates’ Fondos de Atacantes Blockchain Mejorados

Ledger Nano S - The secure hardware wallet

- Publicidad -

Por CriptomonedaseICO: un intento de interrupción de la cadena de bloques de Bitcoin Cash resultó en un resultado negativo para el atacante. Un participante de BCH con el nombre de usuario de Reddit, NilacTheGrim, se jactó ayer de que había "liquidado" los fondos criptográficos pertenecientes al supuesto bandido de blockchain.

Seguridad de direcciones débiles vuelve a Bite Bitcoin Cash Attacker

Para hacerlo, encontró una falla en el modelo de seguridad de la billetera utilizado por el atacante, que no se identificó ni se identificó en el momento de la impresión.

“Los atacantes usaron direcciones p2sh que tenían scriptsSigs fácilmente adivinables (carecían de una firma para canjear). (…) Acabo de liquidar aproximadamente ~ 1.2 BCH de sus fondos en este momento (…) Por lo tanto, verá que el mempool ahora tiene un montón de tx y tiene 18 MB completos al momento de escribir este artículo. "Estos tx son todos los tx especiales que tienen muchos sigops que hice para liquidar (tomar) los fondos del atacante".

No existe un gobierno que regule las interacciones en Bitcoin Cash o, en realidad, en Bitcoin Cash. Las personas pueden hacer lo que sea posible dentro de las reglas del consenso. Como tal, la idea de Changpeng Zhao de "reorganizar" la cadena de bloques de Bitcoin fue tomada muy en serio por personas que entienden que no hay nada que lo detenga, si tiene la capacidad.

Spam de un nuevo tipo

La intención del ataque inicial fue aparentemente interrumpir las operaciones normales de Bitcoin Cash. El atacante inyectó miles de transacciones inválidas en el mempool y dificultó que alguien hiciera transacciones regulares. El ataque coincidió con una bifurcación dura programada de la red.

Cabe destacar que BitcoinXT recientemente dejó la red de Bitcoin Cash, renunciando a los esfuerzos de desarrollo en protesta por los tenedores duros regularmente programados.

El origen del error que llevó al ataque no estaba claro de inmediato. Algunos observadores, como el profesor de Cornell Emin Gün Sirer, afirman que el error nació del código de la plantilla de bloque.

Otro espectador tiene una visión diferente del ataque, lo que tiene más sentido. Es posible enviar transacciones al mempool que usted sabe que nunca lo hará en bloques.

Los grupos mineros reaccionaron ante el ataque de correo no deseado al extraer bloques vacíos y alejarse de la cadena que los mantenía en el mempool (transacciones enviadas que aún no se han incluido en los bloques).

Algunos mineros se vieron obligados a explotar bloques vacíos debido a su diseño, que se explica más adelante.

Esta nueva bifurcación dio a algunos la impresión de que Bitcoin Cash estaba en un estado de flujo, con dos blockchains igualmente válidos existentes. Tal vez una prisa para juzgar, la conclusión trajo ira.

Respuesta de emergencia de cuatro horas de Bitcoin Cash

Bitcoin ABC, el equipo de desarrollo dominante en Bitcoin Cash, implementó un parche para sus nodos a las cuatro horas del ataque inicial.

Sin embargo, varios usuarios de Twitter que no les gustaba Bitcoin Cash aprovecharon la oportunidad para burlarse, tomar fotos y, en general, denigrar la criptomoneda.

Un ataque similar en Bitcoin habría tenido un impacto mucho más significativo, ya que el espacio limitado de bloques es un problema principal en su funcionalidad. Sin embargo, el ataque hubiera sido mucho más caro de realizar. El ataque no es posible actualmente en Bitcoin, por lo que sabemos, pero los errores se introducen y parchean regularmente en el desarrollo de código abierto.

Los orígenes de una inundación de spam

Este exploit en particular fue el resultado del código activado en noviembre pasado. Una nueva característica en Bitcoin Cash lo hizo posible, y quien lo descubrió optó por no reportarlo, pero esperó hasta que se realizara un ataque. El atacante probablemente esperaba que sus acciones tuvieran un mayor efecto disruptivo en Bitcoin Cash, lo que lleva a creer que no son partidarios.

Aquí hay una breve explicación del error:

“Cuando se acepta en mempool, la transacción se registra junto con su número de sigops.

“(…) Durante la aceptación de mempool, se analizan los scripts de la transacción y se cuenta cada aparición de un sigop. Cuando se introdujo OP_CHECKDATASIG durante la actualización de noviembre, el procedimiento que contó el número de sigops necesarios para saber si debería contar OP_CHECKDATASIG como sigop o como nada (desde antes de noviembre, no fue una operación de comprobación de firmas). La forma en que el procedimiento sabe qué contar se controla mediante una "bandera" que se pasa junto con el script. Si se incluye la bandera, OP_CHECKDATASIG se cuenta como un sigop; Sin ella, se cuenta como nada. En noviembre pasado, cada lugar que contaba con sigops incluía la bandera, EXCEPTO el lugar donde se registraron en mempool; en cambio, la bandera se omitió y las transacciones que usaban OP_CHECKDATASIG se registraron en mempool como que no tenían sigops. (…)

“El número de sigops para transacciones que utilizan OP_CHECKDATASIG se registra como cero, pero solo durante el paso de mempool, no durante ninguna de las otras operaciones. Así que estas transacciones OP_CHECKDATASIG pueden agruparse en el mismo bloque. El constructor de bloques prototipo cree que el bloque debería tener muy pocos sigops, pero el bloque real tiene muchos, muchos, sigops. (…) Sin embargo, dado que el nuevo bloque tiene demasiados sigops incluidos, el software de minería comienza a trabajar en un bloque vacío (lo que no es ideal, pero es más rentable que dejar a miles de ASIC sin hacer nada). (T) El bloque vacío se extrae y se transmite a la red. Es un bloque válido, pero no contiene ninguna otra transacción que no sea el coinbase. Nuevamente, esto se debe a que el bloque prototipo no se pudo validar debido a que tiene demasiados sigops ".

Si tuviéramos que nombrar el ataque, podríamos decir "ataque de inundación sigop", ya que eso es esencialmente lo que sucedió: los nodos de minería estaban sobrecargados con validaciones sigop, lo que los llevó a los bloques de minas sin transacciones válidas.

El vigilante de Bitcoin Cash descubrió una debilidad en las direcciones utilizadas por el atacante. Luego realizó un movimiento similar a una "inundación sigop" para drenar el saldo de la billetera del atacante. Las transacciones tardarán días en liquidarse, debido al parche posterior de la red de Bitcoin Cash.


¡Asegúrese de no perderse ninguna noticia importante relacionada con Criptomonedas! Siga nuestro feed de noticias de la forma que prefieras; a través de Twitter, Facebook, Telegram, RSS o correo electrónico (desplácese hacia abajo hasta la parte inferior de esta página para suscribirse). Bitcoin nunca duerme. Tampoco nosotros.


Descargo de Responsabilidad: Este comunicado de prensa es sólo para fines informativos, la información no constituye consejo de inversión o una oferta para invertir. Las opiniones expresadas en este artículo son las del autor y no representan necesariamente los puntos de vista de CriptomonedaseICO, y no deben ser atribuidas a, CriptomonedaseICO.


Síguenos en Telegram

- PUBLICIDAD -

- PUBLICIDAD -

Deja una respuesta

Su dirección de correo electrónico no será publicada.

1 + dieciseis =

Suscríbete a nuestro Boletín de Noticias
Regístrese aquí para recibir las últimas noticias y actualizaciones directamente en su bandeja de entrada.
Puedes darte de baja en cualquier momento

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More


Notice: ob_end_flush(): failed to send buffer of zlib output compression (1) in /home/criptomo/public_html/wp-includes/functions.php on line 4212

Notice: ob_end_flush(): failed to send buffer of zlib output compression (1) in /home/criptomo/public_html/wp-includes/functions.php on line 4212