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

By | March 9, 2021


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

En la serie 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 banda, la activación de Taproot por los usuarios y, por otro banda, 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 adecuado en la interpretación más fresco del cliente Bitcoin Core, pero la activación depende de cada nodo o agraciado de la red. Hay que rememorar que los mineros ya han manifestado su aprobación sobre Taproot, como reportó CriptoNoticias, una implementación que traerá longevo 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 al revés, 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 en presencia de su ejecución, tendrían ocasión escenarios favorables o, al contrario, existiría el peligro de que ocurra una derivació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 alivio BIP 8, los nodos de Bitcoin Core establecerían una vencimiento 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 siquiera 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 antiguamente 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 ocasión a una derivació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 convenido, pero en un espacio 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 categoría de pedrusco estipulada.

Si adentro 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 adentro de 3 meses el 90% de los mineros no señalizan a protección de la activación, esta fallará y volverá al estado coetáneo 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 alivio y mejora de Bitcoin.

El dilema no es la opción de escalabilidad, sino la forma de activarla en Bitcoin. Fuente: geralt / pixabay.com

O’Connor reconoce en el correo que la desemejanza en las reglas de consenso se ha cubo en el pasado y es una característica de Bitcoin como software de uso suelto y de código amplio.

Algunos usuarios de Bitcoin no comparten todas las reglas del consenso militar 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 software 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 dilación 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.

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 tráfico de una brío 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 opción intermedia al debate LOT=True contra LOT=False. La propuesta de Prueba Rápida ya fue agregada a GitHub como proyecto. De aprobarse, podría ser agregada al código de Bitcoin en las próximas semanas a dilación de su realización.

La única observación que realizan es la de contar el periodo de activación con una categoría de pedrusco 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).





Source link