¿Qué es el BOLT 12? Bueno, son muchas características diferentes y piezas móviles juntas para lograr múltiples cosas diferentes: códigos QR estáticos, facturas modulares, privacidad para la persona que recibe el pago.
Pero, ¿qué es el paquete completo? Es una forma de tener un solo código QR, una “oferta”, que le permite obtener facturas de un nodo de una manera que preserva la privacidad, al mismo tiempo que permite cosas como solicitar que un nodo remoto pague su factura.
Ahora, cualquiera que esté familiarizado con LNURL ya debería estar pensando: “Esto 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 realizar pagos a través de Lightning Network usando HTTP. La lista completa de piezas del protocolo LNURL se puede encontrar aquípero solo voy a entrar en 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 retiro esquema de solicitud 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 la billetera del usuario firma con una clave recién generada. Una vez que el servidor recibe el valor aleatorio firmado, guarda la clave asociada para usarla en futuros inicios de sesión.
La funcionalidad de solicitud de factura es una forma de proporcionar información a un usuario sobre un pago que desea realizar en un formato que no es una factura. Esto proporciona una descripción del pago, el monto mínimo y máximo que se espera pagar por el servicio y una URL para la billetera desde la cual solicitar una factura real. Desde aquí, la billetera muestra esta información al usuario, lo que le permite establecer un monto final y solicitar una factura. Después de enviar la solicitud de factura y recibir una del servidor, la billetera verifica que los montos coincidan con lo que el usuario configuró y paga la factura.
La solicitud de retiro funciona haciendo ping al servicio y recibiendo como respuesta una descripción, una URL para enviar una factura, una cadena aleatoria (o determinista para vincular a una cuenta o usuario) y un monto mínimo y máximo que se puede retirar . Después de completar el valor apropiado, la billetera devuelve 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 se puede usar además de esto 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 propio nodo Lightning para manejar estas formas optimizadas de coordinar y realizar pagos. Este es un requisito perfectamente razonable para cualquier proveedor de servicios en línea o comerciante, que de todos modos necesitará un servidor web para proporcionar su servicio o productos en línea. Sin embargo, para un usuario final no técnico en el hogar que simplemente quiere una experiencia tan optimizada, un vendedor ambulante, una tienda física u otros usuarios que aún no requieren el uso de un servidor web, este puede ser un requisito oneroso y potencialmente riesgoso. .
¿Qué es el PERNO 12?
BOLT 12 ofrece un intento de lograr algunas de las funciones principales que proporciona LNURL sin necesidad de utilizar un servidor web. Una oferta codifica los datos necesarios para llegar a un nodo para solicitar una factura para realizar un pago, ya sea un node_id o un camino ciego (los últimos saltos en una ruta de cebolla, precalculados y encriptados) a ese nodo usando mensajes de cebolla. También puede codificar un monto mínimo para un pago, la moneda en la que se paga, un tiempo de vencimiento y números de cantidad mínima/máxima (para la compra de varios artículos).
Esta es toda la información necesaria para obtener una factura real del nodo que emitió la oferta. Alguien que quiere pagar una factura lo hace a través de mensajes cebolla, una de las funciones principales de BOLT 12. Permite que los nodos establezcan una conexión directa cifrada de extremo a extremo entre sí que no involucra un canal Lightning. Al igual que los pagos Lightning, estos pueden usarse para enrutar mensajes. Después de obtener una oferta, el pagador utilizará la información codificada en ella para enviar un mensaje de solicitud de factura. El creador de la oferta luego responderá con una factura real.
También hay soporte para generar ofertas únicas por usuario que permiten al receptor solicitar un 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 en el caso de 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 correcta pueda lograr que el creador pague una factura, a diferencia de quien pueda obtener una copia de la oferta.
Estos dos usos de ofertas cumplen efectivamente la misma funcionalidad que las solicitudes de factura y retiro de LNURL, sin la necesidad de ejecutar un servidor web.
LNURL o BOLT 12? Se trata de compensaciones
LNURL y BOLT 12 cumplen la misma funcionalidad general, entonces, ¿cuál es realmente la diferencia entre ellos? ¿Cuál es la necesidad de BOLT 12 si LNURL ya existe? La distinción clave es el servidor web. Un servidor web requiere ejecutar más infraestructura, un nombre de dominio, un certificado TLS y la experiencia para administrar estas cosas.
Si bien este no es un problema que valga la pena mencionar para la mayoría de las empresas y servicios, ya que estas cosas son necesarias para operar cualquier negocio en línea en primer lugar, este es un gran problema para su usuario final típico no técnico. No es una expectativa razonable que un usuario mantenga una infraestructura adicional acoplada a su nodo Lightning para tener acceso a una experiencia de usuario optimizada y simple. También está la cuestión de la centralización de DNS; un dominio no es algo que pueda ser realmente controlado por el propietario.
Aparte de estos problemas, ambos pueden coexistir. LNURL funciona bien y ya se ha adoptado ampliamente en el ecosistema Lightning, pero no es una solución realista para usuarios que no sean empresas o servicios. BOLT 12, tal como se adopte, puede llenar ese vacío y brindar la misma experiencia de usuario optimizada para los usuarios finales en el hogar que no son empresas.
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 totalmente propias y no reflejan necesariamente las de BTC Inc o Revista Bitcoin.
