Taproot y Firmas Schnorr - Crypto Academy / S5W6 - Homework post for pelon53.

Tarea.

1.- Explique en detalle el P2SH y el P2PKH, muestre las diferencias entre ambas direcciones.

Comencemos por aclarar que en general, las direcciones son la forma mediante la cual en la cadena BITCOIN se identifican desde donde se envían, a donde se mandan los BTCs y las condiciones a cumplir para validar las operaciones. Estas se representan por sucesiones alfa numéricas que muchas veces se presentan como números en base 16, (como los hashs) y pueden llevar implícitos uno o varios scripts.

Comencemos por la P2PKH.

Direcciones P2PKH. (Pay 2 Public Key Hash)

Esta es una de las primeras direcciones usadas en la cadena y llevan implícitos scripts criptográficos que mejoran la tradicional comprobación de las claves públicas y privadas, bien sea para enviar dinero o recibirlo. Esta se aplica a transacciones donde están involucrados solo el que envía y el que recibe el dinero y sus firmas, (las que se obtienen usando el hash de las claves facilitadas y los scripts del proceso).

Es decir. Si voy a hacer una transacción T cualquiera. La instrucción que sigue el script es que el dinero que envíe solo puede ser retirado por la otra persona que proporcione la clave privada asociada al hash de la clave pública que se me proporcionó como dirección para enviar el dinero.

La cosa va un poco en este sentido.

• X va a mandarle dinero a Y.
• Y debe tener una clave privada y con esta se genera la clave pública.
• Ahora, a esta clave pública se le aplica una función hash.
• Y le envía el hash de su clave pública a X y junto con esto las condiciones o scripts necesarios para recibir sus fondos de forma segura.
• Con estos elementos, X, crea un ScriptPubKey o script de bloqueo donde van como datos: su firma, el hash de la clave publica de Y y el dinero.
• Como paso para completar el P2PKH se debe ejecutar el ScriptSig o script de desbloqueo que lo que hace es comprobar que quien retira el dinero posee la clave privada asociada al hash de clave pública enviado.

Direcciones P2SH. (Pay 2 Script Hash)

Estas direcciones se usan mas que todo para realizar transacciones entre usuarios multifirma, es decir, estas se autorizan con la aprobación de uno o más entes. También se caracterizan por que en estas se pueden incluir condiciones por parte del receptor para poder hacer efectivos los pagos.

Al igual que en las P2PKH no hace falta mandar explícitamente las claves públicas de las direcciones de los receptores, solo se envían un hash con las indicaciones en forma de script. Esto elimina la necesidad de trabajar con un algoritmo descifrable de claves públicas y privadas.
Los tokens se envían en forma de hash junto con los procedimientos definidos en los scripts correspondientes. En estos van inmersas las indicaciones y condiciones para poder retirar los fondos (estas indicaciones también se conocen como redeem script).

Veamos más específicamente cómo funciona esta dirección.

• La responsabilidad de colocar los redeem script recae enteramente en el receptor del dinero.
• Quien envía no tiene porque saber cuales son esas condiciones y tampoco las claves públicas requeridas de los destinatarios. Estas solo se revelarán cuando los receptores hagan uso de ese dinero.
• El receptor envía al pagador un mensaje codificado de su redeem script, de solo 34 caracteres, en lugar del redeem script completo. Esto le ayuda evadir errores y ahorrar espacio. Recuerde que en las blockchains se cobran comisiones por datos, no por cantidad de dinero. Es importante saber que el mensaje codificado mencionado va a funcionar ahora como una dirección en la red a la que van a ser enviados los activos. Estas direcciones se pueden reconocer porque comienzan con un 3 en lugar de la usuales que comienzan con un 1.

Ahora supongamos que se quiere hacer una transferencia a un ente A que depende de 4 claves públicas: k1,k2,k3.k4. Se va a poner como condición que dos de los propietarios de las claves den su firma.

En este caso se genera un ScripSig como se ve en la siguiente imagen

fuente

En el aparecen el número de firmas necesarios para desbloquear la transacción y el número total de estas (MugSig 2 de 4), las 4 claves privadas asociadas a las firmas pedidas y el script OP_CHECKMULTISIG que es el encargado de comprobar la valides de las firmas y las llaves para desbloquear la transacción. recordemos que estos datos están en manos del receptor y es el único que puede generar este ScripSig.

Ahora hay que generar el ScriptPubKey

Ya con el ScripSig generado, a las instrucciones de desbloque (redeem script ) se les aplica la operación OP_HASH160, esto genera el hash que será enviado al remitente. Ahora se coloca como condición de desbloqueo que el receptor, luego de aplicar la misma operación OP_HASH160 a su redeem script coincida con el enviado al remitente. Es obvio que el único que puede cumplir con este requisito es el receptor que fue quien originó dicho hash.

El ScriptPubKey (de bloqueo) queda como se ve en la siguiente imagen.

fuente

diferencias entre P2SH Y P2PKH

1. Las direcciones P2SH comienzan con un 3 y las P2PKH con un uno. Esto se debe a que los codificadores que se usan en cada caso son distintos.

2. Las direcciones P2SH admiten operaciones multifirmas, las P2PKH no.

3. En las P2PKH se envía al remitente un hash de la clave pública del receptor. En las P2HS se le envía un hash del redeem script.

4. Los procedimientos en P2SH son más sencillos que los de P2PKH.

5. A pesar de llevar implícita más información y más condiciones, las comisiones con P2SH son menores que las de P2PKH.

2.- Se requiere transferir 10 BTC que pertenecen a una cartera multifirma 3 de 5, a la empresa MTC, por la compra de unos equipos.
• Use el ScriptSig y el ScriptPubKey para explicar los pasos que se siguen.
• Explique ¿Qué sucede si la transacción se realiza usando las firmas Schnorr?

