Bitcoin es uno de los avances más importantes de toda la era digital en términos de transferencia de valor entre una persona y otra. No requiere intermediarios. Está asegurado por un quórum descentralizado de mineros y validado por cada participante en la red que elige para garantizar la validez de los pagos individuales. La arquitectura del sistema está diseñada para permitir que cualquier persona de cualquier parte del planeta reciba dinero de cualquier otra persona sin importar dónde se encuentre. El crowdfunding, la caridad, la financiación de cualquier cosa que desee se vuelve posible al instante sin necesidad de permiso de nadie, sin tener que lidiar con ningún guardián, sin trámites burocráticos. Es una idea brillante en teoría, pero en realidad, adolece de una gran deficiencia: la privacidad.
Como un sistema de pago basado en push (a nadie se le permite “retirar” los pagos de usted, debe autorizarlos explícitamente usted mismo y “empujarlos” a otras personas), Bitcoin requiere que el remitente tenga la información necesaria para definir el destino de dinero que envían. Esto requiere que el destinatario comunique al remitente su dirección de Bitcoin de una forma u otra. En el caso de tratar de recaudar dinero del público en general, esto tiene enormes consecuencias en términos de privacidad o la necesidad de mantener una presencia interactiva constante en línea. Cualquiera es totalmente capaz de simplemente publicar una sola dirección de Bitcoin en algún lugar en línea y, a partir de ese momento, cualquier persona que desee enviar dinero a esa persona puede simplemente hacerlo, pero no hay privacidad en recaudar dinero de esta manera. Simplemente tome esa dirección y búsquela en la cadena de bloques, y no solo podrá ver cuánto dinero se ha enviado a esa persona, sino que también podrá ver la huella en la cadena de bloques de todos los que le han enviado dinero. Tanto la persona que intenta recaudar fondos como todos los que les han donado no tienen privacidad alguna; todo está completamente abierto y correlacionado para que todo el mundo lo vea.
La única alternativa a la reutilización de direcciones en la forma de publicar una sola dirección estática requiere ejecutar un servidor que permanezca en línea constantemente para que las personas puedan solicitar una nueva dirección no utilizada cada vez que alguien nuevo quiera donar dinero. Si bien puede no parecer un problema tener algo en línea todo el tiempo en la era digital, tiene un costo y una complejidad, especialmente si alguien está tratando de ejecutarlo en casa con su propio hardware. ¿Y las personas que solo tienen un dispositivo móvil? Es casi imposible en estos días, con las características actuales del sistema operativo, optimizar el uso de la batería para mantener algo funcionando en segundo plano todo el día, e incluso si puede, se agotará la batería.
BIP47
Introduzca BIP47 por Justus Ranvier. El propósito de esta propuesta es habilitar una manera para que alguien pueda publicar suficiente información públicamente para poder recibir fondos de cualquier persona que elija, sin que esa información pública sea suficiente para (1) rastrear cuánto dinero la persona que publicó ha recibido y (2) revelar al público cualquier información sobre quién ha enviado fondos a la persona que los solicita. La idea central es tomar esa información publicada públicamente (o código de pago) y, a partir de ahí, combinar su propio código de pago para generar un nuevo conjunto de direcciones para las que el receptor pueda construir las claves privadas. Este nuevo conjunto de direcciones es específico de la relación entre un solo remitente y el receptor, cada vez que un nuevo remitente utiliza este protocolo para enviar dinero a un receptor, generará un nuevo conjunto de direcciones exclusivo para los dos.
En un nivel alto, el flujo general es el siguiente: la persona que desea recibir dinero genera una nueva clave pública extendida desde su billetera HD en una nueva ruta de derivación y la publica públicamente. Esta nueva clave pública funciona como su “código de pago”. A partir de aquí, alguien que quiera enviarle dinero tomará este nuevo código de pago y tendrá toda la información necesaria para generar nuevas direcciones para enviar dinero. Sin embargo, el problema es que el remitente debe comunicar la información de su propio código de pago al receptor; de lo contrario, no podrá generar la clave privada necesaria para gastar los fondos que se le envían. Esto requiere una “transacción de notificación” especial.
Digamos que Alice quiere realizar transacciones con Bob usando códigos de pago. Alice selecciona un UTXO para enviarlo a la dirección de notificación de Bob, de aquí toma la clave privada asociada con este UTXO y la clave pública asociada con la dirección de notificación de Bob. Ella los multiplica para crear una clave cegadora secreta. Con esto, puede encriptar su código de pago y codificarlos en una salida OP_RETURN. Esto significa que Bob, tomando la clave privada de su dirección de notificación y la clave pública de la entrada gastada de Alice, es la única persona que puede descifrar y leer esta información. Esto funciona porque multiplicar la clave privada de Alice con la clave pública de Bob produce el mismo valor que multiplicar la clave privada de Bob con la clave pública de Alice.
Alice y Bob ahora pueden derivar un nuevo conjunto de direcciones que solo ellos dos conocen, y Alice ahora puede enviar cualquier cantidad de transacciones a Bob usando una nueva dirección cada vez sin que ningún observador externo se dé cuenta del vínculo entre ellos. Hay una segunda variación en la que, en lugar de enviar una salida a la transacción de notificación de Bob, Alice crea una salida de cambio para sí misma usando un multisig 1 de 2 donde una clave es su dirección de cambio y la segunda es el identificador del código de pago de Bob. Una tercera variación utiliza una salida multigrado 1 de 3 para codificar la información necesaria en lugar de OP_RETURN. Aparte de eso, las cosas funcionan igual.
La única deficiencia de BIP47 es la necesidad de utilizar blockspace para enviar una transacción especial que notifique al destinatario que recibirá dinero antes de gastarlo. Esto termina siendo muy ineficiente para los casos de uso en los que alguien solo intenta enviar un pago único. También existe el riesgo de dañar activamente la privacidad si la UTXO utilizada para la transacción de notificación está conectada a las UTXO utilizadas para realizar pagos a las direcciones BIP47 de alguien. Se debe tener cuidado para garantizar el aislamiento entre estas dos cosas para no crear correlaciones que puedan rastrearse en la cadena y la propiedad asociada de UTXO como resultado de diferentes pagos.
Pagos silenciosos
Los pagos silenciosos son la última idea de Ruben Somsen. Resuelve efectivamente el mismo problema que BIP47 sin necesidad de una transacción de notificación con la compensación de necesitar escanear más transacciones para detectar los pagos realizados al destinatario. La idea abstracta es más o menos la misma: publicas una información pública y, a partir de eso, un remitente puede construir una nueva dirección que solo el destinatario podrá reconstruir. La diferencia está en los detalles de implementación.
El receptor publica una clave pública “silenciosa” en algún lugar accesible, y luego el remitente la toma y modifica esta clave pública utilizando la clave privada de una entrada que van a gastar para realizar un pago al receptor. Esto se hace multiplicando la clave privada del remitente con la clave pública silenciosa del receptor y luego agregando esa clave pública silenciosa nuevamente. Esto da como resultado una nueva dirección, que el receptor puede recuperar multiplicando su clave privada con la clave pública de la entrada del remitente y agregando su clave pública silenciosa. Es así de simple.
El gran inconveniente aquí es que el soporte para clientes ligeros es muy difícil, ya que el receptor tiene que escanear cada transacción en cada bloque y calcular las combinaciones de entradas ajustadas a su clave para ver si coincide con una salida en una transacción. Para un usuario de nodo completo, esto no es un aumento insoportable en los costos de validación, pero para las billeteras ligeras sin su propio nodo completo, esto se vuelve muy costoso. Esto podría optimizarse aún más simplemente escaneando el conjunto UTXO. Jonas Nick de Blockstream realizó una prueba de referencia en un Intel i7 y descubrió que le tomó alrededor de tres horas y media escanear todo el conjunto y ejecutar los cálculos para verificar las direcciones. Esto no incluyó el tiempo que lleva buscar la transacción que creó cada UTXO para encontrar las claves públicas de entrada necesarias para ejecutar ese cálculo. Eso aún no se ha comparado ni probado, por lo que el costo y el tiempo siguen siendo una pregunta abierta.
Una optimización adicional que se podría realizar es usar cada entrada en la clave pública de la transacción de envío como parte del ajuste, lo que reduciría el costo de escanear para ver si ha recibido dinero al no requerir que escanee cada entrada individual en una transacción. y ejecute el cálculo individualmente. Sin embargo, esto aumentaría la complejidad de hacerlo con transacciones CoinJoin, ya que requeriría que todos los demás participantes participaran activamente en los ajustes clave. También les filtraría la salida por la que está pagando en la implementación ingenua. Sin embargo, evitaría que el destinatario supiera qué entrada se utilizó para pagarle y, al cegar criptográficamente la información compartida con otros participantes en CoinJoin, evitaría que supiera qué salida es el pago silencioso, mitigando así todos los problemas de privacidad.
También es posible agregar una clave de escaneo y gasto en el proceso de derivación para que el receptor pueda tener una clave en línea que es todo lo que se necesita para detectar los pagos entrantes, mientras mantiene la clave necesaria para gastar las monedas que ha recibido fuera de línea y en almacenamiento en frío. Esto cambiaría la derivación para multiplicar la clave privada de entrada del remitente con la clave de escaneo y luego agregar la clave necesaria para gastar. Esto permitiría una mayor seguridad en la recepción de pagos, dejando solo su privacidad en riesgo si el dispositivo del receptor se viera comprometido.
Una última cosa importante a considerar es el potencial de reutilización de direcciones por parte del remitente. En la implementación base, si un remitente tiene varios UTXO con la misma clave pública, reutilizarlos para enviarlos a la misma persona con un pago silencioso daría como resultado la misma dirección silenciosa y constituiría la reutilización de la dirección. Esto podría evitarse al incluir el TXID y el índice de entrada de la entrada de la transacción utilizada en el esquema, que podría calcularse previamente antes de enviarse a los clientes ligeros para no crear una carga computacional adicional para ellos.
En general, la idea es una mejora sustancial con respecto a BIP47 en todos los sentidos, excepto en los costos de validación más altos para que el receptor escanee los fondos que se le han enviado. Conserva la propiedad de recuperación determinista, logra la desvinculación entre diferentes pagos enviados al receptor y elimina la necesidad de que se realice una transacción de notificación antes de que se realicen los pagos. Una vez más, a Somsen se le ocurrió una idea muy sólida para un protocolo que podría implementarse para mejorar la utilidad de Bitcoin.
Esta es una publicación invitada de Shinobi. Las opiniones expresadas son totalmente propias y no reflejan necesariamente las de BTC Inc o Bitcoin Magazine.
