Actualización de Taproot: Los usuarios de Bitcoin se centran en el plan de activación (fecha aún por determinar)

Muchos de los interesados ​​más activos de Bitcoin prácticamente han definido el método de activación para Taproot, la mayor actualización del software de Bitcoin en años.

En una reunión pública en Internet Relay Chat (IRC) el martes, desarrolladores, mineros, profesionales de negocios y entusiastas de Bitcoin resolvieron los detalles de cómo empaquetar la actualización de Taproot en una actualización y cómo activarla una vez que se haya enviado el código.

Los más activos de los aproximadamente 200 participantes del chat (en su mayoría, aunque no todos, desarrolladores) parecían estar de acuerdo con la Propuesta de Mejora de Bitcoin (BIP) que se usaría para activar Taproot. Para preparar la BIP para su lanzamiento, también votaron por fusionar dos solicitudes de extracción (PR) en GitHub que describen las reglas de la lógica de activación de Taproot en el código fuente de Bitcoin cuando llegue el momento de impulsar la actualización.

Sigue leyendo: Cómo la actualización Taproot de Bitcoin mejorará la Tecnología en toda la pila de software de Bitcoin

ONE de estos, PR #1021, incluye una medida para permitir a los usuarios forzar la activación de la actualización si los mineros no la admiten, mientras quePR #1020 Solo "recomienda" esta activación forzada, pero no la habilita por defecto. Dado que la mayoría de los participantes apoyan BIP 8 sin activación forzada, como señaló en el chat Michael Folkson, líder de la reunión y desarrollador de Bitcoin CORE , en futuras conversaciones se determinará una fecha para el inicio de la activación y se debatirá en mayor profundidad hasta qué punto es necesario un "día de la bandera" para forzar la activación.

Por qué un día de la bandera de Taproot (probablemente) no es necesario

No es que los mineros que bloquean la actualización deberían ser un problema para Taproot, que tiene un 91% de soporte de mineros,según una encuesta dirigido por el vicepresidente de Poolin, Alejandro De La Torre.

La encuesta proporciona información crucial de los mineros para la organización descentralizada de Bitcoin, que no puede coordinar actualizaciones unilateralmente como lo hace un proveedor de software centralizado. Actualizaciones como Taproot requieren una coordinación minuciosa entre mineros, usuarios de nodo completo (aquellos que ejecutan el código abierto de Bitcoin) y otras partes interesadas para garantizar que no haya problemas (como la introducción de un error o la división de la red Bitcoin en dos versiones incompatibles).

Debido a que los mineros no han mostrado resistencia a Taproot, la mayoría de los participantes expresaron una preferencia por BIP8 (falso), y (falso) se refiere a la exclusión de un “día de bandera” para forzar la activación a través de nodos completos en caso de que la actualización falle por falta de activación de los mineros.

BIP8, tal como está concebido actualmente, otorgaría a los mineros de Bitcoin y a los operadores de nodos completos un año para adoptar la actualización, tras lo cual esta quedaría "fijada" con suficiente soporte. En una versión de esto, BIP8 (falso), la actualización simplemente falla sin suficiente soporte. En otra, BIP8 (verdadero), un "día de alerta" obligaría a los mineros a solicitar la actualización al vencimiento del plazo de activación si no lo hicieron con antelación.

Sigue leyendo: Todos los principales pools de minería ahora admiten Taproot, la mayor actualización de Bitcoin en años

Nota técnica: Existen varias maneras de actualizar Bitcoin. La más sencilla es mediante la activación de mineros, donde los grupos de minería se actualizan y comienzan a minar bloques bajo las nuevas reglas. De no ser así, los operadores de nodos pueden actualizar y rechazar los bloques de los mineros que no hayan mostrado su apoyo a la actualización. Esta bifurcación suave de activación por usuario (UASF)... casiy utilizado para activar SegWit, obligaría a los mineros reticentes a adoptar la nueva actualización.

