¿Se utilizará la rama bifurcada de la cadena de bloques de un atacante en la confirmación de bitcoin?

Por lo que entiendo, las transacciones se aglomeran en un bloque, la prueba de trabajo se realiza calculando un valor hash para el bloque y luego se agrega a la cadena de bloques. Cuando se agrega un bloque a la cadena de bloques, la transacción incluida en el bloque se considera confirmada.

¿Cómo se decide el nodo completo desde el que se consulta la cadena de bloques? ¿O con cuántas cadenas de bloques de nodos completos se verifica una transacción?

Supongamos que un atacante tiene una cadena bifurcada, y no asumamos nada sobre el rechazo de otros nodos completos o la confirmación de esta bifurcación, ¿se puede verificar mi transacción con esta cadena bifurcada del atacante y no con otras cadenas de bloques válidas mantenidas por nodos completos honestos?

Supongamos que logré 6 confirmaciones, pero todos estos bloques son la bifurcación de un atacante. ¿Es esto un problema?

Creo que está preguntando sobre la situación en la que usted, como un nodo no completo (es decir, una billetera SPV en un teléfono, por ejemplo), está conectado solo a los nodos ejecutados por el atacante. Y luego te engañan haciéndote creer la cadena del atacante.

Respuestas (3)

Su escenario no está completamente claro, porque no nos dice si el atacante está produciendo bloques válidos o bloques no válidos. Tampoco ha definido si su propia billetera es un nodo completo o un cliente ligero.

Primero hablemos sobre cómo se transmiten los bloques a través de la red:
cuando se descubre un nuevo bloque, un nodo anunciará a través de un invmensaje (de inventario) que tiene este nuevo bloque. Otros nodos completos enviarán un getdatamensaje solicitando el bloque completo. Después de recibir y validar los datos, enviarán un invmensaje a sus pares para anunciarles el nuevo bloque.
Los nodos SPV no solicitan el bloqueo completo. Solo obtendrán el encabezado del bloque, y si hay transacciones de interés, solicitarán específicamente pruebas para enviarlas a través de un merkleblockmensaje. Los nodos SPV no pueden verificar completamente la validez de los nuevos bloques porque no almacenan la cadena de bloques.

Ahora hay tres escenarios posibles diferentes y dos tipos de billeteras a considerar:

El atacante está produciendo bloques no válidos
Se puede engañar a una billetera SPV porque no puede verificar la validez de un bloque. Todavía verifican que los encabezados de los bloques estén bien formados. Algunas billeteras SPV requieren múltiples pares para informarles sobre el mismo bloque. Por lo tanto, este ataque puede requerir adicionalmente un ataque Sybil o el control de la conexión a Internet de la billetera SPV.
Los nodos completos no se ven afectados porque rechazarán los bloques no válidos.

El atacante está produciendo bloques válidos a baja velocidad
. Una billetera SPV se reorganizará en una cadena más larga cuando se entere de ello por parte de un compañero diferente. Entonces, nuevamente, la billetera SPV debe estar aislada de otra información para que esto funcione. Como la información es válida, este ataque también puede funcionar contra nodos completos. El atacado puede notar la tasa de actualización sospechosamente lenta.

El atacante está produciendo bloques válidos con el 51 % de la potencia minera
. El atacante es más rápido que el resto de la red. Al elegir construir solo sobre sus propios bloques, puede extraer el 100% de los bloques y aún así superar a la red restante. Los bloques son válidos y por lo tanto aceptados por todos los nodos (hasta algún tipo de intervención). El atacante puede censurar las transacciones e incluso revertir una pequeña cantidad de bloques comenzando desde un bloque anterior pero eventualmente superando la punta natural de la cadena de bloques. Esto se denomina ataque mayoritario y rompe la suposición axiomática de seguridad de Bitcoin de que más de la mitad del poder minero es honesto.

¿Qué tan seguras son seis confirmaciones en la bifurcación de un atacante?
Si estás atrapado en un ataque de Sybil, esto te engañará. En todos los demás casos, no se dejará engañar, o toda la red es el objetivo.

Una vez que envía una transacción, la transmite a la red. Todos los nodos completos reciben eso y verificarán la transacción, por lo tanto, los nodos completos ignoran los bloques falsos cuando los envían los mineros y esperan el bloque correcto en el futuro y suponiendo que más del 50% de los mineros son honestos, ese bloque falso quedará huérfano.
Sin embargo, los clientes de SPV solo verifican la cadena más larga y, en ese caso, serán engañados por el bloque incorrecto.
El ataque que describiste es un ataque del 51 % en el que el atacante tiene el 50 % y más de todo el poder de hashing y, por lo tanto, puede crear bloques falsos uno encima del otro, lo que puede resultar en una situación realmente devastadora y definitivamente es un problema.

"suponiendo que más del 50% de los mineros sean honestos, ese bloque falso quedará huérfano". No necesitan asumir que más del 50% es honesto. Incluso si solo un minero es honesto, la cadena válida continuará. Los bloques inválidos simplemente se ignoran por completo, por lo que la cadena no crecerá en absoluto. Esto es cuando se habla de bloques inválidos (firmas incorrectas, recompensa de bloque demasiado alta, etc.). Tenga en cuenta que los gastos dobles NO son transacciones no válidas. Ambas transacciones SON válidas, pero solo una de ellas termina en lo que será la cadena de bloques final.
Sí, es importante distinguir los gastos dobles y las transacciones no válidas y creo que la pregunta no lo dejó claro. "Incluso si solo un minero es honesto, la cadena válida continuará". pero la red no acepta la cadena válida ya que no tiene la prueba de trabajo válida. ¡Es como si mantuvieras una cadena de bloques válida por tu cuenta pero no te preocupas por ti! La cadena válida no es válida hasta que obtenga la prueba del trabajo realizado. También será un problema para los SPV, ya que solo siguen la cadena más larga que ha puesto trabajo en ella.

El Trxid válido perdido en el bloque huérfano se pone en cola en el siguiente bloque disponible con confirmación retrasada en el sistema.

La razón para mantener intervalos de diez minutos en cada bloque es reducir la posibilidad de que se realicen 6 transacciones consecutivas.

Las transacciones digitales con una tasa de bloqueo más rápida o un poder de hash más bajo tienen una mayor vulnerabilidad a tal evento.

"El Trxid válido perdido en el bloque huérfano se pone en cola en el siguiente bloque disponible con confirmación retrasada en el sistema". Eso no parece responder a la pregunta. OP pregunta sobre la situación en la que un cliente se desconecta de la red y solo ve bloqueos por parte del atacante. Pienso.
"La razón para mantener espacios de diez minutos en cada bloque es reducir la posibilidad de que se realicen 6 transacciones consecutivas". Eso no tiene sentido. Puede poner 100 transacciones consecutivas incluso en 1 bloque si lo desea. 10 minutos no tiene nada que ver con eso.
"La razón para mantener espacios de diez minutos en cada bloque es reducir la posibilidad de que se realicen 6 transacciones consecutivas". esto no tiene ningún sentido para mí. Esto no tiene nada que ver con bloques de 10 minutos. Esta respuesta no parece responder a las preguntas de OP.