[[alloc] init] presenta una propuesta de Shielded Bitcoin para transacciones privadas

Revista Bitcoin

[[alloc] init] presenta la propuesta de Shielded Bitcoin para transacciones privadas de Bitcoin

Shielded Bitcoin es una propuesta de los investigadores de [[alloc] init] Clara Shikhelman, Misha Komarov y Aleksei Moskvin para crear un novedoso metaprotocolo de privacidad en la capa base de Bitcoin que permita realizar transacciones blindadas de Bitcoin sin necesidad de operadores, bifurcaciones blandas ni otros cambios en el consenso de Bitcoin. Aquí puedes consultar el documento técnico y aquí el anuncio en el blog. 

El protocolo define una estructura transaccional y un protocolo de indexación para transacciones con sólidas garantías de privacidad, y se basa en los PIPEs de Bitcoin para vincular fondos al sistema y retirarlos de él. Al final del artículo encontrarás más información sobre el mecanismo de los PIPEs. 

Su diseño es, en gran medida, un reflejo del de Bitcoin: tiene un equivalente a un UTXO (una nota); las transacciones consumen notas como entradas, igual que una transacción normal de Bitcoin; un testigo demuestra que las entradas consumidas cuentan con la autorización adecuada; los nodos (indexadores, en el caso de un metaprotocolo) analizan el historial de transacciones y crean un estado actual de las monedas gastadas y no gastadas, etc. 

Sin embargo, todos los detalles son bastante diferentes. 

Una transacción de Bitcoin blindado no es más que un bloque de datos con un prefijo (algo como «shbtc:») incluido en una transacción de Bitcoin mediante OP_RETURN, el campo witness u otro método para transportar datos. No significa nada para Bitcoin: la red Bitcoin no hace nada para verificarla ni aplica ninguna regla en su contra. Es perfectamente posible que transacciones inválidas de Bitcoin blindado acaben en la cadena, y es tarea de un indexador de Bitcoin blindado, que observa pasivamente la cadena de bloques (es decir, un nodo), ignorar esas transacciones cuando no superan la validación y negarse a aplicarlas al actualizar el estado de los saldos de la red.

Un indexador no elimina notas de un conjunto de notas no gastadas, como hace Bitcoin con los UTXO. Utiliza un conjunto de nulificadores. Esto permite que un usuario publique abiertamente una prueba cifrada y un nulificador que demuestren que se ha gastado una nota, sin revelar qué nota se ha gastado. La idea es que, en lugar de comprobar si una nota está en el «conjunto de notas no gastadas», se comprueba si ya se ha utilizado un nulificador. Los indexadores construyen un árbol de Merkle que crece para siempre y al que solo se pueden añadir elementos: incluye cada salida de nota creada y, después, el conjunto de nulificadores.

Para usar este protocolo, solo necesitas un nodo de Bitcoin y un indexador de Bitcoin blindado. No hace falta ningún proveedor de servicios, coordinador ni estado fuera de la cadena para recuperar los fondos. Funciona igual que Bitcoin en la cadena: solo necesitas tu nodo/indexador y tus claves.

La cartera de cada usuario deriva una clave secreta maestra, a partir de la cual se crean todos los demás conjuntos de claves implicados.

Piensa en esto de forma muy similar a una cartera HD de Bitcoin. Puedes generar muchos conjuntos de direcciones relacionados de esta manera. Sk_spend es tu clave privada, la sk_nf se utiliza para anular las salidas de notas, la vk_in se utiliza para descifrar y ver las notas entrantes, la vk_out para ver tus transacciones salientes, y la sk_view se utiliza para generar una dirección de recepción. 

Cuando un usuario quiere dar una dirección a alguien para que le envíe fondos, genera un valor diversificador d similar a un valor de derivación y luego multiplica el valor por su sk_view clave pública resultante, pk_d y d es la dirección del usuario. 

A continuación, el remitente genera un valor aleatorio, la r_seed, lo cual es necesario tanto para cifrar la salida de la nota como para anularla (ya llegaremos a eso en un momento). Las salidas de transacción contienen solo tres elementos cifrados: el valor de la salida, el d valor que el receptor dio al emisor, y el valor r_seed del emisor. El emisor usa un par de claves efímeras secretas y la clave pública del receptor para crear un secreto compartido. Ambas partes pueden generar el mismo secreto multiplicando su clave privada por la clave pública de la otra parte. La salida de la nota se cifra usando este secreto compartido, y la clave efímera sk_eph se incluye sin cifrar para que el receptor pueda generar el secreto compartido. 

En el lado de entrada de la imagen, se necesitan dos cosas para que una transacción sea válida: un anulador público para las salidas de nota consumidas y una prueba de conocimiento cero que demuestre que 1) la salida de nota está incluida en el árbol de Merkle de notas, 2) la transacción está autorizada por la clave sk_spend apropiada, 3) el anulador se deriva correctamente y 4) no se ha producido inflación. 

Si te fijas en la imagen de arriba, el anulador usa la sk_nf clave, el valor ρ derivado de r_seed, y la posición de la nota en el árbol de Merkle de las salidas de notas. La prueba de conocimiento cero garantiza todo esto, por lo que puedes limitarte a contar los nulificadores para detectar repeticiones, en lugar de eliminar las notas gastadas. Aunque nunca sepas a qué salida de nota corresponde un nulificador, las pruebas de conocimiento cero de cada transacción garantizan que cada nulificador añadido al conjunto proviene de una salida de nota válida. Siempre que no haya repeticiones, ofrece la misma garantía contra el doble gasto. 

Así que ahí lo tienen: el protocolo permite básicamente insertar transacciones cifradas del metaprotocolo en la cadena de bloques de Bitcoin, sin dejar de garantizar que no se gaste dos veces nada y que no se creen monedas de la nada. 

En realidad, es un sistema muy bien diseñado en cuanto a sus propiedades de privacidad, a la altura de algo como los pools protegidos de Zcash. Hay consideraciones de privacidad que deben tenerse en cuenta al entrar y salir del metaprotocolo, y se detallarán en un próximo artículo. No hay que preocuparse por medir la privacidad ni por hacer mezclas periódicas, como ocurre con los coinjoins. 

Bien, el mecanismo de anclaje. La idea es crear uno usando PIPEs v2, un esquema de cifrado de testigo. PIPEs permiten cifrar una clave privada con un programa o mecanismo que no revelará la clave a menos que puedas proporcionar una prueba de conocimiento cero de que se ha cumplido una determinada condición (por ejemplo, el estado de algún UTXO, que se haya confirmado una transacción, etc.). Esto permitiría que el mecanismo funcionara sin un operador, una federación ni ningún tercero que custodie los fondos.

Esto no requiere bifurcaciones suaves ni cambios en el protocolo de Bitcoin, y ocurre íntegramente fuera de la cadena.

El plan de Shielded Bitcoin y la siguiente fase de su trabajo consisten en un mecanismo de anclaje que permita a los usuarios depositar fondos en Shielded Bitcoin mediante claves controladas criptográficamente por PIPEs, que luego se «desbloquearían» generando una prueba de conocimiento cero de transacciones legítimas de salida del mecanismo, confirmadas en la cadena.

Actualmente se está trabajando en el artículo que definirá este aspecto del sistema, y debería publicarse en un futuro próximo.

Esta publicación [[alloc] init] presenta la propuesta de Shielded Bitcoin para realizar transacciones privadas con Bitcoin. Apareció por primera vez en Bitcoin Magazine y está escrita por Shinobi.

Fuente: BitcoinMagazine