BOLT12, LNURL y relámpago de Bitcoin

¿Qué es el BOLT 12? Bueno, son muchas características diferentes y partes móviles juntas para lograr varias cosas diferentes: códigos QR estáticos, facturas modulares, privacidad para la persona que recibe el pago.

Pero, ¿cuál es el paquete total? Es una forma de tener un solo código QR, una «oferta», que le permite extraer facturas de un nodo de una manera que preserva la privacidad, mientras sigue haciendo cosas como pedirle a un nodo remoto que pague su factura, puede solicitar.

Ahora, cualquiera que esté familiarizado con LNURL ya debería estar pensando: «Eso se parece mucho a LNURL.» Pero para aquellos de ustedes que no saben qué es LNURL o cómo funciona, aquí hay un desglose rápido.

¿Qué es LNURL?

LNURL es una pila de protocolos simples para coordinar la información necesaria para los pagos a través de Lightning Network utilizando HTTP. La lista completa de partes del protocolo LNURL se puede encontrar aquí, pero solo cubriré algunos usos principales que se superponen con BOLT 12.

Tres piezas centrales del protocolo LNURL son un esquema de autenticación donde se puede usar una clave pública para iniciar sesión en un servicio, un esquema de solicitud de factura donde una billetera puede hacer ping a un servidor a través de un código QR estático y recuperar una factura, y un esquema de solicitud de Pago donde una billetera puede hacer ping a un servidor y solicitar que el servidor pague una factura proporcionada por la billetera. Las facturas relámpago son mucho más largas que las direcciones de bitcoin en cadena, el pago en sí ya es un proceso interactivo que requiere que ambas partes estén en línea, por lo que tiene sentido coordinar los detalles de pago de forma interactiva a través de una conexión de red.

El protocolo de autenticación es efectivamente solo el servidor que proporciona un número generado aleatoriamente que firma la billetera del usuario con una clave recién generada. Una vez que el servidor recibe el valor aleatorio firmado, almacena la clave asociada para usarla en futuros inicios de sesión.

La función de solicitud de factura es una forma de proporcionar a un usuario información sobre un pago que desea realizar en un formato que no es una factura. Esto incluye una descripción del pago, el monto mínimo y máximo que el servicio espera pagar y una URL para la billetera desde la cual solicitar una factura real. A partir de aquí, la billetera muestra esta información al usuario para que pueda establecer un monto final y solicitar una factura. Después de que se envía la solicitud de factura y se recibe una del servidor, la billetera verifica que los montos coincidan con los establecidos por el usuario y paga la factura.

La solicitud de retiro funciona haciendo ping al servicio y brindando como respuesta una descripción, una URL para enviar una factura, una cadena de caracteres aleatoria (o determinista para vincularla a una cuenta o usuario) y un monto mínimo y máximo que se retirará Puede ser obtenido. Después de ingresar el valor apropiado, la billetera envía una factura al servidor y, si es válida y está dentro de los parámetros de cantidad, el servicio paga la factura. El protocolo de autenticación LNURL también se puede usar para garantizar que solo el usuario previsto pueda retirarse con éxito utilizando el enlace LNURL.

LNURL ha suavizado y mejorado gran parte de la experiencia de UX en torno al uso de Lightning Network, pero requiere el uso de un servidor web para ser utilizado. Todas las solicitudes y respuestas se manejan a través de HTTP, y se requiere una infraestructura adicional más allá del nodo Lightning para manejar estos métodos simplificados de coordinación y procesamiento de pagos. Este es un requisito perfectamente razonable para cualquier proveedor de servicios en línea o minorista que de todos modos necesite un servidor web para proporcionar sus servicios o productos en línea. Sin embargo, para un usuario final doméstico no experto en tecnología que solo quiere una experiencia tan sencilla como esta, un vendedor ambulante, una tienda física u otro usuario que aún no necesita usar un servidor web, puede ser una tarea tediosa y requisito potencialmente riesgoso.

¿Qué es el BOLT 12?

BOLT 12 ofrece un intento de lograr algunas de las funciones principales de LNURL sin requerir el uso de un servidor web. Una oferta codifica los datos necesarios para llegar a un nodo, solicitar una factura, realizar un pago, ya sea a un node_id o a una ruta ciega (los últimos saltos en una ruta de cebolla, precalculados y encriptados). mensajes También puede codificar un monto mínimo para un pago, la moneda en la que se pagará, un tiempo de vencimiento y números de cantidad mínima/máxima (para comprar varios artículos).

Esta es toda la información necesaria para recuperar una factura real del nodo que emitió la cotización. Alguien que quiere pagar una factura lo hace a través de Onion Messages, una de las funciones principales de BOLT 12. Permite que los nodos establezcan una conexión cifrada directa de extremo a extremo entre sí que no involucra un canal Lightning. Al igual que los pagos Lightning, estos pueden usarse para reenviar mensajes. Después de recibir una oferta, un pagador usa la información codificada en ella para enviar un mensaje de Solicitud de factura. El creador de la cotización luego responde con una factura real.

También hay soporte para generar ofertas únicas por usuario, lo que permite al destinatario solicitar el pago del creador de la oferta, similar a la función de solicitud de retiro de LNURL. Las facturas de BOLT 12 se comprometen con una clave de pagador única; esto se puede usar al emitir reembolsos para demostrar que usted es la persona que realmente pagó la factura. Esto también se puede usar en combinación con la oferta de retiro para garantizar que solo la persona adecuada pueda recibir una factura pagada por el creador y no todos los que puedan recibir una copia de la oferta.

Estos dos usos de ofertas realizan efectivamente la misma funcionalidad que las solicitudes de pago y facturación de LNURL sin la necesidad de ejecutar un servidor web.

LNURL o PERNO 12? Se trata de compromiso

LNURL y BOLT 12 cumplen la misma funcionalidad general, entonces, ¿cuál es realmente la diferencia entre ellos? ¿Por qué se necesita BOLT 12 cuando ya existe LNURL? La principal diferencia es el servidor web. Un servidor web requiere más infraestructura, un nombre de dominio, un certificado TLS y la experiencia para administrar esas cosas.

Si bien este no es un problema importante para la mayoría de las empresas y servicios, dado que estas cosas son necesarias para ejecutar un negocio en línea en primer lugar, es un gran problema para el usuario final típico no técnico. No se espera que un usuario instale infraestructura adicional en su nodo Lightning para acceder a una experiencia de usuario simple y optimizada. También está el tema de la centralización de DNS; Un dominio nunca puede ser realmente controlado por el propietario.

Aparte de estos problemas, ambos pueden coexistir. LNURL funciona a la perfección y ya está muy extendido en el ecosistema Lightning, simplemente no es una solución realista para usuarios que no sean empresas o servicios. BOLT 12, como se cree, puede cerrar esta brecha y ofrecer la misma experiencia de usuario optimizada a los usuarios finales domésticos no empresariales.

Ambas soluciones logran más o menos lo mismo para dos clases diferentes de usuarios, y eso está bien.

Esta es una publicación invitada de Shinobi. Las opiniones expresadas son exclusivamente suyas y no reflejan necesariamente las de BTC Inc o Bitcoin Magazine.