Matt Corallo propuso hace poco más de una semana un BIP para la coordinación de la realización de pagos con Bitcoin. Realizar pagos con bitcoins siempre ha presentado un desafío en términos de coordinación, tanto dentro como fuera de la cadena con protocolos como Lightning, por diferentes razones. Cuando se trata de sistemas digitales como el correo electrónico o sistemas de pago como Paypal, Cashapp, etc., la gente está muy acostumbrada al concepto de un único identificador estático. Si desea enviarle un correo electrónico a John, simplemente envíe un correo electrónico a "john@[insertar dominio]". Si desea enviarle a John algo de dinero en Cashapp, simplemente envíe un pago a @John en Cashapp.
Esta es la experiencia del usuario con la que la gente está familiarizada, y cuando se trata de comportamientos y expectativas arraigados del usuario con respecto a las cosas, es increíblemente difícil impulsarlos a realizar un cambio sustancial o radical en su comportamiento. Si les presenta una herramienta que requiere eso, presenta un gran grado de fricción y lo más probable es que simplemente desincentive a la mayoría de las personas a usar esa herramienta.
Los pagos en cadena se topan con un problema con esta expectativa, no por la incapacidad de tener un identificador estático (una dirección única), sino por las implicaciones de privacidad de publicar una única dirección en cadena y que todas las personas con las que interactúas la usen. para pagarte. Pone todo su historial de pagos y propiedad de monedas a la vista del público de todos. Si rara vez recibe dinero de vez en cuando, es decir, cuando le pagan por su trabajo o cuando paga las cuentas del bar con la gente, no es ninguna carga simplemente abrir su billetera y generar una nueva dirección para recibir. Sin embargo, si recibe dinero con frecuencia, específicamente en los casos en los que no solicita directamente el pago, eso presenta una carga grave.
Es por eso que se crearon herramientas como BTCPay Server, con el fin de reducir la barrera de entrada para que las personas puedan crear la infraestructura necesaria para automatizar la recepción de fondos sin hacer algo ingenuo como publicar una dirección única para que todos los que le paguen la reutilicen. Sin embargo, esto requiere ejecutar un servidor que esté constantemente disponible en línea. Si bien el proyecto ha reducido drásticamente el nivel de comprensión requerido, sigue siendo una carga elevada para un usuario que simplemente quiere poder recibir dinero pasivamente.
Lo mismo ocurre con Lightning, excepto que es peor. Una factura sólo es válida para un pago único. A diferencia de una dirección en cadena, que se puede reutilizar aunque sea una práctica horrible, una factura Lightning no se puede utilizar. Una vez que la factura haya sido pagada o caduque, el nodo Lightning en cuestión negará cualquier intento de pagarla. Esta dinámica llevó a la creación de la especificación LNURL, así como a las direcciones Lightning creadas sobre ella. LNURL es un protocolo para conectarse a un servidor HTTP a través de una IP estática que se puede compartir una vez para obtener una factura Lightning real para pagar desde el servidor. Además de eso, las direcciones Lightning son un esquema de nombres además de LNURL estructurado de manera similar a las direcciones de correo electrónico: John@[dominio del servidor LNURL].
Todas estas soluciones tienen desventajas. El requisito de ejecutar un software adicional (un servidor HTTP) que permanezca en línea todo el tiempo además de su billetera Bitcoin o nodo Lightning; realizar una solicitud al servidor BTCPay/LNURL filtra la dirección IP del remitente al destinatario; confiando en las autoridades de certificación TLS.
Solo usa DNS
Las herramientas del servidor HTTP como LNURL, cuando se combinan con Lightning Address, utilizan dominios para resolver la conexión al servidor HTTP. De manera similar, todos los servidores BTCPay están configurados con dominios en lugar de utilizar direcciones IP sin formato. La idea de Matt es ¿por qué no simplemente eliminar la dependencia de HTTP y utilizar el propio sistema de nombres de dominio?
DNS le permite asociar registros TXT con un nombre de dominio determinado, creando pequeños registros legibles por humanos (o máquinas) que pueden consultarse desde servidores DNS. En combinación con las Extensiones de seguridad del sistema de nombres de dominio (DNSSEC), los registros DNS TXT proporcionan un mecanismo que se puede utilizar para consultar información de pago sin la sobrecarga y la carga de ejecutar un servidor HTTP, además de ofrecer un poco más de flexibilidad y apertura. DNSSEC proporciona una serie de herramientas para firmar criptográficamente entradas DNS, incluidos registros TXT, con las claves DNS inherentes a la estructura jerárquica de DNS. Esto proporciona una garantía de que el registro TXT que está consultando es el registro firmado y distribuido a servidores DNS de nivel inferior desde la clave/servidor raíz local.
Esto llega al beneficio real del DNS como medio para obtener datos de pago: decir adiós al requisito de tener que ejecutar un servidor HTTP. Un registro TXT puede codificar una dirección de Bitcoin en cadena (aunque el BIP recomienda específicamente NO hacer esto si no es capaz de rotar regularmente nuevas direcciones para evitar la reutilización de direcciones), pero lo más importante es que también puede contener una oferta relámpago BOLT 12.
Estos registros se pueden obtener de cualquier servidor DNS, su propio servidor local, su ISP, incluso un servidor público como Google o Cloudflare. A partir de este punto básico, se resuelve una deficiencia de las soluciones basadas en HTTP; Ya no estás filtrando tu dirección IP a la persona a la que estás intentando pagar. Ahora, en el caso de utilizar el DNS de tu ISP o un servidor público como Google o Cloudflare sin una VPN o Tor, les estás revelando tu dirección IP; El BIP claramente fomenta el soporte para la resolución DNS a través de una VPN o Tor específicamente por esta razón.
La combinación de esta propuesta con BOLT 12 elimina la necesidad de ejecutar software auxiliar que presenta un problema de seguridad muy real para los usuarios poco sofisticados, y permite la propiedad de un dominio por sí sola para brindarles a los usuarios todo lo que necesitan para tener un mecanismo para ubicar la información de pago con un simple humano. identificador legible. BOLT 12 no requiere un servidor HTTP, maneja la entrega de facturas real a través de conexiones enrutadas cebolla directamente a través de Lightning Network y admite Ofertas, un identificador estático que se puede usar para encontrar una ruta cebolla a ese nodo Lightning. El problema es que la Oferta está codificada como una enorme cadena aleatoria que parece una factura, lo que la convierte en un horrible identificador legible/utilizable por humanos, excepto mediante el uso de códigos QR o copiar y pegar.
Al almacenar una oferta en un registro DNS TXT, todo lo que un usuario necesita para realizar un pago es el dominio de alguien para escribirlo en su billetera para poder recuperar el registro TXT, recuperar la oferta BOLT 12 y luego realizar el pago. No necesitan alojar ningún servidor ni ejecutar ningún software que no sea su nodo Lightning, el sistema DNS maneja todo por ellos hasta el alojamiento de su BOLT 12. Ofrezca a alguien que los usuarios que quieran pagarles puedan encontrar.
¿Es este un sistema perfectamente sin confianza? No. ¿Es mucho mejor que los sistemas basados en HTTP? Absolutamente. El problema con problemas como este es que existe una cierta expectativa de UX y comportamiento que la mayoría de la gente tiene en cuanto a los sistemas digitales que se supone que funcionan en sus mentes. Sin replicar esa UX, grandes grupos de personas simplemente utilizarán alternativas que cumplan con esa expectativa de UX. Dada esa realidad, al intentar encajar Bitcoin en la caja de esas expectativas de UX, el objetivo del diseño debe ser satisfacer las necesidades de los usuarios con la mínima cantidad de confianza interpuesta, la mínima cantidad de carga impuesta a los usuarios y el mínimo potencial de pérdida de privacidad de nuevas maneras. Creo que BIP de Matt cumple todos esos requisitos en comparación con las soluciones existentes.
Fuente: https://bitcoinmagazine.com/technical/using-dns-to-coordinate-bitcoin-paids