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

Bitcoin Magazine alloc init lanza una propuesta de Shielded Bitcoin para transacciones privadas en Bitcoin. Shielded Bitcoin es una propuesta presentada por los investigadores de alloc init Clara Shikhelman, Misha Komarov y Aleksei Moskvin para un novedoso metaprotocolo de privacidad en la capa base de Bitcoin que permita transacciones shielded de Bitcoin sin requerir operadores, soft forks ni otros cambios al consenso de Bitcoin. Puedes encontrar el whitepaper aquí y el anuncio del blog aquí.

El protocolo define una estructura transaccional y un protocolo de indexación para transacciones con fuertes garantías de privacidad, mientras se apoya en los PIPEs de Bitcoin para anclar fondos dentro y fuera del sistema. Más sobre el mecanismo de PIPEs al final del artículo. Su diseño es en gran medida un espejo del de Bitcoin; existe un equivalente a un UTXO (una note), las transacciones consumen notes como inputs al igual que una transacción regular de Bitcoin, un witness prueba que los inputs consumidos están debidamente autorizados, y los nodos (indexers en el caso de un metaprotocolo) analizan el historial de transacciones y construyen un estado actual de qué monedas están gastadas y no gastadas, etc. Todos los detalles, sin embargo, son bastante diferentes.

Una transacción de Shielded Bitcoin es solo un blob de datos con un prefijo (algo como "shbtc:") incluido en una transacción de Bitcoin usando OP_RETURN, el campo witness u otro método de transporte de datos. No tiene ningún significado para Bitcoin, la red de Bitcoin no hace nada para verificarla ni aplica ninguna regla contra ella en absoluto. Es perfectamente posible que transacciones inválidas de Shielded Bitcoin terminen on-chain, y es trabajo de un Shielded Bitcoin Indexer, que observa pasivamente la blockchain (léase: nodo), ignorar esas transacciones cuando fallan la validación y negarse a aplicarlas para actualizar el estado de los balances de la red.

Un indexer no elimina notes de un conjunto de notes no gastadas como hace Bitcoin con los UTXOs. Utiliza un nullifier set. Esta es una forma de que un usuario publique públicamente una prueba cifrada y un nullifier de que una note ha sido gastada sin revelar cuál note ha sido gastada. La idea es que, en lugar de ver si una note está en el "conjunto de notes no gastadas", verificas si un nullifier ya ha sido usado. Los indexers construyen un merkle tree que crece para siempre y al que solo se puede añadir, de cada note output creado, y luego el nullifier set.

Para usar este protocolo, todo lo que necesitas es un nodo de Bitcoin y un indexer de Shielded Bitcoin. No hay necesidad de un proveedor de servicios, coordinador ni ningún estado off-chain para recuperar fondos. Funciona igual que el Bitcoin on-chain, todo lo que necesitas es tu nodo/indexer y tus claves. Cada wallet de usuario deriva una master secret key, a partir de la cual se crea cada otro conjunto de claves involucrado. Piensa en esto de manera muy similar a una HD wallet en Bitcoin. Puedes generar muchos conjuntos de direcciones con esta relación.

Sk_spend es tu clave privada, la sk_nf se usa para anular note outputs, la vk_in se usa para descifrar y ver notes entrantes, la vk_out para ver tus transacciones salientes, y la sk_view se usa 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 contra su clave sk_view. Esa clave pública resultante, pk_d, y d son la dirección del usuario.

El remitente entonces genera un valor aleatorio, el r_seed, que es necesario para el cifrado del note output así como para anular (llegaremos a eso en un segundo). Los outputs de transacción contienen solo tres cosas cifradas: el valor del output, el valor d que el receptor le dio al remitente, y el valor r_seed del remitente. El remitente usa un par de claves efímeras secreto y la clave pública del receptor para crear un d secret. Ambas partes pueden generar el mismo secreto multiplicando su clave privada por la clave pública de la otra. El note output se cifra usando este d secret, y la sk_eph efímera se incluye sin cifrar para que el receptor pueda generar el d secret.

En el lado de los inputs, se necesitan dos cosas para tener una transacción válida: un nullifier público para los note outputs consumidos, y una zero-knowledge proof que demuestre que 1) el note output está incluido en el merkle tree de notes, 2) la transacción está autorizada por la clave sk_spend apropiada, 3) el nullifier está correctamente derivado, y 4) no ha ocurrido inflación. Si te fijas en la imagen de arriba, el nullifier usa la clave sk_nf, el valor ρ derivado de r_seed, y la posición de la note en el merkle tree de note outputs.

La zero-knowledge proof garantiza todo esto, y es por eso que puedes simplemente contar nullifiers repetidos en lugar de eliminar notes gastadas. Aunque nunca sabes a qué note output corresponde un nullifier, las zero knowledge proofs en cada transacción garantizan que cada nullifier añadido al conjunto provino de un note output válido. Mientras no haya repeticiones, proporciona la misma garantía contra el doble gasto. Así que ahí está: el protocolo te permite esencialmente incrustar transacciones cifradas de metaprotocolo en la blockchain de Bitcoin, pero aún así proporcionar una garantía de que nada se está gastando dos veces y que las monedas no se están inflando de la nada.

Este es en realidad un sistema muy bien diseñado en términos de propiedades de privacidad, y está a la par de algo como los shielded pools de Zcash. Hay consideraciones de privacidad a tener en cuenta al momento de entrar y salir del metaprotocolo, y estas se detallarán en un próximo paper. No hay ninguna preocupación de medir la privacidad o remezclas periódicas como con los coinjoins.

Entonces, el peg. La intención es construir un peg usando PIPEs v2, un esquema de witness encryption. Los PIPEs te permiten cifrar una clave privada con un programa/mecanismo que no divulgará la clave a menos que puedas proporcionar una ZK-proof de que se ha cumplido cierta condición (es decir, el estado de algún UTXO, que una transacción ha sido confirmada, etc.). Esto permitiría que un peg funcione sin un operador, federación ni ningún tercero custodiando fondos. Esto no requiere softforks ni cambios de protocolo a Bitc