Nos enorgullece anunciar que la BitBox02 es la primera billetera de hardware capaz de realizar pagos silenciosos de Bitcoin de manera segura. En esta serie de artículos del blog, queremos mostrarte cómo funcionan los pagos silenciosos y qué hace la BitBox02 internamente para garantizar que estos pagos se ejecuten de forma segura.
La compatibilidad para enviar a direcciones de pago silenciosas estará disponible para todos los usuarios de la BitBox02 en una futura actualización.
- Parte I explica cómo funcionan los pagos silenciosos en general.
- Parte II mostrará información interesante sobre lo que hace tu BitBox02 internamente para admitir pagos silenciosos de manera segura.
Los pagos silenciosos o Silent Paymentss son una BIP (Bitcoin Improvement Proposal, o propuesta de mejora de Bitcoin) que introduce un nuevo formato de direcciones de Bitcoin. Su principal ventaja es que se trata de una dirección estática, lo que elimina la necesidad de gestionar múltiples direcciones sin comprometer la privacidad. Si quieres saber más sobre los fundamentos de este concepto, consulta nuestro artículo anterior sobre los reusable payment codes (códigos de pago reutilizables) .
Actualmente, para mantener la privacidad, el destinatario debe interactuar con el remitente para proporcionarle una nueva dirección fresca para cada transacción. Esto conlleva una mala experiencia de usuario o dificultades operativas..
Por ejemplo:
- Retirar fondos de un exchange: en cada retiro, debes obtener una nueva dirección de recepción no utilizada desde la BitBoxApp, registrarla en el exchange y verificar que sea la dirección correcta tanto en la BitBox como en un segundo dispositivo.
- Depositar en un exchange: para cada depósito, debes crear una nueva dirección de depósito en el exchange y verificarla en un segundo dispositivo y en tu BitBox antes de enviar las monedas.
- Recibir donaciones: necesitas configurar y operar un servidor como BTCPay Server para generar nuevas direcciones para cada donante.
Muchos servicios y usuarios de Bitcoin evitan estas complicaciones reutilizando una sola dirección, comprometiendo su privacidad, ya que todas las transacciones relacionadas con esa dirección pueden identificarse y analizarse fácilmente..
Los pagos silenciosos buscan resolver estos desafíos. Utilizan direcciones estáticas diseñadas para ser reutilizadas, mientras que las transacciones realizadas hacia ellas solo pueden ser identificadas por el remitente y el destinatario. Las organizaciones benéficas, por ejemplo, podrían publicar su dirección de donaciones en su sitio web sin que nadie pueda saber quién donó o cuánto. Los exchanges podrían registrar una única dirección de pago silenciosa para todos los retiros.
Las transacciones hoy en día
Una transacción de Bitcoin está compuesta por entradas (inputs) y salidas (outputs)..
Las salidas crean nuevos UTXO (unspent transaction outputs o salidas de transacción no gastadas), y las entradas gastan UTXO existentes. Si quieres aprender más sobre qué son los UTXO, consulta nuestro artículo en el blog sobre el tema.
Normalmente, un UTXO se bloquea con una única clave pública y se gasta proporcionando una firma creada con la clave privada correspondiente. Cuando envías bitcoin a una dirección, tradicionalmente la dirección codifica una clave pública (o el hash de una clave pública).
Los pagos silenciosos utilizan técnicas criptográficas interesantes para derivar una clave pública nueva y no utilizada para cada transacción que se envía a una dirección de pago silenciosa. A continuación, construiremos una base de conocimiento e intuición para entender cómo funciona esto. Lo siguiente es una descripción simplificada y de alto nivel de cómo funcionan los pagos silenciosos. Para conocer los detalles completos, consulta la propuesta oficial.
Un repaso rápido: claves privadas y públicas
Una clave privada es simplemente un número grande, tan grande que no puede ser adivinado. Por ejemplo:
92193805913277071008055984303319191614197341949664602874511898854633635443214
Por cada clave privada, existe una clave pública correspondiente. Conocer la clave pública no revela información sobre su clave privada.
as claves públicas forman parte de un grupo matemático donde la suma tiene un significado especial. Si quieres saber más sobre esto, te recomendamos la serie de artículos “Elliptic Curve Cryptography: a gentle introduction”.
La fórmula para derivar una clave pública a partir de una clave privada es:
PublicKey = privateKey×G ,
donde G es un valor predefinido llamado generador. El generador es una clave pública especial: todas las demás claves públicas pueden generarse a partir de ella mediante sumas.
Por ejemplo, si tu clave privada es 2, tu clave pública será 2×G = G + G. Si tu clave privada es 3 tu clave pública es 3×G = G + G + G, y así sucesivamente. En la práctica, tu clave privada será un número enorme e imposible de adivinar, como en el ejemplo anterior.
Aunque la división no es posible aquí (de lo contrario, podrías calcular la clave privada a partir de la pública), la mayoría de las operaciones matemáticas funcionan igual. Leyes conocidas como la distributiva se mantienen:
(a + b)×G = a×G + b×G
En el resto de este artículo, usaremos letras minúsculas para las claves privadas y mayúsculas para las claves públicas. Por ejemplo: a×G = A.
Elliptic-Curve Diffie-Hellman
El protocolo ECDH (Elliptic-Curve Diffie-Hellman) ermite crear un secreto compartido entre dos partes, Alice y Bob.
Supongamos que Alice quiere hacer una transacción a Bob.
- Alice tiene un par de claves privada/pública:
a×G = A. - Bob tiene un par de claves privada/pública:
b×G = B.
Ambos pueden crear un secreto que solo ellos conocen sin comunicar nada más que sus claves públicas.
- Alice calcula el secreto compartido como
S = a×B. - Bob calcula el secreto compartido como
S = b×A.
Puedes ver que ambos valores son iguales al reemplazar B = b×G y A = a×G ya que:
S = a×B = a×(b×G) = a×b×G = b×a×G = b×(a×G) = b*A = S.
S=(a×b)×G es técnicamente una clave pública correspondiente a la clave privada a×b y podría usarse en una salida de transacción para enviarle bitcoin. Sin embargo, los fondos sólo podrían gastarse combinando ambas claves privadas, la de Alice y la de Bob.
Para evitar compartir claves privadas, este valor puede interpretarse como una nueva clave privada al aplicarle una función hash:
s = hash(S). Las monedas enviadas a la dirección de pago silenciosa podrían entonces bloquearse con la clave pública:P = hash(S)×G = hash(a×B)×G = hash(b×A)×G.
Estas monedas aún podrían ser gastadas tanto por Alice (usando su clave privada a) como por Bob (usando su clave privada b). ¿Cómo podemos bloquear las monedas para que solo Bob pueda gastarlas? Veámoslo.
Pagos silenciosos o Silent payments
Una dirección de pago silenciosa tiene el prefijo sp1 (en lugar del habitual bc1 ) y, por ejemplo, podría verse así:
sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv
Es bastante larga, ya que codifica no una sino dos claves públicas del destinatario: una clave pública B_scan para el escaneo y una clave pública B_spend para el gasto. La clave adicional se utiliza para bloquear las monedas de manera que solo Bob pueda gastarlas.
En lugar de usar la clave pública P = hash(S)×G para bloquear las monedas, Alice añade la segunda clave pública de Bob::P = B_spend + hash(S)×G. Ella calcula el secreto compartido S usando la clave pública de escaneo de Bob y su propia clave privada: S=a×B_scan.
Alice puede crear esta clave pública P ya que conoce B_spend y B_scan (de la dirección de pago silenciosa de Bob), y conoce su propia clave privada a.
La clave pública resultante P se añade como una salida Taproot a la transacción.
Solo Bob puede gastar estas monedas usando sus dos claves privadas b_spend y b_scan. Para gastarlas, debe conocer la clave privada p correspondiente a la clave pública P.
P = B_spend + hash(S)×G
Reemplazando B_spend = b_spend×G tenemos:
P = b_spend×G + hash(S)×G
Aplicando la Ley distributiva (a + b)×G = a×G + b×G, obtenemos:
P = (b_spend + hash(S))×G
Por lo tanto, la clave privada resultante para que Bob gaste las monedas es:
p = b_spend + hash(S).
Bob puede calcular el hash del secreto compartido S usando su clave privada de escaneo:hash(S)=hash(b_scan×A), y luego obtener la clave privada final sumándole b_spend a este.
¿Qué clave usa Alice? ¿Y cómo sabe Bob su clave pública?
Alice, que desea enviar monedas a Bob, conoce las claves públicas de Bob, ya que están codificadas en su dirección de pago silenciosa.
Pero ¿qué pasa con las claves de Alice? ¿Cómo puede Bob conocer la clave pública de Alice para volver a crear el secreto compartido y así detectar los pagos enviados a su dirección de pago silenciosa y gastar las monedas? Sería poco práctico que el destinatario tuviera que interactuar con cada remitente para obtener sus claves públicas. La solución es elegante: las claves relevantes están incluidas directamente en la transacción.
Alice gasta sus propios UTXO en una transacción hacia Bob, los cuales ya están bloqueados con un par de claves privada/pública. Dado que necesita sus claves privadas para gastar sus monedas, también puede usarlas para crear el secreto compartido.
Alice puede calcular el secreto compartido de un pago silencioso usando las claves privadas de los UTXO que utiliza como entradas en la transacción.
Bob puede calcular el mismo secreto compartido usando las claves públicas de Alice, que están incluidas en las entradas de la transacción.
Como una transacción puede tener muchas entradas, Alice utiliza una clave privada combinada, que es la suma de las claves privadas de todas las entradas:
a = a_1 + a_2 + …
Y Bob usa la clave pública combinada de Alice, sumando las claves públicas de las entradas de la transacción:
A = A_1 + A_2 + …
La suma de las claves privadas es la clave privada de la suma de las claves públicas, según la ley distributiva:
A = (a_1 + a_2 + …)×G = a_1×G + a_2×G + … = A_1 + A_2 + …
Para que los pagos silenciosos funcionen, cada entrada debe estar asociada a una sola clave pública. Por tanto, las únicas entradas permitidas en transacciones de pago silencioso los siguientes: P2TR (key spends), P2WPKH, P2WPKH-P2SH y P2PKH, o en otras palabras, los tipos de scripts de firma única, que actualmente son los más comunes. Desafortunadamente, si Alice usa una cuenta multisig nativa (ignorando esquemas de agregación como MuSig2) u otra cuenta que use scripts avanzados, no podrá realizar pagos silenciosos. Esto es una limitación importante y un obstáculo para su adopción.
Garantizando que las direcciones no se reutilicen
El objetivo principal de los pagos silenciosos es evitar la reutilización de direcciones o claves públicas. Según el esquema anterior, la clave pública del destinatario se crea dinámicamente a partir de las claves de Alice (de las entradas de la transacción) y de la dirección de pago silenciosa de Bob. Sin embargo, si Alice reutiliza siempre la misma dirección, podría terminar usando la misma clave de entrada varias veces, produciendo la misma clave pública de salida.
Para solucionar esto, en lugar de calcular la clave de salida como:
P = B_spend + hash(S)×G
se calcula como:
P = B_spend + hash(input_hash×S)×G
donde input_hash = hash(outpoint || A), es decir, el hash del outpoint de una de las entradas de la transacción. Un outpoint es el ID de una transacción junto con el índice de salida, identificando de forma única un UTXO de una transacción anterior. Como los UTXO no pueden gastarse dos veces, incluir el hash del identificador de un UTXO garantiza que cada clave pública de salida sea únicar. A se incluye en el hash por una cuestión técnica descrita en la BIP.
En un borrador inicial de la propuesta, el input hash se calculaba sobre todas las entradas de la transacción, ordenadas lexicográficamente. En mi revisión del borrador comenté que esto era problemático para las billeteras de hardware (haz click en “Show resolved” para expandir el hilo):
Esto es problemático para las billeteras de hardware. Estas tienen memoria limitada y podrían no ser capaces de cargar todos los outpoints y ordenarlos. Como resultado, habría que restringir las transacciones para que ya estuvieran ordenadas al momento de firmarlas, lo cual no es deseable y causaría problemas de compatibilidad.
Tal vez, en lugar de utilizar los hashes de los outpoints guardados, podríamos utilizar algo como: [...]
En la discusión que siguió, se encontró una solución que cumplía los requisitos y era viable para implementar en billeteras de hardware: hashear solo una entrada, la más pequeña según el orden lexicográfico. Esta solución terminó siendo adoptada en la versión final de la BIP, lo que nos permitió implementar la compatibilidad con pagos silenciosos en la BitBox02 sin dificultades.
Resumen
Hemos introducido el concepto de pagos silenciosos, una propuesta de mejora de Bitcoin (BIP) para un nuevo formato de dirección que permite reutilizar direcciones estáticas sin comprometer la privacidad. Explicamos los fundamentos de las claves privadas y públicas, el proceso de creación de un secreto compartido mediante el protocolo ECDH y cómo este puede usarse para bloquear monedas de manera que solo el destinatario pueda gastarlas.
En la próxima entrega, exploraremos cómo los pagos silenciosos cambian el papel de las billeteras de hardware y profundizaremos en lo que estas deben hacer internamente para admitir pagos silenciosos de forma segura.
¿Aún no tienes una BitBox?
Mantener tus criptomonedas seguras no tiene por qué ser difícil. La billetera física BitBox02 almacena las claves privadas de tus criptomonedas offline. Así podrás gestionar tus monedas de forma segura.
La BitBox02 también viene en versión sólo Bitcoin, con un firmware radicalmente enfocado: menos código significa menos superficie de ataque, lo que mejora aún más tu seguridad cuando sólo almacenas Bitcoin.
¡Hazte con una en nuestra tienda!
Shift Crypto es una empresa privada con sede en Zurich, Suiza. Nuestro equipo de colaboradores de Bitcoin, expertos en criptomonedas e ingenieros de seguridad crea productos que permiten a los clientes disfrutar de un viaje sin estrés desde el nivel de principiante hasta el nivel de maestría en la gestión de criptomonedas. La BitBox02, nuestra billetera de hardware de segunda generación, permite a los usuarios almacenar, proteger y realizar transacciones con Bitcoin y otras criptomonedas con facilidad, junto con su software complementario, la BitBoxApp.