Bitcoin vulnerabilidad de seguridad: ataque de distorsión temporal
Recientemente, el desarrollador de Bitcoin Antoine Poinsot propuso una propuesta de bifurcación suave llamada "Limpieza del Gran Consenso". Esta propuesta tiene como objetivo corregir varios fallos y debilidades que han existido durante mucho tiempo en el protocolo de Bitcoin, incluidos los problemas de transacciones duplicadas que discutimos recientemente, así como un fallo más grave que este artículo se centrará en explorar: el "ataque de distorsión temporal".
Mecanismo de protección del timestamp del bloque de Bitcoin
Antes de discutir los ataques de distorsión temporal, necesitamos entender las reglas actuales de protección contra la manipulación del tiempo:
Regla de tiempo medio pasado (MPT): La marca de tiempo del bloque debe ser posterior al tiempo medio de los 11 bloques anteriores.
Reglas de tiempo de bloque futuro: La marca de tiempo del bloque no debe exceder las 2 horas por encima de la mediana de tiempo de los nodos pares. La diferencia máxima permitida entre el tiempo del nodo y el reloj del sistema local es de 90 minutos.
Las reglas de MPT evitan que las marcas de tiempo de los bloques se alejen demasiado del pasado, mientras que las reglas de bloques futuros limitan las marcas de tiempo para que no ingresen en exceso al futuro. Es importante señalar que no se puede implementar un mecanismo similar a las reglas de bloques futuros para bloquear las marcas de tiempo del pasado, ya que esto podría afectar la sincronización inicial de la cadena de bloques. Los ataques de distorsión temporal precisamente aprovechan la posibilidad de falsificar marcas de tiempo antiguas.
El error "uno menos" de Satoshi Nakamoto
El período de ajuste de dificultad de Bitcoin incluye 2016 bloques, calculado en un tiempo objetivo de 10 minutos por bloque, lo que equivale a aproximadamente dos semanas. Al calcular el ajuste de dificultad de minería, el protocolo calcula la diferencia de marcas de tiempo entre el primer y el último bloque en la ventana de 2016 bloques relacionados. Esta ventana de 2016 bloques en realidad incluye 2015 intervalos de bloques (es decir, 2016 menos 1). Por lo tanto, el tiempo objetivo correcto debería ser 60 segundos × 10 minutos × 2015 intervalos = 1,209,000 segundos. Sin embargo, el protocolo de Bitcoin utiliza el número 2016 para calcular el objetivo: 60 segundos × 10 minutos × 2016 = 1,209,600 segundos. Este es un típico error de uno, lo que podría ser que Satoshi Nakamoto confundió el concepto de bloque con el de intervalo de bloques.
Este error hace que el tiempo objetivo sea un 0.05% más largo de lo que debería. De hecho, el intervalo de tiempo objetivo de Bitcoin no es de 10 minutos, sino de 10 minutos y 0.3 segundos. Aunque este fallo parece insignificante, desde el lanzamiento de Bitcoin, el intervalo medio entre bloques ha sido de 9 minutos y 36 segundos, claramente menos de 10 minutos. Esto se debe principalmente a que desde 2009, la potencia de cálculo promedio ha ido en aumento. Esto también explica por qué el reciente evento de reducción a la mitad ocurrió en abril de 2024 y no en enero de 2025. En realidad, hemos avanzado en el cronograma. A largo plazo, cuando los precios y la potencia de cálculo tiendan a estabilizarse, este error de 0.3 segundos podría ayudarnos a volver al cronograma original.
Ataque de distorsión temporal
El ataque de distorsión temporal fue descubierto por primera vez alrededor de 2011, aprovechando un error de Satoshi Nakamoto en el cálculo de la dificultad. Supongamos que la minería está completamente centralizada, los mineros pueden establecer cualquier marca de tiempo dentro de los límites permitidos por el protocolo. El atacante establecería las marcas de tiempo de la mayoría de los bloques a solo un segundo antes que el bloque anterior, avanzando así el tiempo de la cadena de bloques lo más lentamente posible, mientras cumple con las reglas de MTP. Para maximizar la desaceleración del avance temporal, los mineros pueden mantener la misma marca de tiempo durante seis bloques consecutivos y luego aumentar el tiempo en un segundo en el séptimo bloque, repitiendo este ciclo.
Este ataque puede hacer que el tiempo de la blockchain se retrase cada vez más con respecto al tiempo real, mientras que la dificultad seguirá aumentando, haciendo que la minería se vuelva cada vez más difícil. Sin embargo, para mejorar el efecto del ataque, en el último bloque de cada ciclo de ajuste de dificultad, los mineros establecerán la marca de tiempo en el tiempo del mundo real. Luego, la marca de tiempo del primer bloque del nuevo ciclo de ajuste de dificultad se establecerá de nuevo en el pasado, adelantándose solo un segundo al penúltimo bloque del ciclo anterior. Esta operación sigue cumpliendo con las reglas de MTP, ya que una anomalía individual no afectará la mediana de 11 bloques.
Después de implementar este ataque, la dificultad del primer ciclo no se verá afectada. Pero a partir del segundo ciclo de ajuste, la dificultad comenzará a reducirse. En este momento, los mineros podrán crear bloques a una velocidad extremadamente rápida, lo que podría resultar en la creación de una gran cantidad de Bitcoin en un corto período de tiempo, obteniendo así beneficios indebidos.
Viabilidad y desafíos del ataque
A pesar de que teóricamente este tipo de ataque es devastador, su implementación real enfrenta múltiples desafíos:
Es posible que se necesite controlar la mayor parte de la potencia de cálculo.
La existencia de mineros honestos aumentará la dificultad del ataque.
Las reglas de MTP y la marca de tiempo de los mineros honestos limitarán el grado de retroceso de las marcas de tiempo maliciosas.
Si un minero honesto genera el primer bloque de cualquier ventana de ajuste de dificultad, el ataque de ese ciclo fallará.
El proceso de ataque es visible para todos, lo que puede dar a la comunidad suficiente tiempo para lanzar una solución de bifurcación suave de emergencia.
Solución
Hay varias maneras posibles de reparar esta vulnerabilidad:
Cambiar el algoritmo de ajuste de dificultad, calcular el intervalo de tiempo entre bloques en diferentes ventanas de 2016 y solucionar completamente el error de diferencia. Pero esto puede requerir un hard fork.
Cancelar la regla MTP, exigiendo que el tiempo en cada bloque se mueva siempre hacia adelante. Pero esto podría llevar a que el tiempo se quede atascado en un futuro distante y causar problemas a los mineros que utilizan el reloj del sistema.
Una solución más sencilla es exigir que el tiempo del primer bloque del nuevo ciclo de dificultad no sea anterior a un número específico de minutos antes del último bloque del ciclo anterior. En la propuesta de limpieza de consenso de Poinsot, este tiempo se establece en 2 horas.
Esta limitación de 2 horas tiene las siguientes ventajas:
Minimizar el riesgo de bloques inválidos inesperados al máximo
Coincidir con las reglas de marca de tiempo de bloque futuro
En comparación con las reglas actuales, es un cambio más conservador.
Un ajuste del 0.6% es bastante pequeño
Aunque esto aún permite a los atacantes manipular la dificultad hacia abajo en aproximadamente un 0.6% por ciclo, esto solo será un cambio único y no acumulativo. En general, esta solución logra un buen equilibrio entre la protección de la seguridad de la red y el mantenimiento de la estabilidad del sistema.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
20 me gusta
Recompensa
20
7
Compartir
Comentar
0/400
ColdWalletGuardian
· hace20h
Una vez que se haya corregido este error, estaré tranquilo.
Ver originalesResponder0
BridgeNomad
· hace20h
he sido quemado por suficientes exploits de puentes para saber - este vector de ataque me está dando ptsd de juno bridge fr
Ver originalesResponder0
fren.eth
· hace20h
Nadie es un tonto, ¿quién no quiere aprovecharse?
Ver originalesResponder0
NotAFinancialAdvice
· hace20h
Después de corregir la vulnerabilidad, los mineros no pueden jugar.
Ver originalesResponder0
retroactive_airdrop
· hace20h
Arreglé un vacío.
Ver originalesResponder0
GmGmNoGn
· hace20h
Arreglando bugs otra vez, resolviendo uno y aparece otro.
Ver originalesResponder0
quiet_lurker
· hace20h
Según debería, el minero debería haber explotado la olla.
Análisis de la vulnerabilidad de ataque de distorsión temporal de Bitcoin: principios, impactos y soluciones de reparación
Bitcoin vulnerabilidad de seguridad: ataque de distorsión temporal
Recientemente, el desarrollador de Bitcoin Antoine Poinsot propuso una propuesta de bifurcación suave llamada "Limpieza del Gran Consenso". Esta propuesta tiene como objetivo corregir varios fallos y debilidades que han existido durante mucho tiempo en el protocolo de Bitcoin, incluidos los problemas de transacciones duplicadas que discutimos recientemente, así como un fallo más grave que este artículo se centrará en explorar: el "ataque de distorsión temporal".
Mecanismo de protección del timestamp del bloque de Bitcoin
Antes de discutir los ataques de distorsión temporal, necesitamos entender las reglas actuales de protección contra la manipulación del tiempo:
Regla de tiempo medio pasado (MPT): La marca de tiempo del bloque debe ser posterior al tiempo medio de los 11 bloques anteriores.
Reglas de tiempo de bloque futuro: La marca de tiempo del bloque no debe exceder las 2 horas por encima de la mediana de tiempo de los nodos pares. La diferencia máxima permitida entre el tiempo del nodo y el reloj del sistema local es de 90 minutos.
Las reglas de MPT evitan que las marcas de tiempo de los bloques se alejen demasiado del pasado, mientras que las reglas de bloques futuros limitan las marcas de tiempo para que no ingresen en exceso al futuro. Es importante señalar que no se puede implementar un mecanismo similar a las reglas de bloques futuros para bloquear las marcas de tiempo del pasado, ya que esto podría afectar la sincronización inicial de la cadena de bloques. Los ataques de distorsión temporal precisamente aprovechan la posibilidad de falsificar marcas de tiempo antiguas.
El error "uno menos" de Satoshi Nakamoto
El período de ajuste de dificultad de Bitcoin incluye 2016 bloques, calculado en un tiempo objetivo de 10 minutos por bloque, lo que equivale a aproximadamente dos semanas. Al calcular el ajuste de dificultad de minería, el protocolo calcula la diferencia de marcas de tiempo entre el primer y el último bloque en la ventana de 2016 bloques relacionados. Esta ventana de 2016 bloques en realidad incluye 2015 intervalos de bloques (es decir, 2016 menos 1). Por lo tanto, el tiempo objetivo correcto debería ser 60 segundos × 10 minutos × 2015 intervalos = 1,209,000 segundos. Sin embargo, el protocolo de Bitcoin utiliza el número 2016 para calcular el objetivo: 60 segundos × 10 minutos × 2016 = 1,209,600 segundos. Este es un típico error de uno, lo que podría ser que Satoshi Nakamoto confundió el concepto de bloque con el de intervalo de bloques.
Este error hace que el tiempo objetivo sea un 0.05% más largo de lo que debería. De hecho, el intervalo de tiempo objetivo de Bitcoin no es de 10 minutos, sino de 10 minutos y 0.3 segundos. Aunque este fallo parece insignificante, desde el lanzamiento de Bitcoin, el intervalo medio entre bloques ha sido de 9 minutos y 36 segundos, claramente menos de 10 minutos. Esto se debe principalmente a que desde 2009, la potencia de cálculo promedio ha ido en aumento. Esto también explica por qué el reciente evento de reducción a la mitad ocurrió en abril de 2024 y no en enero de 2025. En realidad, hemos avanzado en el cronograma. A largo plazo, cuando los precios y la potencia de cálculo tiendan a estabilizarse, este error de 0.3 segundos podría ayudarnos a volver al cronograma original.
Ataque de distorsión temporal
El ataque de distorsión temporal fue descubierto por primera vez alrededor de 2011, aprovechando un error de Satoshi Nakamoto en el cálculo de la dificultad. Supongamos que la minería está completamente centralizada, los mineros pueden establecer cualquier marca de tiempo dentro de los límites permitidos por el protocolo. El atacante establecería las marcas de tiempo de la mayoría de los bloques a solo un segundo antes que el bloque anterior, avanzando así el tiempo de la cadena de bloques lo más lentamente posible, mientras cumple con las reglas de MTP. Para maximizar la desaceleración del avance temporal, los mineros pueden mantener la misma marca de tiempo durante seis bloques consecutivos y luego aumentar el tiempo en un segundo en el séptimo bloque, repitiendo este ciclo.
Este ataque puede hacer que el tiempo de la blockchain se retrase cada vez más con respecto al tiempo real, mientras que la dificultad seguirá aumentando, haciendo que la minería se vuelva cada vez más difícil. Sin embargo, para mejorar el efecto del ataque, en el último bloque de cada ciclo de ajuste de dificultad, los mineros establecerán la marca de tiempo en el tiempo del mundo real. Luego, la marca de tiempo del primer bloque del nuevo ciclo de ajuste de dificultad se establecerá de nuevo en el pasado, adelantándose solo un segundo al penúltimo bloque del ciclo anterior. Esta operación sigue cumpliendo con las reglas de MTP, ya que una anomalía individual no afectará la mediana de 11 bloques.
Después de implementar este ataque, la dificultad del primer ciclo no se verá afectada. Pero a partir del segundo ciclo de ajuste, la dificultad comenzará a reducirse. En este momento, los mineros podrán crear bloques a una velocidad extremadamente rápida, lo que podría resultar en la creación de una gran cantidad de Bitcoin en un corto período de tiempo, obteniendo así beneficios indebidos.
Viabilidad y desafíos del ataque
A pesar de que teóricamente este tipo de ataque es devastador, su implementación real enfrenta múltiples desafíos:
Solución
Hay varias maneras posibles de reparar esta vulnerabilidad:
Cambiar el algoritmo de ajuste de dificultad, calcular el intervalo de tiempo entre bloques en diferentes ventanas de 2016 y solucionar completamente el error de diferencia. Pero esto puede requerir un hard fork.
Cancelar la regla MTP, exigiendo que el tiempo en cada bloque se mueva siempre hacia adelante. Pero esto podría llevar a que el tiempo se quede atascado en un futuro distante y causar problemas a los mineros que utilizan el reloj del sistema.
Una solución más sencilla es exigir que el tiempo del primer bloque del nuevo ciclo de dificultad no sea anterior a un número específico de minutos antes del último bloque del ciclo anterior. En la propuesta de limpieza de consenso de Poinsot, este tiempo se establece en 2 horas.
Esta limitación de 2 horas tiene las siguientes ventajas:
Aunque esto aún permite a los atacantes manipular la dificultad hacia abajo en aproximadamente un 0.6% por ciclo, esto solo será un cambio único y no acumulativo. En general, esta solución logra un buen equilibrio entre la protección de la seguridad de la red y el mantenimiento de la estabilidad del sistema.