Activación de Taproot en Bitcoin depende del debate de tres propuestas

Una mejora en la privacidad y la escalabilidad de Bitcoin, conocida como Taproot, que podría ser una de las más importantes actualizaciones de la red, aún se encuentra en una fase de debate en torno los procedimientos más adecuados para su implementación.

De acuerdo a un hilo publicado el 14 de julio en la cuenta de la comunidad de Bitcoin en Reddit, uno de los problemas a superar para proceder a la activación, tiene que ver con el “trastorno de estrés postraumático” (TEPT) causado por la bifurcación suave que incorporó SegWit.

Señala la publicación que el consenso que permitió implementar SegWit (Segregated Witness) o Testigo Segregado en la red de Bitcoin en 2017 siguió el procedimiento de bifurcación suave de la propuesta de mejora BIP9. Esta propuesta requería que el 95% de todos los mineros señalaran que actualizaron el software y que estaban listos para completar la bifurcación.

Sin embargo, se presentó un período de espera que rechazó automáticamente la propuesta de SegWit, al no alcanzar el consenso en una fecha determinada. Tal hecho generó controversias en ese momento, debido a que el alto grado de acuerdo requerido permitiría a un minero con gran poder de procesamiento dentro de la red detener la actualización.

Para evitar que esta situación se repita con Taproot, los desarrolladores debaten sobre tres técnicas de activación: la propuesta de mejora BIP8, Decreasing Threshold y Modern Softfork Activation (activación moderna de bifurcación suave).

Con la BIP8 el mecanismo descrito en la BIP9 cambia. La idea es que, si los nodos de la red se actualizan, los mineros no puedan bloquear la bifurcación. Por ello, ofrece un marco de tiempo de un año -medido en bloques- a fin de que los nodos hagan la actualización. Se agrega lo que se denomina “indicador lockinontimeout”, basado en la altura o número de bloques. Por tanto, una vez transcurrido el tiempo establecido, se mantiene vigente la opción de que la actualización sea o no obligatoria.

En la explicación que el desarrollador Anthony Towns escribe acerca de esta propuesta, señala algunas observaciones realizadas por otros desarrolladores, quienes cuestionan el tiempo establecido a través del lockinontimeout.

En su publicación, Towns también hace una comparación con el método llamado Decreasing Threshold, que es la segunda propuesta de actualización. De acuerdo a ella existiría un nuevo umbral de tiempo para la aprobación. Se exigiría el 95% de actualización en una primera fase, opcional. Este requerimiento decae luego hasta el 50% de aprobación, en un segundo lapso de tiempo que se brinda hasta que la activación se hace obligatoria.

Por su parte, la tercera técnica (activación moderna de bifurcación suave) se basa en un planteamiento del desarrollador Matt Corallo, quien propone un sistema híbrido entre BIP8 y BIP9.

En este caso la actualización sería rechazada si no se llega a consenso en el lapso de un año. Si esto ocurre, se plantea que después de otros seis meses de discusión, la comunidad podría decidir comenzar un procedimiento de dos años que activaría la actualización al vencimiento de la fecha pautada. La duración máxima de este procedimiento sería de 42 meses, o tres años y medio.

Se alarga el tiempo de espera para Taproot

En general, los desarrolladores de Bitcoin Core están de acuerdo en que la actualización será beneficiosa para Bitcoin, y hasta ahora, la propuesta ha sido bien recibida en el ecosistema. Pero aún falta tiempo para su activación, tomando en cuenta este nuevo debate que se abre en relación a la forma de realizar la bifurcación suave.

Entre tanto, se vienen realizando avances. El pasado mes de enero el colaborador de Bitcoin Core, Pieter Wuille, y principal responsable de Taproot, presentó en GitHub una solicitud de cambio de código, conocida como pull request o “solicitud de inclusión”, que actualmente está en progreso. Con ella se hizo la solicitud formal para añadir este código al código principal de Bitcoin.

Tal como se reportó en CriptoNoticias, Taproot fue propuesto originalmente en enero de 2018 por el desarrollador Gregory Maxwell. Este protocolo permite expandir las capacidades del protocolo de multifirma o de MAST (un protocolo que permite establecer distintas condiciones para que se puedan gastar las criptomonedas). Estos sistemas también han sido descritos como tipos de contratos inteligentes en Bitcoin.

El protocolo preserva la privacidad, al hacer que las transacciones estándares, que requieren que se genere una clave privada para posibilitar el gasto, y las transacciones más avanzadas (las de firma múltiple), sean indistinguibles. Con ello se busca mejorar la seguridad de la plataforma al evitar que se revelen algunos datos, entre ellos el tipo de cartera utilizada.