Nostr, abreviatura de "notas y otro contenido transmitido a través de retransmisión", es un nuevo protocolo de comunicación desarrollado por fiatjaf, desarrollador de Lightning Network, en 2021. Los intentos de descentralizar los mercados evolucionaron. A diferencia de otras soluciones de comunicación, la mayoría de las cuales funcionan a través de clientes tontos y servidores inteligentes, Nostr proporciona clientes inteligentes y servidores tontos, lo que aumenta la resistencia de los usuarios a la censura.
**En Nostr, todos los datos se almacenan localmente en el usuario y solo se distribuyen a través de repetidores, no en un servidor central como Twitter. ** En el caso de las redes sociales, Nostr agrega resistencia a la censura ya que los usuarios tienen la propiedad total de sus contenidos y perfiles. A la luz de la reciente controversia en torno a las políticas de censura de Twitter, los usuarios están comenzando a migrar a la solución de comunicaciones federadas Mastodon. En Mastodon, sin embargo, la propiedad de los contenidos y perfiles recae en el operador del servidor de Mastodon en el que el usuario se registra. Si bien un sistema federado como Mastodon ofrece más resistencia a la censura que un servidor central, ya que los usuarios simplemente pueden registrarse en otro servidor si están censurados, ha habido críticas de que Mastodon puede imponer la censura a través del propietario del servidor.
En diciembre de 2022, la comunidad de Nostr recibió una financiación de 14 BTC del fundador de Twitter, Jack Dorsey, lo que atrajo una atención sin precedentes al protocolo. A medida que las aplicaciones basadas en Nostr continuaron creciendo, el cliente móvil Damus ocupó el primer lugar en la categoría de redes sociales de la tienda de aplicaciones iOS de China y, como resultado, fue prohibido. En un esfuerzo por frenar el movimiento #MarchOffTwitter, el CEO de Twitter, Elon Musk, prohibió rápidamente el contenido relacionado con Nostr y prohibió otras plataformas de terceros como Instagram, sin éxito.
Aunque Nostr en sí mismo no es un protocolo de privacidad (de forma predeterminada, los clientes filtran las direcciones IP de los usuarios a los repetidores), el protocolo Nostr podría mejorar potencialmente la privacidad de Bitcoin.
Mejora la privacidad y escalabilidad de BIP47
**BIP47 es una propuesta de mejora de Bitcoin para crear códigos de pago reutilizables para pagos recurrentes mientras se protege la privacidad del usuario. **Si no hay BIP47, para evitar la reutilización de direcciones, los usuarios deben generar nuevas direcciones de forma manual y laboriosa. Cuando un usuario reutiliza una dirección para transacciones, cualquier persona que observe la cadena de bloques puede agregar fácilmente todas las transacciones que pertenecen a esa dirección, formando un gráfico del historial de pagos y el valor neto del usuario. Por lo tanto, en Bitcoin, evitar la reutilización de direcciones es una buena práctica de privacidad y ya está implementada de manera predeterminada en muchas billeteras de Bitcoin. Sin embargo, la generación frecuente de nuevas direcciones puede ser inconveniente cuando un usuario intenta establecer una relación de pago recurrente con otra parte, como entre un comerciante y un cliente.
**A través de BIP47, los clientes pueden generar un conjunto de direcciones de pago para comerciantes. **Si el cliente compra productos mensualmente, el comerciante debe enviar una dirección al cliente todos los meses. Con BIP47, el cliente crea un código de pago dedicado para el comerciante, similar a una clave pública extendida. Esto le permite al cliente generar automáticamente una nueva dirección para el comerciante sin requerir que el comerciante cree una dirección para el cliente.
**BIP47 usa direcciones de notificación, que son monitoreadas por HD Wallet para salidas. **En una transacción de notificación, el comerciante envía al cliente la clave pública ciega y el código de cadena a través del campo OP_RETURN, junto con un secreto compartido para mantener la dirección compartida privada en la cadena de bloques pública. Debido a la arquitectura de la red Bitcoin, este intercambio crea varios problemas. Los dos primeros problemas son económicos: una transacción de notificación consta de 80 bytes, lo que puede resultar costoso para los usuarios cuando las tarifas de transacción en la red de Bitcoin son altas. Además, las transacciones de notificación crean salidas que no se pueden enviar, **inflando el conjunto de UTXO con el tiempo. **Esto aumenta la carga computacional en los nodos de Bitcoin, ya que actualmente necesitan almacenar todo el conjunto de UTXO, es decir, cada salida de Bitcoin que no se usa como una nueva entrada para garantizar que una transacción sea válida.
**La notificación de transacciones crea lo que se conoce como "cambio envenenado". **Cuando un usuario recibe cambio de una transacción de notificación y se lo paga a un tercero, cualquiera que observe la cadena de bloques podrá correlacionar el pago recurrente del usuario con un pago no recurrente, incluso si la dirección no se reutiliza. Una dirección de notificación solo existe una vez por billetera. Si un comerciante desea tener relaciones de pago recurrentes con 10 clientes, cualquier persona que observe la cadena de bloques podrá conocer la base de clientes del comerciante, ya que los 10 clientes deberán crear transacciones de notificación para el comerciante a la misma dirección de notificación.
**En lugar de utilizar transacciones de notificación para intercambiar códigos de pago entre comerciantes y clientes, los códigos de pago se pueden intercambiar a través de Nostr. ** A diferencia de otros métodos de comunicación, Nostr es adecuado para intercambiar códigos de pago BIP47 porque no existe una autoridad central que pueda censurar los intercambios de mensajes. Al mismo tiempo, todos los mensajes directos en Nostr están encriptados de forma predeterminada y no es necesario calcular un secreto compartido. Al usar BIP47 a través de Nostr, los usuarios pueden evitar la creación de una sobrecarga para el conjunto de UTXO con salidas no gastables, desvincular los gastos dobles de los gastos no duplicados al evitar cambios tóxicos y la reutilización de las direcciones de notificación, y al evitar exponer la base de clientes para eliminar la liberación del base de clientes
Nota: Al implementar UTreeXO, la necesidad de que los nodos de Bitcoin almacenen todo el conjunto actual de UTXO puede eliminarse en el futuro. UTreeXO transfiere la carga de probar si una transacción utiliza un UTXO válido al propietario del UTXO, lo que reduce los requisitos de almacenamiento de unos pocos GB a unos pocos KB.
Nostr Pay-To-EndPoint
** En Bitcoin, el servicio de análisis de blockchain asigna transacciones a identidades utilizando una regla heurística de "propiedad de entrada común". **Según esta regla, las transacciones que contienen diferentes claves públicas como entrada se clasifican como pertenecientes a la misma persona. El protocolo Bitcoin también es susceptible al análisis de suma de subconjuntos debido a su arquitectura basada en UTXO mediante la cual se correlacionan las entradas y salidas de las transacciones. En el análisis de suma de subconjuntos, un atacante puede calcular la probabilidad de que una entrada y una salida pertenezcan a la misma entidad, incluso si se utilizan diferentes claves públicas como entradas para una transacción. Por ejemplo, si una transacción tiene las entradas 1, 4, 7, 23 y 6 y las salidas 5 y 36, se puede inferir que las entradas 1 y 4 y las entradas 7, 23 y 6 pertenecen a la misma entidad.
Fuente: Knowledge Discovery in Cryptocurrency Trading: A Survey, 2021 de Xia Fan Lu y Xin-Jiang Jang
**Pay-to-EndPoint (P2EP) es un rediseño protegido por privacidad de Pay-to-IP (P2IP) de Satoshi Nakamoto, codificado en el cliente Bitcoin original. **Una forma de transacción P2EP es la transacción PayJoin, diseñada para romper la regla heurística de propiedad conjunta de entrada. En una transacción PayJoin, tanto el remitente como el receptor proporcionan entradas para romper la heurística de entrada común. Con PayJoins, los usuarios pueden intercambiar información sobre UTXO para utilizarlos como entradas para construir transacciones de Bitcoin parcialmente firmadas (PSBT) a través de cualquier canal de comunicación (como Tor Onion como punto final). Una vez que las dos partes acuerdan los términos y firman la transacción, la transacción de PayJoin se parece a cualquier otra transacción de Bitcoin en la cadena de bloques. Dado que las partes involucradas desempeñan los roles de remitente y receptor, las transacciones de PayJoin no solo rompen la regla heurística de copropiedad, sino que también rompen el análisis de suma de subconjuntos: las partes pueden proporcionar entradas de 3 y 5, y la salida generada por la transacción para 6 y 2.
Fuente: Pay To EndPoint de Adam Fiscor, 2018
Problema: la coordinación de las transacciones de PayJoin es bastante compleja, ya que los participantes deben estar en línea al mismo tiempo, ya sea que utilicen dominios de red clara o terminales Tor Onion. Si un usuario inicia una transacción P2EP, por ejemplo, apagando su computadora o perdiendo su conexión de red, la transacción no puede comunicarse. En Nostr, la comunicación es asíncrona: los usuarios obtienen información del relé después de que se restablece la conexión a la red. Las transacciones P2EP se pueden coordinar más fácilmente utilizando las teclas Nostr en lugar de Tor Onion como punto final para las transacciones P2EP.
Otra implementación de P2EP es la controvertida LNURL. Con LNURL, en lugar de generar tediosamente nuevas facturas para cada transacción, los usuarios pueden recibir un punto final estático que apunta a un servidor web para generar automáticamente nuevas facturas. Sin embargo, debido a que los servidores web dependen del Servicio de nombres de dominio (DNS) global, los usuarios que usan LNURL inevitablemente revelan sus identidades a los proveedores de alojamiento y, si no se toman las precauciones adecuadas, sus direcciones IP a los beneficiarios. La adopción generalizada de LNURL será perjudicial para el anonimato de Lightning Network**. En lugar de usar un servidor web como punto final para LNURL, los usuarios pueden usar las claves Nostr como punto final para las transacciones LNURL para ocultar sus identidades. **
Nostr para CoinJoin
Si bien PayJoin rompe muy bien la heurística de copropiedad, la división en subconjuntos y el análisis, PayJoin no proporciona al remitente y al receptor protección de la privacidad de las partes colaboradoras. PayJoin es esencialmente un CoinJoin de dos partes, limitado a dos participantes, lo que significa que tanto el remitente como el receptor conocen sus propias entradas y salidas, lo que hace que las entradas y salidas de sus socios sean identificables. A menos que se utilice una transacción CoinJoined para facilitar PayJoin, los usuarios corren el riesgo de revelar los saldos de sus billeteras y las transacciones pasadas y futuras a los socios de PayJoin.
En un sistema de certificado de monto anónimo como el Protocolo de coordinación CoinJoin de Wasabi Wallet (WabiSabi), la clave Nostr puede servir como punto final de comunicación para coordinar las transacciones CoinJoin. Esto permite que el remitente y el receptor de una transacción de CoinJoin intercambien las credenciales requeridas para participar en una ronda de CoinJoin, lo que permite una forma de pago discreta en CoinJoin. Al usar la clave Nostr como punto final en CoinJoins, las partes colaboradoras permanecen ocultas de la multitud, sin conocer los saldos y transacciones de su contraparte. Al mismo tiempo, el uso de claves Nostr como punto final de las transacciones de CoinJoin ayuda a los usuarios de PayJoin a ahorrar tarifas al realizar pagos directamente en CoinJoin en lugar de facilitar los pagos a través de CoinJoin.
Otro uso de Nostr en CoinJoins es el descubrimiento de coordinadores. Si bien la mayoría de los coordinadores de CoinJoin operan detrás de Tor para enmascarar las identidades de los participantes de CoinJoin, los usuarios actualmente no pueden descubrir fácilmente nuevos coordinadores, excepto en JoinMarket (un mercado de CoinJoin para usuarios de CoinJoin más avanzados). Si bien los usuarios de CoinJoin pueden agregar coordinadores personalizados a Wasabi Wallet (tan fácil como intercambiar URL en segundo plano), debido a la falta de una plataforma de publicación, no hay forma de automatizar el proceso de actualización de coordinadores. Por lo tanto, para descubrir nuevos coordinadores, los usuarios deben buscar manualmente en las redes sociales y foros (como Reddit o Twitter) para agregar coordinadores. Sin embargo, publicar un servicio de Coordinador a través de redes sociales o foros puede representar un riesgo para el Proveedor de coordinación, según las políticas aplicadas al servicio, ya que algunas páginas pueden cerrarse fácilmente.
Si Tor es un servidor de retransmisión anónimo, un protocolo que facilita el envío y la recepción anónimos de mensajes entre pares, Nostr puede actuar como un tablón de anuncios anónimo. Los coordinadores de CoinJoin pueden publicar sus servicios a través del tipo de evento Nostr, y las billeteras CoinJoin pueden habilitar la obtención automática de información de estos servidores de retransmisión y mostrarla en sus clientes. Los servidores coordinadores de transmisión de Nostr, como a través del complemento CoinJoin de servidores de BTCPay y el enfoque propuesto en el software CoinJoin basado en Lightning Network Vortex, pueden eliminar la necesidad de buscar y agregar coordinadores CoinJoin manualmente en los clientes CoinJoin, descentralizando aún más el panorama de coordinación CoinJoin.
Omita los requisitos de IP a través de NOSTR
Como se mencionó anteriormente, el concepto original del protocolo **Nostr era implementar un mercado completamente descentralizado llamado Diagon Alley. **Con el desarrollo del protocolo Nostr, Diagon Alley se convierte en NostrMarkets, una extensión de LNbits: un mercado habilitado para Nostr que permite de forma nativa a los comerciantes y clientes operar e interactuar con tiendas en línea a través de relevos. En NostrMarkets, los clientes pueden suscribirse a la clave pública del comerciante y obtener productos del relé en lugar de visitar el sitio web del comerciante a través de la tienda en línea. Esto aumenta la resistencia a la censura de la tienda en línea porque en lugar de depender de un sitio web censurable, la tienda del comerciante está alojada en todos los relés con los que se comunica. Incluso si se incauta el servidor del comerciante, la tienda se puede configurar fácilmente en diferentes ubicaciones, ya que todos los productos se almacenan en el relé de la red Nostr. NostrMarkets maneja la coordinación de pedidos y pagos a través de mensajes directos de Nostr encriptados, mientras que los pagos se realizan a través de Lightning Network.
Además de ser resistente a la censura, la extensión NostrMarkets de LNbits permite un mercado completamente anónimo. Los comerciantes y los clientes no divulgan sus direcciones IP al mundo, sino solo al relé al que se conectan, y esto se puede resolver fácilmente ejecutando el cliente o la tienda detrás de Tor. La ventaja de ejecutar la tienda completamente detrás de Tor es que, si bien solo se puede acceder a la tienda a través del navegador Tor y las páginas web .onion, NostrMarkets puede ejecutarse en cualquier navegador web o teléfono inteligente, lo que mejora la experiencia del usuario de comunicación cliente-servidor que preserva la privacidad. Dado que los pagos se negocian a través de Mensajes directos de Nostr encriptados y se implementan a través de Lightning Network, los pagos en NostrMarkets seguirán siendo relativamente privados siempre que el nodo Lightning de la tienda se ejecute detrás de Tor, ya que los Mensajes directos de coordinación de pagos no se pueden comparar con otros Mensajes directos en Nostr. .
Otra forma de eludir el requisito de la dirección IP en la comunicación servidor-cliente es NOSTREST. REST significa "Transferencia de estado representacional", que es parte de la arquitectura de software de la Web mundial para la comunicación entre servidores y clientes a través de solicitudes GET, POST, PUT, DELETE y PATCH. Sin embargo, cuando un cliente envía una solicitud REST a un servidor, la dirección IP queda expuesta, lo que podría revelar información de identificación personal. En GitHub, __escapeee__ propuso un puente API REST construido en Nostr llamado NOSTREST. Al usar las claves Nostr sin un encabezado de autenticación, los usuarios y los operadores del servidor no necesitan conocer las direcciones IP de los demás. Por lo tanto, la implementación de NOSTREST puede mejorar la privacidad de las aplicaciones de Bitcoin que utilizan REST, ya que el servidor no requiere la dirección IP del cliente.
Un ejemplo de esto podría ser ejecutar una menta de efectivo electrónico Chaumian de custodia, un sistema de cupones anónimos para cantidades. En una casa de moneda electrónica, el operador de la casa de moneda no conoce los saldos de sus usuarios ni el valor del intercambio. Sin embargo, debido a la arquitectura REST actual, a menos que se ejecute detrás de Tor de forma predeterminada (como en el sistema de efectivo electrónico Cashu), aprende la dirección IP del usuario. Sin embargo, implementar y administrar el soporte de Tor es engorroso. A través del puente NOSTREST, el proyecto puede proteger fácilmente la privacidad de los usuarios. Al ejecutar e-cash mint detrás de Tor y usar NOSTREST para comunicarse entre el servidor y el cliente, se puede lograr una comunicación asíncrona, mientras que el operador del servidor y el usuario solo conocen la clave pública del otro, eliminando la necesidad de identificación por riesgo de IP.
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
La paradoja de la privacidad de Nostr y las mejoras en la privacidad de Bitcoin
Autor: L0la L33tz, Compilador: DoraFactory
Nostr, abreviatura de "notas y otro contenido transmitido a través de retransmisión", es un nuevo protocolo de comunicación desarrollado por fiatjaf, desarrollador de Lightning Network, en 2021. Los intentos de descentralizar los mercados evolucionaron. A diferencia de otras soluciones de comunicación, la mayoría de las cuales funcionan a través de clientes tontos y servidores inteligentes, Nostr proporciona clientes inteligentes y servidores tontos, lo que aumenta la resistencia de los usuarios a la censura.
**En Nostr, todos los datos se almacenan localmente en el usuario y solo se distribuyen a través de repetidores, no en un servidor central como Twitter. ** En el caso de las redes sociales, Nostr agrega resistencia a la censura ya que los usuarios tienen la propiedad total de sus contenidos y perfiles. A la luz de la reciente controversia en torno a las políticas de censura de Twitter, los usuarios están comenzando a migrar a la solución de comunicaciones federadas Mastodon. En Mastodon, sin embargo, la propiedad de los contenidos y perfiles recae en el operador del servidor de Mastodon en el que el usuario se registra. Si bien un sistema federado como Mastodon ofrece más resistencia a la censura que un servidor central, ya que los usuarios simplemente pueden registrarse en otro servidor si están censurados, ha habido críticas de que Mastodon puede imponer la censura a través del propietario del servidor.
En diciembre de 2022, la comunidad de Nostr recibió una financiación de 14 BTC del fundador de Twitter, Jack Dorsey, lo que atrajo una atención sin precedentes al protocolo. A medida que las aplicaciones basadas en Nostr continuaron creciendo, el cliente móvil Damus ocupó el primer lugar en la categoría de redes sociales de la tienda de aplicaciones iOS de China y, como resultado, fue prohibido. En un esfuerzo por frenar el movimiento #MarchOffTwitter, el CEO de Twitter, Elon Musk, prohibió rápidamente el contenido relacionado con Nostr y prohibió otras plataformas de terceros como Instagram, sin éxito.
Aunque Nostr en sí mismo no es un protocolo de privacidad (de forma predeterminada, los clientes filtran las direcciones IP de los usuarios a los repetidores), el protocolo Nostr podría mejorar potencialmente la privacidad de Bitcoin.
Mejora la privacidad y escalabilidad de BIP47
**BIP47 es una propuesta de mejora de Bitcoin para crear códigos de pago reutilizables para pagos recurrentes mientras se protege la privacidad del usuario. **Si no hay BIP47, para evitar la reutilización de direcciones, los usuarios deben generar nuevas direcciones de forma manual y laboriosa. Cuando un usuario reutiliza una dirección para transacciones, cualquier persona que observe la cadena de bloques puede agregar fácilmente todas las transacciones que pertenecen a esa dirección, formando un gráfico del historial de pagos y el valor neto del usuario. Por lo tanto, en Bitcoin, evitar la reutilización de direcciones es una buena práctica de privacidad y ya está implementada de manera predeterminada en muchas billeteras de Bitcoin. Sin embargo, la generación frecuente de nuevas direcciones puede ser inconveniente cuando un usuario intenta establecer una relación de pago recurrente con otra parte, como entre un comerciante y un cliente.
**A través de BIP47, los clientes pueden generar un conjunto de direcciones de pago para comerciantes. **Si el cliente compra productos mensualmente, el comerciante debe enviar una dirección al cliente todos los meses. Con BIP47, el cliente crea un código de pago dedicado para el comerciante, similar a una clave pública extendida. Esto le permite al cliente generar automáticamente una nueva dirección para el comerciante sin requerir que el comerciante cree una dirección para el cliente.
**BIP47 usa direcciones de notificación, que son monitoreadas por HD Wallet para salidas. **En una transacción de notificación, el comerciante envía al cliente la clave pública ciega y el código de cadena a través del campo OP_RETURN, junto con un secreto compartido para mantener la dirección compartida privada en la cadena de bloques pública. Debido a la arquitectura de la red Bitcoin, este intercambio crea varios problemas. Los dos primeros problemas son económicos: una transacción de notificación consta de 80 bytes, lo que puede resultar costoso para los usuarios cuando las tarifas de transacción en la red de Bitcoin son altas. Además, las transacciones de notificación crean salidas que no se pueden enviar, **inflando el conjunto de UTXO con el tiempo. **Esto aumenta la carga computacional en los nodos de Bitcoin, ya que actualmente necesitan almacenar todo el conjunto de UTXO, es decir, cada salida de Bitcoin que no se usa como una nueva entrada para garantizar que una transacción sea válida.
**La notificación de transacciones crea lo que se conoce como "cambio envenenado". **Cuando un usuario recibe cambio de una transacción de notificación y se lo paga a un tercero, cualquiera que observe la cadena de bloques podrá correlacionar el pago recurrente del usuario con un pago no recurrente, incluso si la dirección no se reutiliza. Una dirección de notificación solo existe una vez por billetera. Si un comerciante desea tener relaciones de pago recurrentes con 10 clientes, cualquier persona que observe la cadena de bloques podrá conocer la base de clientes del comerciante, ya que los 10 clientes deberán crear transacciones de notificación para el comerciante a la misma dirección de notificación.
**En lugar de utilizar transacciones de notificación para intercambiar códigos de pago entre comerciantes y clientes, los códigos de pago se pueden intercambiar a través de Nostr. ** A diferencia de otros métodos de comunicación, Nostr es adecuado para intercambiar códigos de pago BIP47 porque no existe una autoridad central que pueda censurar los intercambios de mensajes. Al mismo tiempo, todos los mensajes directos en Nostr están encriptados de forma predeterminada y no es necesario calcular un secreto compartido. Al usar BIP47 a través de Nostr, los usuarios pueden evitar la creación de una sobrecarga para el conjunto de UTXO con salidas no gastables, desvincular los gastos dobles de los gastos no duplicados al evitar cambios tóxicos y la reutilización de las direcciones de notificación, y al evitar exponer la base de clientes para eliminar la liberación del base de clientes
Nota: Al implementar UTreeXO, la necesidad de que los nodos de Bitcoin almacenen todo el conjunto actual de UTXO puede eliminarse en el futuro. UTreeXO transfiere la carga de probar si una transacción utiliza un UTXO válido al propietario del UTXO, lo que reduce los requisitos de almacenamiento de unos pocos GB a unos pocos KB.
Nostr Pay-To-EndPoint
** En Bitcoin, el servicio de análisis de blockchain asigna transacciones a identidades utilizando una regla heurística de "propiedad de entrada común". **Según esta regla, las transacciones que contienen diferentes claves públicas como entrada se clasifican como pertenecientes a la misma persona. El protocolo Bitcoin también es susceptible al análisis de suma de subconjuntos debido a su arquitectura basada en UTXO mediante la cual se correlacionan las entradas y salidas de las transacciones. En el análisis de suma de subconjuntos, un atacante puede calcular la probabilidad de que una entrada y una salida pertenezcan a la misma entidad, incluso si se utilizan diferentes claves públicas como entradas para una transacción. Por ejemplo, si una transacción tiene las entradas 1, 4, 7, 23 y 6 y las salidas 5 y 36, se puede inferir que las entradas 1 y 4 y las entradas 7, 23 y 6 pertenecen a la misma entidad.
Fuente: Knowledge Discovery in Cryptocurrency Trading: A Survey, 2021 de Xia Fan Lu y Xin-Jiang Jang
**Pay-to-EndPoint (P2EP) es un rediseño protegido por privacidad de Pay-to-IP (P2IP) de Satoshi Nakamoto, codificado en el cliente Bitcoin original. **Una forma de transacción P2EP es la transacción PayJoin, diseñada para romper la regla heurística de propiedad conjunta de entrada. En una transacción PayJoin, tanto el remitente como el receptor proporcionan entradas para romper la heurística de entrada común. Con PayJoins, los usuarios pueden intercambiar información sobre UTXO para utilizarlos como entradas para construir transacciones de Bitcoin parcialmente firmadas (PSBT) a través de cualquier canal de comunicación (como Tor Onion como punto final). Una vez que las dos partes acuerdan los términos y firman la transacción, la transacción de PayJoin se parece a cualquier otra transacción de Bitcoin en la cadena de bloques. Dado que las partes involucradas desempeñan los roles de remitente y receptor, las transacciones de PayJoin no solo rompen la regla heurística de copropiedad, sino que también rompen el análisis de suma de subconjuntos: las partes pueden proporcionar entradas de 3 y 5, y la salida generada por la transacción para 6 y 2.
Fuente: Pay To EndPoint de Adam Fiscor, 2018
Problema: la coordinación de las transacciones de PayJoin es bastante compleja, ya que los participantes deben estar en línea al mismo tiempo, ya sea que utilicen dominios de red clara o terminales Tor Onion. Si un usuario inicia una transacción P2EP, por ejemplo, apagando su computadora o perdiendo su conexión de red, la transacción no puede comunicarse. En Nostr, la comunicación es asíncrona: los usuarios obtienen información del relé después de que se restablece la conexión a la red. Las transacciones P2EP se pueden coordinar más fácilmente utilizando las teclas Nostr en lugar de Tor Onion como punto final para las transacciones P2EP.
Otra implementación de P2EP es la controvertida LNURL. Con LNURL, en lugar de generar tediosamente nuevas facturas para cada transacción, los usuarios pueden recibir un punto final estático que apunta a un servidor web para generar automáticamente nuevas facturas. Sin embargo, debido a que los servidores web dependen del Servicio de nombres de dominio (DNS) global, los usuarios que usan LNURL inevitablemente revelan sus identidades a los proveedores de alojamiento y, si no se toman las precauciones adecuadas, sus direcciones IP a los beneficiarios. La adopción generalizada de LNURL será perjudicial para el anonimato de Lightning Network**. En lugar de usar un servidor web como punto final para LNURL, los usuarios pueden usar las claves Nostr como punto final para las transacciones LNURL para ocultar sus identidades. **
Nostr para CoinJoin
Si bien PayJoin rompe muy bien la heurística de copropiedad, la división en subconjuntos y el análisis, PayJoin no proporciona al remitente y al receptor protección de la privacidad de las partes colaboradoras. PayJoin es esencialmente un CoinJoin de dos partes, limitado a dos participantes, lo que significa que tanto el remitente como el receptor conocen sus propias entradas y salidas, lo que hace que las entradas y salidas de sus socios sean identificables. A menos que se utilice una transacción CoinJoined para facilitar PayJoin, los usuarios corren el riesgo de revelar los saldos de sus billeteras y las transacciones pasadas y futuras a los socios de PayJoin.
En un sistema de certificado de monto anónimo como el Protocolo de coordinación CoinJoin de Wasabi Wallet (WabiSabi), la clave Nostr puede servir como punto final de comunicación para coordinar las transacciones CoinJoin. Esto permite que el remitente y el receptor de una transacción de CoinJoin intercambien las credenciales requeridas para participar en una ronda de CoinJoin, lo que permite una forma de pago discreta en CoinJoin. Al usar la clave Nostr como punto final en CoinJoins, las partes colaboradoras permanecen ocultas de la multitud, sin conocer los saldos y transacciones de su contraparte. Al mismo tiempo, el uso de claves Nostr como punto final de las transacciones de CoinJoin ayuda a los usuarios de PayJoin a ahorrar tarifas al realizar pagos directamente en CoinJoin en lugar de facilitar los pagos a través de CoinJoin.
Otro uso de Nostr en CoinJoins es el descubrimiento de coordinadores. Si bien la mayoría de los coordinadores de CoinJoin operan detrás de Tor para enmascarar las identidades de los participantes de CoinJoin, los usuarios actualmente no pueden descubrir fácilmente nuevos coordinadores, excepto en JoinMarket (un mercado de CoinJoin para usuarios de CoinJoin más avanzados). Si bien los usuarios de CoinJoin pueden agregar coordinadores personalizados a Wasabi Wallet (tan fácil como intercambiar URL en segundo plano), debido a la falta de una plataforma de publicación, no hay forma de automatizar el proceso de actualización de coordinadores. Por lo tanto, para descubrir nuevos coordinadores, los usuarios deben buscar manualmente en las redes sociales y foros (como Reddit o Twitter) para agregar coordinadores. Sin embargo, publicar un servicio de Coordinador a través de redes sociales o foros puede representar un riesgo para el Proveedor de coordinación, según las políticas aplicadas al servicio, ya que algunas páginas pueden cerrarse fácilmente.
Si Tor es un servidor de retransmisión anónimo, un protocolo que facilita el envío y la recepción anónimos de mensajes entre pares, Nostr puede actuar como un tablón de anuncios anónimo. Los coordinadores de CoinJoin pueden publicar sus servicios a través del tipo de evento Nostr, y las billeteras CoinJoin pueden habilitar la obtención automática de información de estos servidores de retransmisión y mostrarla en sus clientes. Los servidores coordinadores de transmisión de Nostr, como a través del complemento CoinJoin de servidores de BTCPay y el enfoque propuesto en el software CoinJoin basado en Lightning Network Vortex, pueden eliminar la necesidad de buscar y agregar coordinadores CoinJoin manualmente en los clientes CoinJoin, descentralizando aún más el panorama de coordinación CoinJoin.
Omita los requisitos de IP a través de NOSTR
Como se mencionó anteriormente, el concepto original del protocolo **Nostr era implementar un mercado completamente descentralizado llamado Diagon Alley. **Con el desarrollo del protocolo Nostr, Diagon Alley se convierte en NostrMarkets, una extensión de LNbits: un mercado habilitado para Nostr que permite de forma nativa a los comerciantes y clientes operar e interactuar con tiendas en línea a través de relevos. En NostrMarkets, los clientes pueden suscribirse a la clave pública del comerciante y obtener productos del relé en lugar de visitar el sitio web del comerciante a través de la tienda en línea. Esto aumenta la resistencia a la censura de la tienda en línea porque en lugar de depender de un sitio web censurable, la tienda del comerciante está alojada en todos los relés con los que se comunica. Incluso si se incauta el servidor del comerciante, la tienda se puede configurar fácilmente en diferentes ubicaciones, ya que todos los productos se almacenan en el relé de la red Nostr. NostrMarkets maneja la coordinación de pedidos y pagos a través de mensajes directos de Nostr encriptados, mientras que los pagos se realizan a través de Lightning Network.
Además de ser resistente a la censura, la extensión NostrMarkets de LNbits permite un mercado completamente anónimo. Los comerciantes y los clientes no divulgan sus direcciones IP al mundo, sino solo al relé al que se conectan, y esto se puede resolver fácilmente ejecutando el cliente o la tienda detrás de Tor. La ventaja de ejecutar la tienda completamente detrás de Tor es que, si bien solo se puede acceder a la tienda a través del navegador Tor y las páginas web .onion, NostrMarkets puede ejecutarse en cualquier navegador web o teléfono inteligente, lo que mejora la experiencia del usuario de comunicación cliente-servidor que preserva la privacidad. Dado que los pagos se negocian a través de Mensajes directos de Nostr encriptados y se implementan a través de Lightning Network, los pagos en NostrMarkets seguirán siendo relativamente privados siempre que el nodo Lightning de la tienda se ejecute detrás de Tor, ya que los Mensajes directos de coordinación de pagos no se pueden comparar con otros Mensajes directos en Nostr. .
Otra forma de eludir el requisito de la dirección IP en la comunicación servidor-cliente es NOSTREST. REST significa "Transferencia de estado representacional", que es parte de la arquitectura de software de la Web mundial para la comunicación entre servidores y clientes a través de solicitudes GET, POST, PUT, DELETE y PATCH. Sin embargo, cuando un cliente envía una solicitud REST a un servidor, la dirección IP queda expuesta, lo que podría revelar información de identificación personal. En GitHub, __escapeee__ propuso un puente API REST construido en Nostr llamado NOSTREST. Al usar las claves Nostr sin un encabezado de autenticación, los usuarios y los operadores del servidor no necesitan conocer las direcciones IP de los demás. Por lo tanto, la implementación de NOSTREST puede mejorar la privacidad de las aplicaciones de Bitcoin que utilizan REST, ya que el servidor no requiere la dirección IP del cliente.
Un ejemplo de esto podría ser ejecutar una menta de efectivo electrónico Chaumian de custodia, un sistema de cupones anónimos para cantidades. En una casa de moneda electrónica, el operador de la casa de moneda no conoce los saldos de sus usuarios ni el valor del intercambio. Sin embargo, debido a la arquitectura REST actual, a menos que se ejecute detrás de Tor de forma predeterminada (como en el sistema de efectivo electrónico Cashu), aprende la dirección IP del usuario. Sin embargo, implementar y administrar el soporte de Tor es engorroso. A través del puente NOSTREST, el proyecto puede proteger fácilmente la privacidad de los usuarios. Al ejecutar e-cash mint detrás de Tor y usar NOSTREST para comunicarse entre el servidor y el cliente, se puede lograr una comunicación asíncrona, mientras que el operador del servidor y el usuario solo conocen la clave pública del otro, eliminando la necesidad de identificación por riesgo de IP.