Cuando escuchan la palabra”CoinJoin”, lo primero que aparece en la cabeza de muchos Bitcoiners relativamente nuevos es probablemente el Implementaciones ZeroLink de Wasabi Wallet y Samourai Wallet. En los últimos años, estos dos proyectos han llevado la privacidad de Bitcoin casi a la corriente principal, haciéndola mucho más simple y accesible.
Sin embargo, si es nuevo en el espacio, es posible que no sepa que el proyecto JoinMarket ha estado proporcionando herramientas CoinJoin a los usuarios de Bitcoin desde 2015.
Colaborativo transacciones para interrumpir los supuestos de propiedad común fueron una idea propuesta por el desarrollador de Bitcoin Greg Maxwell en enero de 2013, y luego formalizada en el concepto de CoinJoin en agosto de ese año.
La idea se mantuvo durante dos años antes de que se lanzara algo para implementarla, y había una razón para eso: un problema con la idea general que condujo a fallas con intentos anteriores, como Dark Wallet de Amir Taaki, era el de atraer liquidez. CoinJoin puede ser una herramienta muy útil, pero si no hay nadie dispuesto a CoinJoin contigo o no hay forma de encontrarlo si está dispuesto, no sirve de nada.
El problema era cómo convencer a la gente de que se uniera a ese grupo inicial para ayudar a convertirlo en un grupo más grande de liquidez y usuarios. La solución de JoinMarket era bastante simple pero brillante en ese momento: proporcionar un mecanismo de mercado para que los proveedores de liquidez constante puedan ganar dinero para proporcionar liquidez a los grupos de CoinJoin.
JoinMarket funciona en torno a lo que es efectivamente un mercado impulsado por carteras de pedidos, compuesto por creadores de mercado y tomadores de mercado que compran y venden liquidez de CoinJoin para anonimizar su actividad en cadena.
Los creadores pueden quedarse sentados esperando el tiempo que sea necesario con ofertas abiertas hasta que lleguen los compradores que buscan pagar por sus servicios. Resuelve el problema del usuario de sentarse y esperar eternamente a que alguien se mezcle. Los creadores de mercado, que buscan obtener ganancias, se ven incentivados por las tarifas que cobran a simplemente estar siempre en línea esperando a los interesados; y los receptores, que buscan privacidad, están incentivados a pagar estas tarifas. Es un arreglo en el que todos ganan.
En su arquitectura, así como en su potencial para actualizaciones de coordinación, JoinMarket ofrece una versión potencialmente más descentralizada de la mezcla de monedas en comparación con el más conocido ZeroLink. He aquí cómo.
Cómo se coordina la mezcla: ZeroLink vs. JoinMarket
La arquitectura general de ZeroLink, en comparación con JoinMarket, es muy diferente.
En el caso de Wasabi y Samourai, hay un único servidor coordinador operado por el creador de la billetera codificado en la billetera. Todos los usuarios participan en CoinJoin poniéndose en contacto con este servidor central y”registrándose”para esperar hasta que se hayan registrado suficientes usuarios para construir CoinJoin. Una vez que el número requerido de usuarios está presente y registrado, el servidor coordinador firma una credencial cegada que representa el derecho a crear una salida en la transacción CoinJoin, y el usuario se desconecta y se vuelve a conectar a través de una nueva conexión Tor para registrar sus salidas de transacción.
Esto evita que el coordinador sepa qué entradas se asignan a qué salidas. Los usuarios pagan una tarifa al coordinador por su papel en la facilitación de CoinJoin. En este modelo, no hay ningún incentivo para proporcionar liquidez excepto por las ganancias de privacidad y, a pesar de los problemas con intentos anteriores como Dark Wallet, esto parece funcionar bien para Wasabi y Samourai.
JoinMarket, por otro lado, tiene un libro de pedidos en el que los fabricantes anuncian, lo que permite a los compradores elegir entre las ofertas disponibles del fabricante (esto se hace actualmente a través de Internet Relay Chat [IRC]).
Los fabricantes se conectarán al libro de pedidos con una identificación única, luego publicarán una oferta en el libro de pedidos que contiene la siguiente información: la tarifa que el fabricante está cobrando por mezclarse con los compradores, la cantidad a la que contribuirá el fabricante tarifas de minero y luego el valor de denominación mínimo y máximo en el que realizarán salidas denominadas mixtas. También publican una forma para que las personas se conecten de forma privada con ellos directamente.
Cuando los compradores quieren CoinJoin, descargan el libro de pedidos y su cliente selecciona a los fabricantes con los que mezclarse en función de su configuración. Después de que el cliente selecciona un creador, el receptor publicará una clave pública temporal para el cifrado y comenzará a comunicarse con el creador a través de mensajes cifrados a través de IRC (vale la pena señalar que es posible que varios receptores se conecten a un solo fabricante al mismo tiempo). tiempo). Si todas las partes están de acuerdo, firman la transacción, incluida la tarifa del receptor al fabricante, y la envían a la red.
Debido a cómo funciona esta coordinación, los creadores aprenden los resultados de los receptores en el proceso de coordinación de la construcción de CoinJoin. Para mitigar esto, JoinMarket tiene una función de”caída”, donde el cliente del receptor se mezclará varias veces con diferentes fabricantes hasta alcanzar el número de mezclas establecido. Esto garantiza que ningún fabricante podrá deshacer el historial de mezcla completo de un solo comprador, porque cada fabricante a lo largo de la”ruta de caída”solo aprende las conexiones en esa transacción.
Estas diferencias tienen muchas implicaciones generales en términos de arquitectura de diseño para JoinMarket, como veremos al analizar parte del estado actual del proyecto, así como los planes futuros.
Cómo se mitigan los ataques de Sybil: ZeroLink vs. JoinMarket
Los ataques de Sybil (en este contexto, un solo usuario que finge ser muchos usuarios para socavar la privacidad al crear una”multitud”falsa en la que otros se esconden mientras en realidad constituyen la”multitud”completa) son un problema fundamental de cualquier protocolo de mezcla en Bitcoin. Si toda la multitud está compuesta por usted y el atacante Sybil, y nadie más, el atacante conoce todas sus monedas y usted no ha ganado privacidad desde su punto de vista. Al final del día, no hay una solución fundamental para este problema, todo lo que puede hacer para mitigarlo aumentando el costo de realizar el ataque.
En el caso de ZeroLink, el problema se mitiga con el coordinador cobra tarifas. Siempre que el costo de las tarifas de los mineros sea más alto que los ingresos por tarifas que el servidor coordinador recauda en tarifas, incluso el coordinador incurriría en una pérdida neta al intentar que Sybil ataque a sus propios usuarios.
Para JoinMarket, el problema es un poco más complicado. Tienes que proteger a los receptores, en su caso de que los fabricantes Sybil ataquen el libro de pedidos para que un receptor solo se mezcle con ellos y revele todo su historial de mezclas al creador malicioso. Pero también debe proteger a los receptores de los atacantes solicitando CoinJoins y luego abandonando el protocolo después de que el fabricante revela sus resultados al receptor.
Esto permite que el receptor malintencionado separe las entradas de ese fabricante en transacciones futuras de los receptores con los que se mezclan. Repetir esto varias veces seguidas contra el mismo fabricante les permitiría desanonimizar a los receptores que se han mezclado con ellos.
Hay dos mecanismos en este sistema para ofrecer una defensa adecuada para cada clase de ataque: el primero, para lidiar con los receptores que espían a los creadores, es una prueba de equivalencia de logaritmos discretos (defensa número dos en este artículo , también conocido como PoDLE).
La idea básica es que para un par de claves pública/privada para un UTXO de Bitcoin, puede generar una segunda clave pública diferente correspondiente a la clave privada y crear una prueba de conocimiento cero (ZKP) que muestre ambas comparten la misma clave privada. Después de proporcionar la segunda clave y la prueba al creador, el tomador revela la primera clave pública correspondiente a la salida que desea mezclar.
Ahora, esta configuración le permite a un creador publicar la segunda clave pública y ZKP para todos los demás creadores sin doxxing los resultados reales del receptor, de esa manera, si un receptor que está coordinando con el fabricante original intenta reutilizar eso salida para espiar a varios fabricantes al mismo tiempo, todos los demás fabricantes verán que la primera clave pública del receptor coincide con la segunda clave publicada y ZKP. Entonces se negarán a revelar sus propios resultados al tomador malintencionado. Esto aumenta el costo de los receptores que espían los resultados de los fabricantes al exigir que un receptor tenga resultados únicos para cada fabricante al que espían, en lugar de poder reutilizar los mismos resultados para atacar a varios fabricantes.
El segundo mecanismo de defensa es proteger a los receptores de los creadores maliciosos que pretenden ser muchos creadores diferentes en el libro de pedidos, permitiendo así al creador malicioso desentrañar la mezcla de receptores que terminan mezclándose solo con el atacante.
Este mecanismo se llama bono de fidelidad , que básicamente consiste en tomar una gran cantidad de bitcoins y bloquear el tiempo. Los creadores que lo hagan pueden firmar y publicar mensajes con esa clave para demostrar el control sobre las monedas bloqueadas por tiempo. Los clientes de los tomadores, si han configurado a su cliente para usar bonos de fidelidad, entonces ponderarán su selección de fabricantes para usarlos para preferir los que tienen mayores cantidades de tiempo de valor encerrados en bonos de fidelidad. Los bonos de fidelidad se ponderan por el cuadrado de cuántas monedas están bloqueadas, es decir, si bloquea cuatro bitcoins, tendrá un peso de 16; cinco se ponderarán como 25; seis se ponderarán como 36, etc.
El razonamiento aquí es que obtienes beneficios compuestos como fabricante con más monedas bloqueas (los clientes que lo toman te eligen con más frecuencia), por lo que si unas pocas Los creadores honestos crean bonos de fidelidad muy grandes, aumentan drásticamente el costo para los fabricantes de Sybiling, que tendrían que replicar esa gran cantidad de bonos de fidelidad para cada una de sus identidades falsas en el libro de pedidos. Es decir, si tres creadores honestos pusieran cada uno 10 bitcoins en bonos de fidelidad, un atacante tendría que gastar 30 bitcoins para tener un 50% de posibilidades de ser elegido para mezclarse, costaría 60 bitcoins tener un 66% de posibilidades de ser elegidos, etc.
Cuanto más honestos sean los creadores que usen bonos de fidelidad, mayor será el costo de los compuestos de ataque de Sybil para los creadores maliciosos.
Cómo podría actualizarse el mecanismo de coordinación de JoinMarket
En el caso de ZeroLink, todos se coordinan a través del servidor coordinador centralizado; esta es una parte explícita del diseño del sistema y del modelo de confianza en términos de confiabilidad. Si el coordinador baja, nadie puede CoinJoin hasta que vuelva a subir.
JoinMarket funciona en un sistema de libro de pedidos para tratar de evitar este punto central de falla, pero como se mencionó anteriormente, actualmente está utilizando IRC como una capa de alojamiento y comunicación para el libro de pedidos. IRC es un posible punto central de falla para JoinMarket, al igual que el servidor coordinador lo es para ZeroLink. Como proyecto construido en torno a la coordinación de CoinJoins de manera descentralizada, a largo plazo, esta dependencia de IRC debe reemplazarse por algo más sólido.
Una de las propuestas más desarrolladas es implementar algún tipo de esquema de servidor de directorio similar al que usa el Proyecto Tor. En la red Tor, los clientes se conectan a un conjunto de servidores ejecutados por contribuyentes de Tor que les envían todos los nodos de la red Tor a través de los cuales pueden construir rutas de cebolla.
La idea con JoinMarket sería tener un conjunto similar de servidores que alimenten a los clientes de todos los fabricantes con ofertas abiertas. Estos servidores tendrían que ser ejecutados por alguien que no sea el fabricante, porque cada fabricante tendría un incentivo para anunciarse solo en su propio servidor de directorio para cobrar más tarifas. También tendría que ser difícil unirse al conjunto de servidores de directorio, de lo contrario, las entidades maliciosas podrían activar una gran cantidad de ellos y Sybil atacaría a todos los usuarios que solo se conectan a servidores maliciosos.
Los bonos de fidelidad podrían abordar el problema de Sybil aquí, así como también crear un desincentivo para que los fabricantes intenten ejecutar servidores de directorio. Bloquear monedas en un bono de fidelidad para un servidor de directorio les dejaría menos monedas para bloquear en un bono de fabricante, lo que podría llevar a que menos clientes receptores las seleccionen para las mezclas.
También hay una prueba de concepto y propuesta de Adam Gibson para integrar c-lightning en JoinMarket para su uso como capa de mensajería. En el contexto de los servidores de directorio, esto podría facilitar un método de monetización para ellos como entidades separadas utilizando Lightning Network. Los servidores de directorio podrían cobrar a los fabricantes pequeñas sumas sobre Lightning para anunciarse en el directorio.
Cómo podría actualizarse el protocolo de coordinación de JoinMarket
Como se mencionó anteriormente, los creadores aprenden los resultados de los receptores durante un solo CoinJoins, por eso existe el modo de vaso, para permitir que los receptores se mezclen a través de varios fabricantes y mitigar eso.
Sin embargo, existe una solución mejor, al menos en el caso de que varios receptores estén hablando con un solo fabricante al mismo tiempo, y puedan coordinar la conversación directa entre ellos en lugar de solo a través del creador. (Si solo hay un receptor hablando con un creador, esto no ayudará porque el creador sabe que todos los resultados que no son suyos pertenecen al receptor). CoinShuffle es un protocolo para hacer efectivamente lo que las credenciales ciegas logran en ZeroLink, para mantener las cosas privadas del coordinador, excepto de una manera descentralizada para un grupo sin un coordinador central.
Imagina que tienes a Alice, Bob y Charlie, que quieren CoinJoin entre sí (ya se han decidido por la denominación de las salidas de CoinJoin), y los tres generan una clave pública temporal tener mensajes cifrados.
Charlie le da su clave pública a Bob, luego Bob le da a Alice su propia clave pública y la de Charlie. Entonces, tenemos una situación en la que Alice tiene las claves públicas de Bob y Charlie, Bob tiene la clave pública de Charlie y Charlie solo tiene la suya.
Alice toma la dirección a la que quiere que se envíe su salida y la encripta a la clave de Charlie, pero luego toma ese mensaje encriptado y lo encripta a la clave pública de Bob, anidando como muñecos rusos. Luego le pasa esto a Bob, quien descifra su capa solo para encontrar un mensaje encriptado para Charlie que no puede abrir. Bob luego toma la dirección a la que quiere que se envíe su salida y la cifra con la clave de Charlie. Le pasa ambos mensajes a Charlie. Charlie ahora descifra ambos mensajes y encuentra las direcciones a las que Alice y Bob quieren que se envíen sus resultados, pero no sabe qué dirección pertenece a quién (y recuerde, ni Alice ni Bob aprendieron las direcciones del otro).
Charlie luego construye y firma el CoinJoin, se lo pasa a Alice y Bob para que lo firmen y lo envía a la red. Todos en este proceso saben que su salida se construyó correctamente, pero no saben quién es el propietario de cuál de las otras dos direcciones. Este proceso puede extenderse para grupos mucho más grandes, y si los receptores pudieran comunicarse entre sí directamente antes de acercarse a los fabricantes, este protocolo podría usarse para proteger la privacidad de los receptores contra los fabricantes individuales sin tener que tirar monedas muchas veces con diferentes partes.
Cómo podría actualizarse la estructura de transacciones de JoinMarket
La mayor similitud entre ZeroLink y JoinMarket es la dependencia de salidas denominadas similares para crear ambigüedad sobre qué entradas se asignan a qué salidas en una transacción.
Si bien JoinMarket usa cantidades arbitrarias en contraposición a las cantidades predefinidas en ZeroLink, en el alcance de una sola transacción CoinJoin, todas las denominaciones mixtas deben ser iguales.
CoinjoinXT es una propuesta de Gibson para eliminar potencialmente la necesidad de depender de eso. estrictamente (esto también podría ser implementado por ZeroLink). La idea básica es aprovechar ECDSA Computación multipartita, o MuSig ahora que Taproot está activado, y Cree una cadena de transacciones firmadas previamente utilizando direcciones de firma múltiple que parezcan direcciones de firma única normales.
Cuando alguien está mirando la cadena de bloques, dos grandes suposiciones que se hacen a menudo son: una, que todas las entradas en una transacción son propiedad de una persona (la gran suposición de que CoinJoins se rompe); y dos, que se ha transferido un control de los medios de pago de los fondos.
Entonces, ¿qué pasa si varias partes colaboran para bloquear todos sus fondos en una dirección multifirma que no parece una? ¿Firmar una larga cadena de transacciones que parecen como si una persona gastara dinero lentamente a lo largo del tiempo, pero en realidad se trata simplemente de retirar dinero y devolverlo a los propietarios originales en pequeños fragmentos?
¿Qué pasaría si algunas de esas salidas de pago fueran en realidad canales Lightning privados entre dos de los participantes de CoinjoinXT para asegurarse de que un observador no pudiera rastrear la cadena de pago y juntar las cantidades en algún momento en el futuro?
Esto podría abrir una puerta completamente nueva en términos de flexibilidad para los tipos de CoinJoins en los que participan las personas y los grados de privacidad que crean. Si un CoinJoin normal está gritando descaradamente en la habitación”¡Me voy a ir y desaparecer ahora!”entonces CoinjoinXT podría ser el equivalente a escabullirse silenciosamente de la fiesta sin ser notado.
El futuro descentralizado
En general, JoinMarket ha sido una herramienta de nicho en el ecosistema a pesar de ser desde 2015, dada la necesidad de ejecutar un nodo completo para usarlo. Realmente no fue hasta que ZeroLink llegó al mercado en forma de Wasabi y Samourai que CoinJoin realmente se convirtió en una herramienta accesible y más ampliamente utilizada y comprendida.
Ambas son herramientas muy valiosas, pero al final del día, son servicios construidos alrededor de empresas centralizadas, aunque servicios sin confianza construidos de una manera en la que es imposible perder dinero interactuando con ellas, pero servicios no obstante. ¿Qué pasa si las empresas cierran? ¿Seguirá avanzando el desarrollo de la misma manera, dado que actualmente está financiado por estas empresas?
Existe absolutamente un lugar para tales herramientas en este espacio, y también tienen aspectos positivos. Esa misma dinámica de financiación que cuestiona la supervivencia de la herramienta si la empresa falla, garantiza muchos recursos detrás de su desarrollo, siempre que la empresa sobreviva. Pero también hay lugar para una herramienta descentralizada que no depende de una sola empresa. El progreso puede ser más lento y los problemas pueden ser más complicados de resolver, pero si tiene éxito, el resultado final será mucho más sólido y adaptable.
No hay nada de malo con los servicios y las empresas en este espacio, pero para cada servicio y empresa donde es posible construir una alternativa descentralizada, esa alternativa debería existir como otra opción. Al igual que el propio Bitcoin, es posible que algún día lo necesites con urgencia.
Esta es una publicación de invitado de Shinobi. Las opiniones expresadas son totalmente propias y no reflejan necesariamente las de BTC Inc o Bitcoin Magazine.