Esta nota es para avisar y tranquilizar a nuestra comunidad de que Beam Team está dedicado a mantener nuestra red descentralizada a salvo de ataques.
Descargar Beam Android Wallet | Beam iOS Wallet | Beam Desktop Wallet
Mitigando los ataques de doble gasto
Antes del reciente cambio de consenso en Beam, donde nos mudamos de BeamHashII a BeamHashIII, intentamos llegar a intercambios y grupos para ayudarnos a mitigar cualquier posibilidad de actividad irregular con la cadena de bloques de Beam.
Específicamente, para ayudarnos a combatir cualquier ataque invisible en la red donde un minero podría tener más del 50% del hashrate de la red.
Nos aseguramos de que la mayoría de los intercambios implementaran tiempos de confirmación más largos para los depósitos de Beam, y también introdujimos un punto de control móvil de 60 bloques, un mecanismo que evita las reorganizaciones a más de 60 bloques.
Desafortunadamente, hubo un número mínimo de Exchange que no reconocieron la solicitud de extender los tiempos de confirmación.
Solicitud importante para Exchange y manejadores OTC: permita al menos 70 confirmaciones de bloque antes de aceptar fondos de usuario.
Entonces, en el pasado poco tiempo, hemos notado cierta actividad irregular de la red y, como resultado, sentimos que es correcto emitir esta declaración.
A continuación se muestra la línea de tiempo de los ataques conocidos y los pasos que tomamos para mitigarlos.
27–05–2020
Eventos
Varias reorganizaciones grandes ocurrieron en una fila.
- 730833 -> 730779 -> 730873 (-54, +94)
- 730938 -> 730902 -> 731048 (-36, +146)
- 731075 -> 731066 -> 731116 (-9, +50)
Investigación:
Teníamos 16 nodos mainnet públicos, de los cuales recolectamos y analizamos sus registros para ver la imagen completa.
Principalmente para entender mejor, si tal vez fue un ataque deliberado, o si las reorganizaciones de la cadena ocurrieron espontáneamente.
En este caso, los registros no mostraron una imagen coherente.
Vimos desviaciones considerables en el estado de nuestros nodos debido a la mala conectividad entre nodos.
Diferentes nodos siguieron diferentes ramas durante una duración significativa, mientras que ocurrieron reorganizaciones irregulares y esporádicas.
Nuestras conclusiones:
- La mala conectividad de red, las divisiones de red espontáneas (naturales) no se pueden descartar, y esta podría ser una explicación lógica para las reorganizaciones.
- El ataque fue posible, pero no confirmado.
Nuestras acciones:
- Tomamos medidas para reforzar la conectividad entre nodos.
- Se corrigieron algunos problemas en la gestión dinámica de pares
- Posibilidad adicional de configurar pares permanentes, es decir, pares con los que el nodo debe mantener la conexión constantemente
- Actualizamos todos nuestros nodos de mainnet, los configuramos para mantener una conexión permanente entre ellos, para tener un clúster súper conectado.
- Aconsejó a todos los grupos e intercambios conocidos que hicieran lo mismo
11–06–2020
Eventos
2 grandes reorganizaciones ocurrieron en una fila.
- 753811 -> 753796 -> 753815 (-15, +19)
- 753904 -> 753821 -> 753927 (-83, +106)
Investigación:
Recopilamos y analizamos registros de todos nuestros 16 nodos de mainnet. Esta vez mostraron una imagen perfectamente consistente; todos estaban sincronizados, y cada uno experimentó exactamente las mismas reorganizaciones al mismo tiempo. Entonces este problema de conectividad de red descarta.
Entonces, parecía que un minero muy poderoso extraía durante un período de tiempo aislado. Pero la pregunta aún permanecía: ¿fue este un ataque deliberado, o tal vez el grupo minero más poderoso perdió la conexión temporalmente?
Analizamos los bloques reordenados y notamos que en su mayoría estaban vacíos, pero algunos de ellos contenían una sola transacción.
Esto fue coherente con la forma en que se podría desarrollar un ataque.
De forma aislada, no debe haber transacciones, el usuario solo puede enviarse fondos a sí mismo (en MW, las transacciones se crean mutuamente).
Enviar fondos a usted mismo: parece un doble gasto deliberado. Además, notamos anomalías en el hashrate de la red.
Durante la duración del (supuesto) ataque, el índice de hash de la comunidad honesta se redujo considerablemente, pero el (supuesto) índice de ataque fue significativamente mayor que esta caída. Lo que significa; Si estimamos el hashrate total de la red, aumentó dramáticamente.
Descubrimos que durante este tiempo hubo pedidos de hashpower anormalmente grandes en NiceHash.
Nuestras conclusiones:
El ataque de doble gasto es muy probable.
Complejidad del ataque: modesto
- El aislamiento temporal se puede lograr ajustando el firewall.
- No es necesario conocer ni modificar nuestro código.
Costo del ataque.
- Dados los precios actuales de Beam y la dificultad minera, es factible.
- Si el ataque es exitoso, el atacante también obtiene las recompensas de los bloques, lo que reduce aún más el costo
Nuestras acciones:
Implementamos un mecanismo de punto de control continuo que evita la reorganización automática a más de 60 bloques.
- Instruyó a todos los grupos e intercambios que tengan al menos 80 confirmaciones para depósitos
- Nos dimos cuenta de que nuestro cambio a la regla del consenso puede conducir a una división de la red, por lo que también hicimos lo siguiente:
- Se agregaron mecanismos de detección y alerta de división de red
- Capacidad para que el usuario pueda reorganizar manualmente
- Reorganización automática a profundidad arbitraria en caso de que se abandone la rama actual. Esto es para facilitar las cosas a los usuarios comunes. En caso de división de la red, una vez que el ataque haya terminado, sus nodos se reorganizarán automáticamente después de un tiempo.
15–07–2020
Eventos
4 grandes reorganizaciones ocurrieron dentro de varias horas durante la noche. 2 reorganizaciones más durante el día siguiente. 2 reorganizaciones en la tarde y noche siguientes.
- 800823 -> 800788 -> 800833 (-35, +45)
- 800923 -> 800913 -> 800938 (-10, +25)
- 800979 -> 800958 -> 800991 (-21, +33)
- 801014 -> 800994 -> 801021 (-20, +27)
- 802281 -> 802240 -> 802290 (-41, +50)
- 802341 -> 802321 -> 802351 (-20, +30)
- 803422 -> 803366 -> 803431 (-58, +65)
Investigación:
Todas las reorganizaciones siguen el mismo patrón que observamos anteriormente. Los bloques reordenados están en su mayoría vacíos, con solo unas pocas transacciones (que parecen doble gasto).
- Las mismas fluctuaciones de hashrate.
- Ninguno de los cambios fue superior a 60 bloques, como se esperaba.
- No hay división de red
Esta vez analizamos más a fondo los bloques reordenados donde sospechábamos que había un doble gasto contenido dentro de ellos.
Esto mostró que el bloque de reemplazo gasta parte de la entrada que se gastó también en el bloque original, mientras que las salidas del bloque de reemplazo son diferentes. Es decir, el bloque original contenía A-> B, mientras que el bloque de reemplazo contenía A-> C.
Desafortunadamente, no pudimos realizar el mismo análisis en reorganizaciones anteriores, porque nuestros nodos no mantuvieron bloques reordenados (huérfanos) para siempre. Sin embargo, podríamos hacer esto para las reorganizaciones más recientes. Y esto es lo que descubrimos.
- 803422 -> 803366 -> 803431
- H = 803424 Doble gasto. Altura original = 803375
- 802341 -> 802321 -> 802351
- H = 802330 Doble gasto. Altura original = 802329
- 802281 -> 802240 -> 802290
- H = 802250 Doble gasto. Altura original = 802246
Así que para los últimos 3 reorgs estamos CIERTOS. Este es un gasto doble. También sabemos la altura exacta de gasto de la transacción original (revertida).
Lo que no quedó claro es ¿POR QUÉ el atacante sigue haciendo esto? Las reorganizaciones de no más de 60 bloques no deberían causar la pérdida de fondos en los intercambios, ya que deberían tener al menos 80 confirmaciones.
Más tarde en la noche descubrimos valores comerciales anormales en algunos Exchange conocidos y descubrimos que, contrariamente a nuestro consejo, han tenido un pequeño número de confirmaciones para los depósitos de Beam.
Nuestras conclusiones:
- El atacante había identificado intercambios con un pequeño número de confirmaciones y pudo realizar el ataque repetidamente. Lamentablemente, los intercambios no notaron esto a tiempo, a pesar de nuestros mejores consejos previos y su pérdida de fondos.
- Es probable que el atacante también haya intentado realizar el ataque en otros intercambios, pero no tuvo éxito.
- Algunos otros intercambios con los que contactamos en este asunto informaron que tenían depósitos en las alturas correspondientes, pero fueron revertidos. Afortunadamente, tomaron nuestros consejos y permitieron un número suficiente de confirmaciones para depósitos de Beam.
- El atacante también podría haber intentado reorganizaciones más profundas (para atacar otros intercambios), pero no tuvo éxito.
- Además de robar fondos de los intercambios, el atacante pone en riesgo la red
- Algunas transacciones dependientes pueden no recuperarse después de la reorganización, causando inconvenientes a los usuarios
- Se impone el riesgo de división de la red.
Nuestras acciones:
- Nos contactamos urgentemente con los intercambios afectados que encontramos y les pedimos que aumentaran el número de confirmaciones.
- Estamos trabajando en nuestra API para grupos e intercambios, de modo que su billetera seleccione solo UTXO «maduros» para las transacciones, para evitar el fracaso de las transacciones «accidentales» debido a la reversión de las transacciones de antepasados. Para reducir los posibles efectos secundarios de las reorganizaciones.
Esta ha sido una investigación muy exhaustiva y profunda por parte de nuestro equipo para identificar y mitigar estos ataques y no es un evento único para Beam. Es un posible escenario para cualquier criptomoneda.
En el análisis de los eventos, nos gustaría asegurar y agradecer a nuestra comunidad por su paciencia y comprensión durante este momento de coacción.
Finalmente, nos gustaría que los mineros consideren la mejor manera de ayudarnos mientras monitoreamos y mitigamos estos eventos de ataque. Únase a grupos más pequeños, refuerce su red descentralizada de Beam extendiendo su hashrate, proteja sus recompensas extraídas de los reagrupamientos y no permita que estos atacantes perpetúen en grupos con sobrepeso. No los habilite centralizándose en las piscinas más grandes.
¡Ven a descubrir Beam y únete a nuestra comunidad!
Descargar Beam Android Wallet en Google Play
Descargar Beam iOS Wallet en App Store
Obtenga más información sobre Beam en nuestro sitio web y blog
Telegram: t.me/BeamPrivacy
QQ Beam 中国 官方 社区 : https://jq.qq.com/?_wv=1027&k=5Mbs8N4
Reddit: reddit.com/r/beamprivacy/
Twitter: twitter.com/beamprivacy
