Taproot se activa dentro de las próximas 2 semanas. ¿Qué podría salir mal y qué se podría hacer para reducir la probabilidad de cualquiera de estos escenarios de casos negativos?

Según taproot.watch, Taproot se activa en aproximadamente 10 días (bloque 709632) al momento de escribir (4 de noviembre de 2021). ¿Qué podría salir mal con respecto al mal caso o al peor de los casos? ¿Hay algo que los mineros o usuarios puedan hacer en esta etapa tardía para reducir la probabilidad de que sucedan estas cosas o simplemente para protegerse en caso de que suceda una de estas cosas?

¿Qué malos escenarios han ocurrido en el pasado con activaciones de bifurcaciones blandas anteriores?

¿Qué debemos tener en cuenta en el momento de la activación (o en los bloques posteriores a la activación) para comprobar que la activación se ha realizado sin problemas?

Respuestas (1)

Escenarios que no plantean una preocupación

Escenario: un gasto Taproot válido o no válido lo convierte en un bloque minado antes de la activación (bloque 709632). Simplemente se trata como si cualquiera pudiera gastar, ya que nadie en la red aplica las reglas Taproot hasta el bloque 709632. Esto ya sucedió (ejecutado por 0xB10C).

Escenarios de casos malos (poco probable que ocurran)

Escenario: la mayoría de los mineros (aunque previamente señalaron que estaban listos meses antes) no actualizan a una versión de nodo completo que aplica las reglas de Taproot en el momento de la activación. Un gasto de Taproot no válido lo convierte en una activación posterior del bloque extraído y crea una gran reorganización cuando se reorganiza.

Monitor: puede que no esté claro qué grupos de minería de versión de nodo completo se están ejecutando. Pero si incluyen un gasto de Taproot válido en un bloque (sin gastos de Taproot no válidos) que extraen después de la activación, esto sugiere que están aplicando las reglas de Taproot correctamente.

Escenario: Los protocolos de la segunda capa encuentran problemas imprevistos debido a la actualización de Taproot y necesitan reparación. Laolu Osuntokun discutió recientemente un problema relacionado con Taproot con el protocolo de cliente ligero Neutrino observado en testnet en la lista de correo de bitcoin-dev.

Monitor: Realmente depende del problema con respecto a qué monitorear, pero es probable que cualquier problema se discuta en las listas de correo de bitcoin-dev y lightning-dev.

En el peor de los casos (muy poco probable que ocurra)

Se encontró un error en el código de implementación de Taproot y necesitamos una bifurcación dura para corregir el error o revertir el cambio de bifurcación suave.

¿Qué malos escenarios han ocurrido en el pasado con activaciones de bifurcaciones blandas anteriores?

Bitcoin Optech revisa el historial de activaciones de bifurcaciones blandas aquí . Ha habido una serie de activaciones de emergencia de cambios de consenso para abordar errores, aunque estos no fueron bifurcaciones blandas planificadas previamente como Taproot. Y, por supuesto, aunque la bifurcación suave de SegWit finalmente se activó sin problemas en 2017, los meses previos a esa activación fueron todo menos suaves (puede leer sobre los meses anteriores a la activación de SegWit en The Blocksize War de Jonathan Bier). La única activación de bifurcación suave planificada previamente que encontró problemas en el momento de la activación fue la bifurcación suave BIP 66 en 2015. Como afirma Optech:

El umbral del 75% se alcanzó en la altura del bloque 359.753. El 4 de julio de 2015, se alcanzó el umbral del 95 % en el bloque 363 725 y todos los nodos que ejecutan Bitcoin Core versión 0.10.0 o posterior (o una implementación compatible) comenzaron a aplicar las nuevas reglas. Sin embargo, a la altura del bloque 363 731, un minero no actualizado produjo un bloque que no contenía la versión de bloque correcta y, por lo tanto, no era válido según las nuevas reglas de activación de ISM. Otros mineros construyeron sobre este bloque inválido, produciendo finalmente una cadena con seis bloques inválidos. Esto significó que los nodos no actualizados y muchos clientes ligeros trataron las 96 transacciones en el primer bloque no válido como si tuvieran seis confirmaciones, aunque en ese momento no habían sido confirmadas ni una sola vez en un bloque válido. Eventualmente, los desarrolladores pudieron contactar a los operadores de las piscinas y hacer que reiniciaran manualmente su software para volver a la cadena válida. Un segundo evento de este tipo ocurrió al día siguiente, dando a las transacciones tres confirmaciones falsas. Felizmente, todas las transacciones regulares de las cadenas no válidas de seis y tres bloques se confirmaron más tarde en bloques válidos, lo que significa que ningún usuario regular perdió dinero.

Preguntas y respuestas interesantes. Estoy esperando a ver qué sucederá con los nodos que ejecutan 0.16.0-0.17.0 en este momento o al menos usan esa cadena UA para la versión.
@Prayank: ¿Por qué? ¿Qué crees que les puede pasar?
Motivo: reddit.com/r/Bitcoin/comments/lb6dpi/vulnerable_bitcoin_nodes/… Expectativas: tal vez algunos de ellos comiencen a usar versiones más nuevas