¿Andreas nos podrias hacer un resumen rapido acerca de que es Taproot?
Taproot es un paquete de cambios propuesto para el protocolo de Bitcoin y tambien es el nombre de uno de esos cambios, los otros dos cambios son Tapscript y firmas Schnorr.
Todos estos cambios han sido agrupados para conseguir el máximo efecto en términos de privacidad en una única propuesta llamada Taproot.
Está previsto que se introduzca en el protocolo de Bitcoin en algún momento del 2021.
¿qué hacen estas propuestas en realidad?
Estas propuestas hacen tres cosas principalmente:
1- Mejoran la escalabilidad del sistema Bitcoin.
2- Mejoran masivamente la privacidad del sistema.
3- Establecen algunos fundamentos estructurales para futuras mejoras y nuevos desarrollos que pueden ser construidos sobre ellas.
Cuando escucho taproot siempre se repite la frase "scriptless scripting" en el mismo tema...
¿están relacionados? ¿permite taproot eso y que es un script sin script?
Sí, están relacionados, este seria el resumen.
Todo comienza con las firmas schnoor, las firmas schnorr son un protocolo que es diferente del algoritmo de la curva elíptica (ECDSA) que es el que se utiliza actualmente en bitcoin.
La razón por la que Satoshi no utilizó firmas schnorr a pesar de que fueron inventadas en los años 70 es porque estaban patentadas hasta el año 2018. Ciertamente esto provoca que sea difícil para cualquier persona implementar las bibliotecas que funcionen con este sistema.
Cuando las mejoras vienen a Bitcoin o cualquier otra blockchain a menudo vienen en forma de un de un nuevo tipo de direcciones.
Este nuevo tipo de dirección podría ser diferente visualmente y como consecuencia se podría identificar el tipo de transacción con solo mirarla.
Uno de los grandes beneficios de esta tecnología es que las transacciones sean imposible de distinguir, todas parecen lo mismo.
Ahora bien, al principio eso no va a funcionar perfectamente bien porque es un nuevo estándar y sólo será otra forma mas para identificar ese tipo de transacciones.
Pero a medida que pasa el tiempo y que su implementación se vuelve más omnipresente en las diferentes partes del ecosistema como carteras, exchanges, etc se condensarán en este nuevo tipo de direcciones lo que facilitara hacer este tipo de movimientos en privado sin que nadie sepa exactamente lo que estás haciendo.
Por ejemplo, una cuenta de seguridad multifirma que es controlada por varias personas o por varios dispositivos diferentes, no sólo tiene un aspecto distinto sino que ademas ocupan mucho espacio en la blockchain y eso hace que sea más caro y que menos personas puedan procesar ese tipo de transacciones en la blockchain sin hacer subir el precio de las comisiones por transacción.
Se resuelve ese aspecto porque todos estos tipos diferentes de transacciones parecerán iguales y también ocuparan menos espacio al permitir combinar mutiples transacciones en una sola. Esto mejora la privacidad y escalabilidad al mismo tiempo, haciendo el sistema mas barato para todos al reducir el espacio necesario en la blockchain.
Así que ahora vamos a entrar mas en detalle sobre esto.
Las firmas schnorr al igual que las firmas digitales de curva elíptica (ECDSA), son básicamente una forma matemática de demostrar que se tiene control sobre una clave privada produciendo una firma digital, que es un número que se deriva de aplicar su clave privada junto con un mensaje, el mensaje a menudo suele ser una transacción.
Las firmas schnorr son interesantes porque tienen un par de propiedades muy útiles que las firmas digitales de curva elíptica no poseen.
Para decirlo de forma sencilla, una de las propiedades realmente interesantes es que puedes "agregarlas" de forma que la suma de un conjunto de firmas sea la misma que la firma de la suma de las claves privadas, lo que significa que en lugar de presentar cinco firmas para cinco claves privadas que pueden ser verificadas contra cinco claves públicas, puedes presentar una firma que es la suma de las cinco firmas que pueden ser verificadas contra las cinco claves públicas sumadas como una clave pública para demostrar que quien firmó esto estaba en control de la suma de las cinco claves privadas como una clave privada.
La ventaja de esto es que si se presenta una única firma contra una única clave pública que confirma la posesión de una única clave privada, no puedes decir que en realidad había cinco personas que la componen, y en eso obtienes dos efectos.
Uno tiene que ver con la escalabilidad, el hecho de que puedes producir y verificar una firma para cinco partes diferentes de una transacción o incluso potencialmente cinco transacciones diferentes en un bloque, esa es la capacidad de agregación.
La otra ventaja es que puedes ocultar scripts complejos como una sola firma en una sola clave pública, lo que provoca que la transacción parezca un pago simple.
Hagamos un ejemplo concreto.
Digamos que estás cerrando un canal de lightning, un canal de lightning es un multisig 2 de 2.
Si lo firmas como un multisig 2 de 2 todo el mundo puede verlo y sabe que es un canal lightning.
Pero si en lugar de eso mientras cierras el canal "agregas" esas dos firmas y lo presentas como una sola firma en una sola clave pública entonces nadie puede decir que esto es un canal de lightning ya que la firma se ve igual que un pago directo. Esto aumenta masivamente lo que se llama el conjunto de anonimato.
Hace que cualquier transacción parezca un pago simple, incluso si es un canal, un multi-sig, o si es un script complejo.
Como vimos con la implementación de segwit hace varios años, una vez que esto entre en vigor, si es que entra en vigor, pero presumiblemente lo hará, tendrías que mover las monedas a una dirección compatible con taproot para poder hacer uso de este tipo de transacciones. ¿Es esto correcto?
Si, en primer lugar taproot introduce un nuevo tipo de dirección que utiliza la capacidad de versionado de segwit así que lo que conocemos hoy como direcciones nativas de segwit son la versión 0 de segwit que se introdujo en 2017 y taproot será la versión 1 de segwit.
Las direcciones actuales comienzan con "bc1q" y las direcciones de segwit v1 empiezan con "bc1p".
Lo que eso significa es que veremos un formato de dirección ligeramente diferente y para obtener todos los beneficios tienes que empezar a usar taproot en tu cartera, lo que significa tu cartera tiene que implementar taproot.
Así que veremos una mezcolanza de carteras implementando esto con el tiempo, después de que sea implementado en el protocolo de Bitcoin.
Sí, al igual que los cambios anteriores esto es retro-compatible, no tienes porque usarlo si no quieres.
Una vez que esté disponible sera un formato válido y entonces podrás utilizarlo si quieres.
Si decides utilizar scripts y direcciones de tipo segwit v1 entonces podrás acceder a todas las diferentes funcionalidades.
Hasta ahora sólo he hablado de las firmas schnorr y de las capacidades de escalabilidad y privacidad de la agregación, hay un par mas de cambios que están ocurriendo aquí.
Otra gran parte de esto es la cuestión de los scripts.
Así que los scripts son básicamente como la versión de Bitcoin de los contratos inteligentes, puedes construir contratos inteligentes reales en capas superiores construidas sobre Bitcoin pero Bitcoin en sí mismo soporta algo que se parece y funciona mucho como contratos inteligentes simples en la forma de estos scripts.
¿verdad, Andreas?
Correcto, el script es un tipo de programa muy simple y en bitcoin los programas solo hacen una cosa, te dan una respuesta verdadera o falsa. Verdadero significa que se te permite gastar y falso que no se te permite, así que si en el script puedes producir una respuesta verdadera eso significa que cumples todas las condiciones y puedes gastarlo.
Bitcoin tiene un lenguaje de scripting que te permite especificar condiciones para gastar algo y la condición más obvia es mostrar una firma que pruebe que posees la clave privada y entonces puedes gastar esto. Este es un script bastante simple pero esa no es realmente la gran mejora de la escalabilidad.
La gran mejora de la escalabilidad viene de scripts más complejos, así, por ejemplo si tienes un script complejo que dice aquí hay 10 claves, si tres de estas claves firman, entonces puedes gastarlo, o si dos de estas claves firman y han pasado 90 días, entonces puedes gastarlo, o si esta clave firma mientras produce un hash de este otro mensaje y también han pasado 120 días, entonces puedes gastarlo. Son tres o cuatro condiciones diferentes y estas condiciones se especifican en un script.
Ahora si quieres gastar con el script tendrías que presentar todo el script y luego mostrar qué parte de él estás usando y proporcionar todos los requisitos previos por lo que podrías decir aquí está todo el script todas las condiciones que se requieren y también estoy usando la segunda cláusula y tengo dos claves y 90 días han transcurrido y por lo tanto puedo gastarlo, genial, la red de Bitcoin lo reconocerá y permitira el gasto.
El problema es que es una transacción muy larga y si estas usando muchas entradas se hace más y más larga. Lo que taproot mejora es que oculta todas estas diferentes condiciones en un árbol utilizando una tecnología llamada árboles merkle (merkle trees) que también se utiliza en la compresión de todas las transacciones en un bloque.
En lugar de proporcionar una lista de condiciones a través de un largo script, proporcionas un árbol y dices que este árbol especifica todas las las condiciones. Sólo voy a mostrarte el hash de la parte superior del árbol y cuando quieras gastarlo dices voy a usar la segunda cláusula en el árbol, aquí esta la prueba que demuestra que esa cláusula era parte del árbol pero no te estoy diciendo qué otras cláusulas existen, la primera, tercera, cuarta, quinta y sexta cláusula nunca las sabrás, ni siquiera te las muestro y por lo tanto la prueba que proporciono es muy muy corta.
Ese concepto fue introducido por primera vez en 2014. Fue llamado "merklized abstract syntax trees", hemos hablado de ello en el programa. Hablamos de ello ampliamente en 2016 y 2017 en el período previo a segwit y taproot finalmente lo hace una realidad.
Esto parece una especie de prueba de zero-knowledge en la que puedes demostrar que algo es correcto sin tener que revelar qué es lo que estás demostrando que es correcto.
¿Es eso lo mismo de alguna manera?
En cierta forma si, esencialmente estás protegiendo todas las partes del script que no estás utilizando para gastar y esa es la parte del merklized tree en Taproot, pero hay una aún mejor que es que en el ejemplo que di antes dices "aquí hay 10 claves, si tres de ellas firman entonces puedes gastar, si dos de ellas firman y tienes 90 días entonces puedes gastar, si uno de ellos firma y tienes tal hash y 120 días entonces puedes gastar, pero en casi todos estos tipos de scripts también está el caso en el que todos están de acuerdo.
Esto se llama el k de k, la opción unánime y eso es simplemente que las 10 claves están de acuerdo y en muchos de los protocolos que se construyen sobre bitcoin o en entornos de gasto corporativo u otro tipo de situaciones siempre es posible obtener un consentimiento unánime en lugar de los gastos individuales.
Usted podría ser capaz de realizar la gran mayoría de los gastos con la opción de consentimiento unánime, con taproot el consentimiento unánime se produce como una sola firma que se agrega a partir de todas las 10 claves, por ejemplo, en contra de una sola clave pública que se agrega en contra de todas las 10 claves públicas y que aparece a todo el mundo en la red como un pago simple y entonces usted ni siquiera sabe que había una secuencia de comandos de cinco cláusulas con sub-opciones y rutas alternativas de gasto detrás de esto.
Todo lo que ves es el root, el taproot y es por eso que se llama taproot.
Como esto llega a ser más centrado en la privacidad es si comparamos bitcoin a ach el mundo en el que estamos ahora es el mundo ethereum y el mundo bitcoin donde si acme quiere pagar a warner brothers, no sólo podemos ver el pago , tambien se ve todo el contrato y la negociación, el acuerdo y todo se revela.
Pero lo que permite taproot es hacer que cuando acme y warner brothers tienen un acuerdo solo veas el final del acuerdo que es "hey algo de dinero fue de acme a warner brothers"
De hecho puede que ni siquiera veas eso porque si acme y warner brothers están representados por algún tipo de canal de pago agregado como a través de un canal de lightning, verás una firma agregada que alguna parte anónima ha firmado esto, pero no ves lo que hay detrás, que en realidad son 10 pagos diferentes que se hacen. Obtienes todas estas capacidades de agregación y la agregación también significa privacidad por lo que es una de las grandes propiedades.
Ahora todo esto es inmensamente técnico, para la mayoría de los usuarios de bitcoin lo que esto significará es que su cartera será capaz de hacer una actualización al formato de direcciónes actual, es una actualización relativamente simple para las carteras que ya han implementado segwit el implementar segwit v1.
A diferencia de segwit v0 no es una gran actualización, el código ya está integrado en las bibliotecas de prueba, se está ejecutando en las redes de prueba y la red líquid y ya está incorporado en todas las bibliotecas a nivel de aplicación que construyen sobre libsecp y por lo tanto debería ser una actualización bastante fácil para las carteras.
Una vez que se actualiza, el efecto mas obvio para la mayoría de los usuarios es simplemente que sus transacciones van a ser más baratas... eso es todo, pero lo que está sucediendo para los usuarios más sofisticados es que todos sus scripts que solían ser una aguja en un pajar ahora se convierten en una aguja en una pila de agujas.
Me preguntaba si hay alguna buena razón para que esto no se implemente, como que alguien se opondría a esto o que los mineros no han investigado sobre ello o hay algún tipo de preocupación de seguridad al volverse mas complejo bitcoin potencialmente añade más características, siempre suele haber un sacrificio entre seguridad y complejidad.
Ha habido varias rondas de revisión y mejora de todo el conjunto de propuestas y estamos llegando a la línea de meta donde el código está llegando a la estabilidad, las propuestas son estables, el formato de dirección es estable, de hecho, el último formato de dirección se propuso la semana pasada.
Ahora la siguiente parte es la difícil.
La siguiente parte es la activación en la red bitcoin, ya en el pasado hemos visto para sorpresa y horror de los involucrados que lo que debería haber sido una mejora de la escalabilidad relativamente no política se convirtió en un debate muy polemico.
Se convirtió en un pararrayos para una batalla política de poder y, finalmente, se convirtió en una activación muy difícil.
Creo que muchos de los desarrolladores de bitcoin core y de los monederos no quieren que se repita ese escenario, por lo que se está abordando con mucho cuidado para asegurarse de que no se convierta en una lucha, mucha consideración, mucha revisión, muchas pruebas y un proceso de activación que dé a todos mucho tiempo para decidir.
Al contrario de lo que ha insinuado Adam al principio no tenemos un proceso de activación todavía, el proceso de activación en sí se está debatiendo.
Una posibilidad es lo que llamamos la activación bip9, que es una activación en la que se tiene que llegar al umbral del 95% para bloquear y dos semanas más tarde se activaría, pero no hay un plazo limite. Se podría estar por debajo del umbral de activación para siempre, esto fue lo que se utilizó para segwit.
No es una opción muy popular debido a la oportunidad de politizar esta decisión.
Otra alternativa se llama bip8, es una activación por umbral con un día definido. Lo que significa que los mineros tienen la oportunidad de "votar" su aprobación para este cambio y si el 95% de los mineros aprueban este cambio y lo manifiestan en sus bloques, entonces el cambio se bloquea y dos semanas después se activa, pero si no lo hacen, entonces en una fecha determinada se bloquea y se activa de todos modos, por lo que pueden activarlo antes pero no pueden posponerlo.
Se está estudiando cual es el mejor enfoque, por lo que recientemente para decidir la mejor manera de activarlo uno de los desarrolladores hizo una encuesta, es un enfoque muy de la vieja escuela.
Publicaron varios formularios y dijeron: "Oye, si estás interesado en decirme, como minero, lo que crees que deberíamos hacer, envíame tu opinión, ¿crees que deberíamos ir a bip 9? ¿crees que deberíamos ir a bip 8? o alguna otra combinación, y ¿estás a favor o no de taproot?"
Finalmente, consiguieron que más del 90% de los mineros, por el poder del hash, señalaran por mensajes privados o a través de notas públicas y tweets que sí apoyamos taproot y preferiríamos bip8 o preferiríamos bip8 con un umbral aquí o preferiríamos bip9 modificado de esta manera, y de esa encuesta esa encuesta informal espero que en los próximos meses vamos a ver un plan de activación real para ser incluido en el código y la posibilidad de activación en algún momento entre 2021 y 2022.
No es inminente, esto no va a llegar al blockchain en los próximos meses pero estamos en la recta final.
El articulo esta algo desactualizado en las aseveraciones finales, ya tenemos un método para activar taproot y se llama Speedy Trial
Podemos seguir el avance del "voto" de los mineros aqui https://taproot.watch
Podriamos forzar con otro UASF?? https://bitcointaproot.cc
