¿Se debe usar la altura del bloque o MTP o una combinación de ambos en un mecanismo de activación de bifurcación suave?

¿Se debe usar la altura de bloque o MTP ( tiempo pasado medio definido en BIP 113 ) o una combinación de ambos en un mecanismo de activación como BIP 8 o BIP 9 para definir los tiempos de las transiciones de estado ?

¿Cuáles son las ventajas y desventajas de ambos y cómo se comparan?

Respuestas (2)

¿Debería usarse la altura de bloque o MTP (tiempo medio pasado [...]) o una combinación de ambos en un mecanismo de activación como BIP 8 o BIP 9 para definir los tiempos de las transiciones de estado? ¿Cuáles son las ventajas y desventajas de ambos y cómo se comparan?

La principal ventaja de MTP es que generalmente corresponde aproximadamente al tiempo de pared, por lo que es fácil comunicar lo que significa un número para los humanos. Por ejemplo, BIP141 dice: "la hora de inicio de BIP9 será la medianoche del 15 de noviembre de 2016 UTC [...] y el tiempo de espera de BIP9 será la medianoche del 15 de noviembre de 2017 UTC". Cuando ambos valores de MTP se alcanzaron en la red real, estaban dentro de las tres horas del UTC real.

La principal desventaja de MTP es que puede ser manipulado por mineros. MTP es la mediana del valor registrado en el campo nTime del encabezado del bloque actual y los 10 bloques anteriores. Los mineros pueden establecer sus valores de nTime en cualquier valor mayor que el MTP actual y menos de dos horas en el futuro. Esto hace posible que la mayoría de los mineros que trabajan durante un período de tiempo prolongado mantengan el MTP en un valor anterior (digamos hace 3 meses) y luego, en el espacio de un solo bloque, pasen a un tiempo mucho más posterior (digamos 1 mes). atrás). Esto puede permitirles saltar períodos de señalización obligatorios basados ​​en MTP, como se especifica en BIP148.

La principal ventaja de las alturas de los bloques es que no hay forma de saltarse un umbral basado en la altura, por lo que tienen sentido para las activaciones del día de la bandera, los requisitos de señalización obligatorios y otras transiciones que queremos asegurarnos de que sucedan (como de BIP9 LOCKED_IN a ACTIVE, lo que sucede utilizando un umbral basado en la altura relativa de 2.016 bloques).

La principal desventaja de las alturas de los bloques es que no son particularmente consistentes. En un año promedio, esperamos que haya 52 596 bloques, pero no sería extraordinario que haya 58 440 bloques, lo que reduce una implementación prevista de 12 meses a 10,8 meses.

No hay nada de malo en mezclar tiempos y alturas de MTP, y puede haber ventajas significativas si puede aprovechar ambas fortalezas al mismo tiempo sin perder demasiado por sus debilidades.

¿ La manipulación por parte de los mineros y el salto sobre el período de señalización basado en MTP mencionado en el segundo párrafo son un riesgo mayor para las bifurcaciones blandas en las que está involucrado UASF? ¿Cuáles son otros riesgos relacionados con el uso de marcas de tiempo en la activación de bifurcaciones blandas considerando las cosas mencionadas en bitcoin.stackexchange.com/a/99333 ?

El uso de alturas de bloque para los parámetros de inicio y tiempo de espera tiene la ventaja de brindar a los mineros un número conocido de períodos de señalización. La pérdida de hashpower no reduce la cantidad de períodos de reorientación disponibles para la activación. Especialmente para un mecanismo de activación en un horizonte de tiempo más corto (por ejemplo, la propuesta de prueba rápida ), puede ser importante garantizar que los mineros tengan el número máximo de períodos de señalización. Podría decirse que las alturas de los bloques también son más fáciles de comunicar y de razonar, ya que los desarrolladores de blockchain están acostumbrados a trabajar con ellas.

El uso de MTP (median time past) tiene la ventaja de poder programar una activación a una hora específica del día para evitar que la activación ocurra en medio de la noche en alguna región del mundo. Las preocupaciones sobre las disminuciones o aumentos de hashrate que afectan la cantidad de períodos de señalización se pueden mitigar seleccionando MTP de período de señalización medio. La corta duración de propuestas como Speedy Trial son menos sensibles a las desviaciones de la tasa de hash que cambian la cantidad de períodos (se requeriría una gran disminución de la tasa de hash para disminuir la cantidad de períodos de señalización).

Una preocupación con MTP es que una coalición de mineros podría reducir sus bloques minados en nTime a MTP + 1 para evitar alcanzar una hora de inicio de MTP en el tiempo real esperado. Esta preocupación parece menor, ya que podría afectar los ajustes de dificultad y requeriría una amplia participación de los mineros para limitar el MTP.

También está sujeto a debate si es preferible usar la altura de bloque de manera consistente o usar una combinación de alturas de bloque y MTP para dificultar la implementación y liberación de un mecanismo de activación alternativo (compatible o incompatible) (por ejemplo, una liberación de UASF) o para evitando un cuero cabelludo con fines de marketing .

AJ Towns explica una desventaja con el uso de MTP para el punto de miniactivación aquí . Si el tiempo de activación se acerca a una dificultad, la activación del bloque de reorientación podría ocurrir al día siguiente o en dos semanas. Esto presenta algunos desafíos de comunicación.

Además:

La altura a la que haces la transición de LOCKED_IN a ACTIVE debe determinarse completamente tan pronto como hagas la transición de STARTED a LOCKED_IN. De esa manera, todo el período LOCKED_IN debe reorganizarse si desea robar fondos protegidos tanto por nLocktime como por las nuevas reglas.

En resumen, parece haber consenso en que las alturas de los bloques deben usarse exclusivamente en los mecanismos de activación de futuras bifurcaciones blandas, pero no está tan claro si hay consenso en usarlos exclusivamente para el mecanismo de activación Taproot propuesto, Speedy Trial.

Para obtener más detalles sobre el ataque de distorsión temporal en MTP, consulte esto de Mark Friedenbach y esto de Andrew Chow.

Esta respuesta se tomó de los comentarios en GitHub y la lista de correo de Andrew Chow, AJ Towns, Jeremy Rubin, Sjors Provoost, Antoine Riard y David Harding.