La bifurcación BCash parece haber anticipado correctamente la necesidad de ajustar la dificultad a la baja en el caso de bloques muy lentos. Esto significa que es mucho menos probable que la cadena quede huérfana cuando no era tan rentable como la cadena BTC (el primer período fue muy poco rentable). Todo lo que necesita es un minero que continúe extrayendo para producir un ajuste a la baja con bastante rapidez. Sin embargo, ahora estamos en el punto en el que puede ser más rentable extraer BCH y esto puede quitarle capacidad de extracción a BTC: la rentabilidad oscilará entre ambas cadenas.
¿Por qué la cadena BTC no tiene ajustes a la baja más rápidos? Supongo que hay alguna razón de seguridad importante para esto. Ciertamente salvó al BCH al principio tan superficialmente que parece una buena idea. Si BTC pierde mucho poder de minería y tiene ajustes lentos, podría tener períodos realmente largos de tiempos de confirmación lentos en la cadena heredada.
Espero que este problema se vuelva aún más importante con la bifurcación 2x cuando BTC (presumiblemente) pierda mucho más poder de hash. Quizás no haya una solución fácil porque requeriría una bifurcación dura en sí misma, anulando el propósito de no bifurcar la cadena heredada.
Así que para resumir:
¿Por qué el ajuste a la baja es tan lento en la cadena heredada? Debe haber algún beneficio real en esto.
¿Se encontrará un equilibrio en la minería, asumiendo mineros que buscan ganancias a corto plazo? ¿Cómo se llegará a ese equilibrio?
Peter Todd tiene una respuesta detallada a esta pregunta aquí:
El protocolo de Bitcoin limita la tasa a la que la dificultad puede disminuir a no menos de 1/4 de la dificultad del período anterior por período de ajuste. Específicamente, en el cálculo de la dificultad, la variable que contiene el tiempo real que se tardó en generar los bloques de 2016 tiene un tope de 4 veces el tiempo esperado.
// Limit adjustment step
int64_t nActualTimespan = pindexLast->GetBlockTime() - nFirstBlockTime;
if (nActualTimespan > params.nPowTargetTimespan*4)
nActualTimespan = params.nPowTargetTimespan*4;
Entonces, ¿por qué Satoshi hizo esto? ¿Qué ataque previene este limitador de velocidad?
Suponga que quiero engañarlo para que acepte una cadena que he extraído con menos trabajo que la cadena válida con más trabajo existente. Si puedo atacarte con éxito, puedo evitar que aprendas sobre la cadena de mayor trabajo.
Supongamos que inicio el ataque sybil cuando sabe de la existencia del bloque n=(k*2016 - 1), que resulta ser un bloque antes del final del período de ajuste de dificultad y tiene una marca de tiempo t.
Ahora extraigo el bloque n+1 con la marca de tiempo más grande que aceptará (su reloj local más 2 horas). Sin el limitador de velocidad, la cantidad que disminuiría la dificultad está limitada solo por la diferencia entre el tiempo t y ahora; eso puede ser muy grande si su nodo ha estado apagado por un tiempo, está en sincronización inicial o logro obtener que reinicie su estado de cadena (por ejemplo, mediante ingeniería social o con un exploit de corrupción de estado de cadena). Por ejemplo, si logro que retrocedas un año, la dificultad se reduciría a 1/26 del último bloque que conoces.
Con la reducción de la dificultad, puedo minar bloques de manera bastante económica para hacerle pensar que la transacción que está aceptando tiene una cantidad significativa de confirmaciones.
Al limitar la tasa a la que puede disminuir la dificultad, hacemos que este ataque sea significativamente más costoso: mi costo por bloque ahora es solo 1/4 de lo que debería ser, un aumento significativo en comparación con la situación sin el límite de tasa de caída.
Por supuesto, todos los sistemas de consenso tienen una suposición de sincronía de red de algún tipo: si los participantes no pueden comunicarse de manera suficientemente oportuna, es imposible llegar a un consenso; el caso de latencia infinita es un ejemplo obvio. Pero incluso si el sistema no funciona correctamente, aún queremos limitar lo que puede hacer un atacante: en combinación con PoW, el límite de caída de dificultad garantiza que incluso si la latencia es infinita, los ataques contra los participantes siguen siendo costosos, lo que convierte a un potencial desastroso ataque de doble gasto en un ataque DoS mucho menos dañino.
Finalmente, tenga en cuenta la importancia de PoW aquí: PoW garantiza que este ataque será costoso, en virtud del hecho de que el atacante no tiene forma de evitar la necesidad de gastar fondos para destruir energía, o en el caso de poder de hash robado, dar aprovechar la oportunidad de minar bloques extendiendo la cadena de mayor trabajo.
Mientras tanto, en un sistema PoS, este ataque se puede realizar de forma gratuita: incluso en un sistema PoS de estilo "slasher", ya que hemos atacado al objetivo con Sybil, podemos evitar que el mecanismo slasher funcione. La prueba de nuestro fraude nunca llegará al mundo exterior y, por lo tanto, no tiene impacto en el valor de nuestras monedas apostadas.