Proponen prueba rápida sobre activación de Taproot en Bitcoin

Una nueva propuesta plantea una prueba rápida sobre la implementación y activación de Taproot, solución de escalabilidad de Bitcoin.

En la lista de correos de desarrolladores de Bitcoin, Russell O’Connor, quien trabaja para Blockstream, propuso el Speedy Trial para evaluar rápidamente si la red, formada por los nodos, mineros y clientes, quiere y puede activar Taproot.

El debate por el método de activación se ha extendido más de lo planeado, planteando, por un lado, la activación de Taproot por los usuarios y, por otro lado, delegar la activación a los mineros de Bitcoin. Este es el centro del argumento que concentra a desarrolladores, usuarios y mineros de Bitcoin

Taproot ya se encuentra disponible en la versión más reciente del cliente Bitcoin Core, pero la activación depende de cada nodo o usuario de la red. Hay que recordar que los mineros ya han manifestado su aprobación sobre Taproot, como reportó CriptoNoticias, una implementación que traerá mayor privacidad y capacidad (escalabilidad) a Bitcoin.

Pero eso no implica que al momento de activar Taproot, los mineros lo hagan en el período establecido; o viceversa, que los usuarios y nodos hagan lo propio.

Así, surge la duda en algunos sectores de la comunidad sobre si la activación de Taproot guardaría el potencial de ser contenciosa, tratándose de una de las actualizaciones más grandes de Bitcoin desde SegWit, en julio de 2017.

Las diferencias entre los métodos de activación de Taproot no son sutiles pues, según el método que se utilice y cómo la red se comporte ante su ejecución, tendrían lugar escenarios favorables o, al contrario, existiría el riesgo de que ocurra una bifurcación, reorganización de bloques, pérdida de bitcoins, descenso en el hash rate de la red y otros eventos.

Con el comando lockinontime=true (LOT=True), de la propuesta de mejora BIP 8, los nodos de Bitcoin Core establecerían una fecha para la activación definitiva de Taproot, donde dejarían de aceptar transacciones de clientes que no hayan activado Taproot, así como no agregarían bloques a la red creados por mineros que tampoco se hayan actualizado.

Con lockinontime=false (LOT=False), los mineros tendrán suficiente tiempo para sumarse a Taproot una vez sea activado por los usuarios, pero si la mayoría de mineros no actualiza antes de que pase 1 año, podrían entrar en conflicto con los nodos y clientes.

No obstante, una de las desventajas de LOT=True es que si los mineros no se unen, quedarían excluidos tajantemente de la red, lo que daría lugar a una bifurcación y otros escenarios confusos y problemáticos.

Veamos qué pasa si…

El Speedy Trial propone probar rápidamente si los mineros, clientes y nodos cumplirían su palabra en activar Taproot cuando llegue el momento acordado, pero en un lapso corto de 3 meses. Russell O’Connor propone “ver qué pasaría” si los mineros pueden señalizar su disposición a activar Taproot durante un flag day o “día de señalización” en una altura de bloque estipulada.

Si dentro de 3 meses, el 90% de los mineros señalizan que desean activar Taproot, la activación se bloqueará (lock-in) por defecto y comenzará a ser implementada por los usuarios luego de esperar 6 meses más.

Si dentro de 3 meses el 90% de los mineros no señalizan a favor de la activación, esta fallará y volverá al estado actual de discusión. En esta oportunidad, lo que está en discusión no es la propuesta de Taproot como tal, sino el método con el que se activará, demostrando la gran cantidad de variables a considerar en la mejora y desarrollo de Bitcoin.

O’Connor reconoce en el correo que la divergencia en las reglas de consenso se ha dado en el pasado y es una característica de Bitcoin como programa de uso libre y de código abierto.

Algunos usuarios de Bitcoin no comparten todas las reglas del consenso general de este protocolo, pero cuentan con funcionalidades específicas compatibles que no los limitan en su desempeño. Que los usuarios puedan crear y ejecutar diversas versiones del programa de Bitcoin es, hasta cierto punto, deseable, pues aporta robustez y capacidades al protocolo.

Pero el desarrollador argumenta que, a pesar de esto, la comunidad de usuarios, desarrolladores y mineros de Bitcoin no debe quedarse de brazos cruzados a la espera de que suceda lo mejor, ya que cada uno puede ejecutar el método que considere más apropiado en su criterio para la activación de Taproot.

La solución intermedia por el bien común en Bitcoin

O’Connor dispuso de un documento en Github para que los desarrolladores y colaboradores de Bitcoin señalaran si están de acuerdo con el Speedy Trial, con los comandos ACK (“sí, la reconozco”) o NACK (“no la reconozco”) que, más que una votación, se trata de una validación de la propuesta como opción.

La Speedy Trial está siendo revisada por los desarrolladores, quienes en su gran mayoría la aprueban conceptualmente como una solución intermedia al debate LOT=True versus LOT=False. La propuesta de Prueba Rápida ya fue agregada a GitHub como borrador. De aprobarse, podría ser agregada al código de Bitcoin en las próximas semanas a espera de su realización.

La única observación que realizan es la de medir el periodo de activación con una altura de bloque y no con una medida genérica de tiempo, considerado por desarrolladores como Jeremy Rubin y Mark Folkson como un método más preciso para que los mineros sepan cuándo señalizar su posición (flag day).