Básicamente los pasos requeridos son los explicados al final de la pregunta 1. Igual haremos un breve resumen.

En este caso tenemos un MugSig 3 de 5. El ScriptSig correspondiente queda como se ve en la figura de abajo.

Acá 3 de los 5 receptores de la transacción deben validarla con su firma y el OP_CHECKMULTISIG es el encargado de verificar que las firmas dadas son correctas.

Ahora hay que generar el ScriptPubKey. El procedimiento de esta parte es análogo al descrito al final de la pregunta 1, solo cambia que allá se necesitaban 2 firmas de 4 y acá 3 firmas de 5.

El emisor del dinero no necesita ver las condiciones de envío. Solo el hash del redeem script. Por eso el ScriptPubKey no varía en su forma y solo cambia al cambiar el hash facilitado.
Ver imagen siguiente.

fuente

Ya con el ScripSig generado, a las instrucciones de desbloque (redeem script ) se les aplica la operación OP_HASH160, esto genera el hash que será enviado al remitente. Ahora se coloca como condición de desbloqueo que el receptor, luego de aplicar la misma operación OP_HASH160 a su redeem script coincida con el enviado al remitente. Es obvio que el único que puede cumplir con este requisito es el receptor que fue quien originó dicho hash.

En el caso en que tenemos transaccines multifirmas , cada una de las firmas que se necesitan generan una cantidad de datos que hacen mas pesada la operación y por lo tanto el pago en comisiones. Las firmas Schnorr lo que hacen es que toman estas firmas y la sintetizan en una sola. Las firmas en Bitcoin se manejan con ECDSA, las firmas de Schnorr utilizan otros estándares aún anteriores al ya mencionado. El funcionamiento de estos procedimientos no es sencillos de entender o manejar. Solo podemos, por ahora , ocuparnos de las ventajas o desventajas de su aplicación.

En nuestro caso las 5 firmas dadas serán resumidas y codificadas por el procedimiento de Shnorr en una sola firma, que se usará para hacer las transacciones como si esta dependiera de ella solamente.

3.- ¿Por qué cree usted que Taproot y las firmas Schnorr ayudarán a la privacidad de la red Bitcoin? Explique.

Creo que la respuesta es un rotundo SÍ. Procedo a dar mis razones.

1. Al sintetizar las multifirmas en una sola se está ocultando información sensible de los participantes en la red, ya que solo se está facilitando un código representativo y no la información de las firmas involucrados como tal.

2. Mientras menos datos se muestren, menos posibilidad hay de conseguirlos.

3. Las firmas son datos pesados, cuando se sustituyen estas por su única firma de Shnorr se economizan los recursos.

4. Las firmas de Shnorr pueden hacer ver una transacción multifirmas como una transacción normal. Incluso, si tenemos una transacción del tipo n de n firmas es prácticamente imposible distinguirla de una de una sola firma.

5. Las firmas de Shnorr nos ahorran datos y eso se traduce en ahorro en comisiones.

6. También el uso de P2PkH y P2SH nos aseguran ahorro de datos y más privacidad.

4.- Usando la Demo de Blockchain, escriba exactamente el siguiente mensaje: Schnorr Signatures, genere la firma del mensaje y verifique el mensaje. Luego borre el primer caracter de la firma del mensaje y verifique nuevamente ¿Qué sucedió? Explique. Se requiere captures de pantalla.

Vamos a la dirección facilitada en la clase, Blockchain Demo: Public / Private Keys & Signing, de donde tomaremos las capturas en esta pregunta.

En la siguiente imagen vemos que colocamos la frase dada (recuadro verde superior). En el recuadro verde inferior aparece la clave asociada.

En la imagen siguiente, al dar clic sobre el óvalo amarillo que dice sing, obtenemos la firma del mensaje, encerrado en el recuadro amarillo.

Pasamos a verificar la firma haciendo clic en el menú "Verify" (recuadro verde superior). Luego de esta acción vemos como en el cuadro inferior verde aparece la notificación de que ya se verificó la firma.

Ahora miramos que pasa al eliminar la primera letra de nuestra frase de prueba.
En nuestra última imagen se puede notar que tras la modificación e intento de verificación, la página toma un tono rojizo. Lo que se interpreta como un fallo, es decir, que la firma no se corresponde con el mensaje escrito.

Este fallo se produce por que al cambiar el más mínimo detalle en estos mensajes ya los códigos cambian completamente. Recordemos que las funciones de codificación son funciones uno a uno. es decir , que mensajes diferentes, siempre van a tener códigos diferentes. esto es lo que nos garantiza que no se pueden alterar los datos enviados en una transacción.

Conclusiones

La parte que estudia el funcionamiento interno, criptográfico y lógico de la blockchain de Bitcoin es bastante dura y complicada. A pesar de que esta se basa en los scripts, que son programas muy básicos, la combinación y uso de estos no es un tema para principiantes. Eso no quiere decir que debamos desentendernos de ellos , sino más ben , debemos intentar comprenderlos por lo menos en sus comportamientos básicos.

La criptografía y generación de claves con sistemas como el ECDSA o sus respectivos hash también forman parte del complicado andamio que mantiene funcionado esta Blockchain.

Cuando se proponen actualizaciones tipo Taproot junto con las direcciones P2PKH , P2HS y las firmas de Shnorr estas lo que buscan es tomar los elementos antes mencionados y optimizar su uso para lograr una mayor escalabilidad y privacidad en esta red.

Las técnicas antes mencionadas ayudan a mantener fuera del alcance de extraños datos privados que pueden vulnerar nuestra seguridad y ahorrarnos generación de datos a la hora de hacer nuestras transacciones.