¿Se puede detectar y tratar un ataque del 51 %?

¿Se pueden detectar estos ataques? Sí.

Lo que vería es una reorganización de la cadena que invalida una gran cantidad (más de tres) de bloques previamente aceptados. El cliente estándar realmente registrará esto; verá un en el archivo REORGANIZEdel cliente . debug.logEl cliente actualmente no registra la cantidad de bloques invalidados por la reorganización, pero eso es una mejora simple.

¿Pueden los usuarios honestos revertir tales ataques? Algo así como.

Si una transacción que le interesa está en el conjunto de bloques que fue invalidado, siempre puede volver a enviar esa transacción. A menos que el remitente haya emitido una transacción conflictiva como parte de un ataque de doble gasto, la transacción seguirá siendo válida. (La red en realidad hará esto por usted automáticamente. Los mineros no quieren perder la oportunidad de obtener las tarifas de transacción asociadas con las transacciones deshechas).

Como solución a más largo plazo, se han discutido propuestas para rechazar reorganizaciones que invaliden sospechosamente grandes cantidades de bloques, como cuatro o más. El problema con estas propuestas es que, en circunstancias inusuales (como si un desastre divide Internet durante media hora), la red puede dividirse permanentemente y cada lado rechaza la cadena de bloques del otro lado como una reorganización sospechosa.

Esencialmente, el cliente tendría que ir a un modo de "bloqueo" si esto sucediera y rechazar todas las transacciones hasta que se pudiera implementar algún mecanismo para encontrar la cadena de bloques real. (¡Podría enviar todas las transacciones a ambas cadenas y considerar solo las transacciones aceptadas en ambas como confirmadas!) Una propuesta utiliza una autoridad central para elegir la cadena real. Esta es un área donde hay espacio para la innovación.

Sin embargo, un punto importante a tener en cuenta: si el remitente no está intentando un ataque de doble gasto, no tiene nada de qué preocuparse (aparte de la utilidad reducida de una red de intercambio inestable). Puede enviar la transacción a la cadena de bloques tantas veces como sea necesario hasta que finalmente gane algún bloque que contenga la transacción. Solo el remitente puede crear una transacción en conflicto que le impediría incluir la transacción que le interesa en la cadena.

Actualización: de hecho, puede perder monedas incluso si el remitente no estaba intentando un ataque de doble gasto. Supongamos que A envía dinero a B y luego B envía dinero a C, si A usa con éxito un ataque de doble gasto para invalidar la transacción que envió las monedas a B, el envío de B a C puede fallar (porque una transacción en conflicto significa que B nunca tendrá los fondos para gastar) aunque B no estaba intentando un ataque de doble gasto.

Un comentario sobre “empezar de cero”.

Se han codificado varios puntos de control en la fuente del cliente (los hashes de los bloques se agregan regularmente en las nuevas versiones del cliente) precisamente para reducir el impacto de las grandes reescrituras de los grandes fragmentos de la cadena. El historial de transacciones generado en los primeros días de bitcoin podría reescribirse fácilmente con todo el poder de procesamiento disponible para los mineros en la actualidad. Pero los clientes recientes no pueden ser atraídos de esta manera debido a estos puntos de control.

Alguien con el 51% de la potencia informática total podría comenzar a reescribir el historial desde el último punto de control, pero no puede ir más allá en el pasado. Además, para que el ataque sea efectivo, uno debe adelantar la cadena de la red antes de que la mayoría de los nodos acepten el siguiente punto de control.

Tiene que haber una consecuencia para el atacante, lo suficientemente grande como para que sienta el golpe de su propio ataque.

Para crear la consecuencia para él: el votante (nodo confiable/nodo completo) debe tener bitcoin, y cuanto más bitcoin tenga el nodo, más poder de voto (más confiables son). Ejemplo, si el atacante realmente quiere acabar con toda la red de bitcoin, debe tener al menos el 51% de bitcoin en circulación. Si una red de bitcoin vale $ 100 mil millones. Tiene que comprar 50 mil millones de dólares. Intenta acabar con la red y perderá sus 50.000 millones de dólares. Sí, otros perderán un poco de valor, pero él perderá mucho más valor y podemos comenzar con otra criptomoneda.

No tiene que ser un poder de voto lineal de 1 bitcoin = 1. Puede ser una función. como poder de voto = root2 (bitcoin), u otras funciones.

El único problema con esto es que la mayoría de las personas usarán un nodo centralizado (porque están usando un nodo ligero y no quieren desperdiciar recursos para un nodo completo), por lo que su poder de voto puede estar centralizado en algún lugar y puede ser utilizado por el atacante a atacar (suponiendo que más bitcoin = más poder de voto). La solución a esto probablemente sea aplicar una función de ralentización (como la función raíz) para limitar su poder de voto. Pero luego, el atacante puede usar muchas billeteras de pequeño valor para socavar la gran billetera centralizada. (Todo en táctica de moderación, demasiado o muy poco no es bueno) Por lo tanto, también deberíamos reducir el poder de voto de aquellos que tienen muy poco bitcoin en su nodo: vea la imagen.

Entonces, ¿qué sucede con el nodo que no tiene un bitcoin? De todos modos, será inútil porque se extraerán de la red. Diría que no les asigne ancho de banda ni poder de voto, ya que de todos modos no están usando bitcoin y solo están desperdiciando recursos de la red. tal vez dejar que sean una referencia de baja prioridad, solo para que sean un poco útiles.

Lo mismo ocurre con los mineros. debemos asignar una función similar a la de la imagen. No queremos que los grandes mineros centralicen la red y al final tengan demasiado poder para arruinar la red. Dado que la comunidad bitcoin es por la gente y para la gente; Ese es el punto de todo el asunto de la descentralización, ¿no es así? Para que no seamos intimidados por el gran poder que quiere centralizarlo todo. Definitivamente deberíamos limitar el gran poder, así como a las personas inútiles que no usan bitcoin y se extraen de la red y ralentizan a la comunidad real en su conjunto.

Vea la imagen a continuación:

¿Esto también puede ayudar a lidiar con el ataque DDOS?

El mecanismo de punto de control de bloque se ha descrito como una forma poderosa para que los desarrolladores de blockchain se protejan contra la re-minería de toda la cadena. ¿Qué bloques llegan a ser puntos de control?

Tras la revisión del código real, el mecanismo de puntos de control de bloques no ha estado en uso activo recientemente. El último bloque marcado en la versión 0.14 de Bitcoin es 295000, que se extrajo el 9 de abril de 2014. Sin embargo, un número total de transacciones desde el bloque Génesis y la marca de tiempo de ese se han marcado hasta el bloque 446482 extraído el 3 de enero. 2017.

En comparación, los puntos de control de Litecoin 0.13.2.1 bloquean 721000 que se extrajo el 30 de enero de 2015 y luego la transacción 5502192, extrajo el 31 de enero de 2015. Supongo que no han sido tan diligentes y aún se están poniendo al día con Bitcoin en este sentido.