Hechos clave:
-
Los desarrolladores buscan superar el ātrastorno de estrĆ©s postraumĆ”ticoā causado por la activaciĆ³n
-
Las propuestas aumentan el tiempo de espera para activar el protocolo de mejora.
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.