Lightning Address

Anna quiere recibir aportaciones para su pódcast. En lugar de enviar una nueva factura larga a cada oyente, publica una Lightning Address. El ejemplo anna@example.com resulta fácil de recordar: antes de la arroba aparece el destinatario dentro del servicio y después, el dominio que responde a la cartera. El parecido con el correo es intencionado, pero el dinero no viaja por correo electrónico. Tener un correo no significa tener una Lightning Address, ni el nombre demuestra por sí solo quién es su dueño. Compruébalo con el creador al que quieres apoyar. [1] [6]

El oyente introduce el nombre en una cartera compatible. Esta obtiene del servicio una descripción y el intervalo de importes permitido. Una vez que el usuario comprueba el dominio, la descripción y el importe elegido, solicita una factura BOLT 11 concreta y verifica su importe antes de pagar. Obtener la factura todavía no es pagar. El procedimiento se llama LNURL-pay. El servicio facilita un callback, la dirección para solicitar la factura, metadata con la descripción y los límites minSendable y maxSendable. amount se expresa en msat, milésimas de satoshi: 1000 msat = 1 sat. La factura llega en el campo pr. [2] [3]

Anna puede usar un servicio que gestione su cartera o conectar el nombre a su propio nodo Lightning, el programa que tramita sus pagos. La dirección tiene el mismo aspecto en ambos casos. Un endpoint web, el punto donde el servidor responde a la cartera, puede solicitar una factura al nodo mediante un servidor puente. Ese intermediario no es necesariamente custodio: depende de la configuración y los permisos. Aun así, controlar las respuestas importa; quien pueda sustituirlas puede presentar otra factura al pagador. Un dominio propio no garantiza self-custody, es decir, el control de las propias claves. [3] [4]

Una cartera puede enviar a una Lightning Address sin proporcionar al usuario su propia dirección de recepción. Recibir también exige un servicio web disponible, emitir la factura y poder aceptar el pago en Lightning Network. Los pagos pasan por canales: conexiones entre participantes en las que cambia el reparto de fondos entre ambos lados. Para ello hace falta Inbound Liquidity: fondos al otro lado de los canales que pueden pasar al destinatario durante el pago. Un nombre memorable no crea esa liquidez. Si la dirección se carga pero el pago falla, el problema no tiene por qué estar en el nombre. Distingue entre respuesta del sitio, factura obtenida y recepción confirmada del dinero. [3] [5]

Con un dominio propio puedes cambiar el servidor que atiende los pagos y mantener el nombre que conocen los oyentes. La documentación de BTCPay muestra cómo redirigir el endpoint mediante HTTP 301: la petición web va a otro lugar, sin mover monedas. Quizá no tengas ese control sobre un nombre en un dominio ajeno. La Seed Phrase, las palabras de recuperación de la cartera, no garantiza por sí sola que puedas recuperar el acceso a la cuenta del servicio. Tampoco respalda la administración del dominio ni la configuración de DNS, el sistema que indica a dónde lleva ese dominio. Tras el cambio, comprueba la factura correcta y un pago de prueba realmente recibido, no solo que se abra la dirección. Tus contactos no conocerán automáticamente un nombre nuevo. [5] [3]

LUD-16 describe la conversión del nombre en una petición web GET, una solicitud de datos. La cartera consulta el dominio en /.well-known/lnurlp/username y sustituye username por el nombre de usuario. En la web habitual utiliza HTTPS; en un dominio onion, HTTP. La respuesta payRequest continúa con el procedimiento LUD-06. HTTPS protege la conexión contra alteraciones durante el tránsito, pero no demuestra que el servicio sea honrado. Este procesa las consultas y conoce al destinatario de la factura, por lo que el nombre legible no aporta anonimato por sí solo. [1] [2]

LUD-16 admite en el nombre de usuario las minúsculas a-z, los dígitos 0-9 y -_.; el correo corriente permite más caracteres. La abreviatura opcional @domain identifica al destinatario predeterminado _@domain en la ruta /.well-known/lnurlp/_, pero la cartera o el servicio pueden no admitirla. Tampoco +tag es universal. Si el servicio lo admite, puede distinguir el propósito de una aportación e incluirlo como text/tag. No es una nueva clave privada ni una garantía de privacidad. Para el uso cotidiano, copia el nombre exacto publicado por el destinatario. [1]

Los metadatos son información complementaria que cartera y servicio intercambian en el formato estructurado JSON. En LNURL-pay incluyen text/plain, una breve descripción del pago. LUD-16 añade text/identifier para vincularlo al nombre, o text/email si ese nombre corresponde a un correo real. Así la cartera puede mostrar a qué se refiere el pago. Siguen siendo datos proporcionados por el servicio, no una verificación independiente de la identidad civil de Anna. Comprobar la dirección original, el dominio y el importe sigue siendo parte de pagar con cuidado. [1] [2]