“Es completamente anecdótico, pero no lo he visto.cualquier [Énfasis suyo] oposición a Taproot", dijo ONE en el chat, refiriéndose a si es necesario o no un día de bandera. "Creo que usar el mínimo común denominador de los parámetros de activación (falso) parece la opción más sensata para evitar divisiones intencionadas o accidentales de la cadena en caso de que los mineros no indiquen".

¿Qué es lo que está ocurriendo?

Otros, como el prolífico desarrollador de Bitcoin CORE, Luke Dashjr, no están convencidos de que la inclusión de un día de la bandera sea innecesaria. De hecho, es una cuestión de principios demostrar que son los operadores de nodos quienes deciden el software, no los mineros.

"No importa", dijo en el chat en referencia al soporte para mineros. "Los mineros no deciden los cambios de protocolo", continuó, insinuando que son los operadores de nodos quienes deciden qué software ejecutar. Además, defendió que BIP8 (falso) "deja que los mineros decidan" el destino de la actualización. Cuando llegue el momento, comentó más adelante en el chat, configurará su nodo para ejecutar la versión de BIP8 (verdadero) que rechaza los bloques que no son de Taproot de los mineros.

“BIP8 con [activación] obligatoria no es una demostración de fuerza innecesaria”, dijo hsjoberg, reiterando la creencia de Dashjr de que la elección del usuario de un UASF es un control y equilibrio necesarios ante la apatía de los mineros.

Sigue leyendo: UASF revisitado: ¿La revuelta de los usuarios de Bitcoin dejará un legado duradero?

Aun así, una demostración de fuerza podría introducir un riesgo innecesario y sentar un precedente no deseado para futuras deliberaciones sobre actualizaciones, especialmente cuando los mineros no han dado a los usuarios motivos para ser combativos, al igual que los argumentos a favor de BIP8 (falso).

“[BIP8 falso] es más seguro que [verdadero], por lo que vale la pena hacer [falso] primero dado que sabemos que el poder de hash ya es aproximadamente el 90 % pro-Taproot”, dijo Chris Belcher, desarrollador de Bitcoin CORE y CoinSwap.

Otros, como Ben Carman, desarrollador de Suredbits y Bitcoin CORE, señalaron que se podría configurar la actualización más adelante en la activación para incluir el día de la bandera en caso de que los mineros no la señalen, "haciendo que sea más seguro y fácil para los usuarios aplicar el UASF".

Al final de la reunión, los participantes acordaron fusionar las solicitudes de extracción en GitHub para una ruta de activación no forzada (PR #1020) y una ruta de activación forzada (PR #1021). Con ambas reglas en GitHub de Bitcoin Core, las reglas para una activación forzada solo podrían usarse si fuera necesario.

Más deliberación

El escenario de división de la cadena que willcl_ark describió es básicamente el fantasma que todos quieren evitar. El temor es que BIP8 (verdadero) requiera el 100% de la tasa de hash para indicar la actualización tras el vencimiento del plazo de activación de Taproot. Por lo tanto, si suficientes usuarios optaran por esta vía al mismo tiempo que otros usan BIP8 (falso) para la activación no forzada (que solo requiere el 95% de la tasa de hash), las dos versiones de código diferentes podrían crear dos historiales incompatibles en el libro de transacciones de Bitcoin.

Por eso, si es necesario implementar una señalización forzada, lo mejor es hacerlo a través del PR #1021 de AJ Townes, que “hace más segura la opción UASF, que es el escenario más ‘peligroso’”, escribió Carman en el chat.

Por ahora, parece que los involucrados en las discusiones están a favor de BIP8 (falso) con la adición de un UASF a través de PR #1021 si es necesario, pero se necesita más discusión para determinar el cronograma exacto del período de activación inicial (o cuánto tiempo tienen los usuarios para actualizar después de que la actualización se activa), así como qué fecha de activación establecer.

Estos “qué pasaría si” y “cuándo” se resolverán, entre otros asuntos, en una reunión el 16 de febrero.